Port a client's existing website into Seedly Sites - the migrate command, the parity gate, what carries over for SEO, and what needs rebuilding.
Loading the guide...
Help us make the guides more useful.
0 helpful · 0 not helpful
Porting is one of the three ways to fill a new client site with content: point the migration tool at the client's existing website and it reproduces the site in the builder - structure, content, styling, brand, and blog - ready for review. This is how you take over a site without rebuilding it from scratch.
You can run a migration from the command line, below, or from Migrations in the operator sidebar: paste one site address per line, queue them, then press Dispatch batch to run the ports on your GitHub Actions. Each job gets its own page where you check the harvested brand and publish its drafts. The batch route suits several sites at once; the command line gives you the flags.
Given the site's URL, the migration:
Because pages become native builder elements, the ported site is fully editable afterward - the migration is a starting point you own, not a locked-in copy.
The migrator is built for WordPress sites and tuned for ones built with the YOOtheme page builder. Other sites go through a more general capture, so check the parity report closely on those.
A migration never publishes and never deploys. Every page lands as a draft for your review. If imported images could not be brought into your own media storage, the affected pages are held as drafts and the tool tells you which URLs to fix - so a half-imported site cannot leak live.
From the platform repo, with your CMS running:
There is no bare seedly command on your machine; the CLI runs through pnpm from the platform folder. migrate signs in with your operator email and password, passed as --email and --password or set as PAYLOAD_EMAIL and PAYLOAD_PASSWORD.
The target site is found or created by slug. Useful flags:
| Flag | Use |
|---|---|
--dry-run | Extract and convert without persisting - inspect the result first |
--only home,about,services | Port just these pages |
--limit 3 | Port the first few pages (testing) |
--blog-only | Skip pages; import or re-import only the blog |
--qa | Capture source-vs-result screenshots and score similarity after the run |
After porting, diff each page against the live original:
The parity check compares section by section - structural content plus desktop and mobile screenshots - and prints a coverage report: clean sections, sections with gaps, and anything dropped. Migration runs are also tracked in the portal's migration board, where each page carries its parity signal for triage.
Work the gaps in the builder before publishing anything.
Migration reproduces the site closely - then you finish in the builder. It is not pixel-perfect and we will not pretend otherwise; the parity report exists precisely to show you the remaining distance.
Carries over:
Handled at go-live (by you, with platform support):
Does not carry over:
migrate create it by slug)--dry-run first if the site is unusualOne rule to respect: migration is a one-time initial import. Re-run it only before hand-editing begins - after takeover, the builder is the source of truth.
| Question | Answer |
|---|---|
| Input | The live site's URL |
| Output | Draft pages of native builder elements + brand + media + blog |
| Fidelity | Close, verified per page by the parity gate |
| Publishes anything? | Never - drafts only, you publish and deploy |
| Forms / plugins | Do not survive - re-embed forms, replace plugin behavior |
| SEO | 301s + carried-over titles and descriptions + remapped internal links + regenerated sitemap |