A site migration has one step that cannot be reversed: cancelling the old platform. Everything before it can be redone. Everything after it depends on what was captured first. This post is the inventory to complete before that step, for anyone moving off a hosted site builder or an ageing content system, whether a person or a coding agent is doing the moving.
The examples are illustrative and drawn from the general shape of such projects; no specific site, platform or owner is described. Our site migration playbook covers the search side of a move end to end. This one is narrower: what to take with you, where the built-in export falls short, and the reconciliation that catches the difference.
- 01The platform's export is a starting point, not an inventory.Exports tend to miss drafts, hidden sections, secondary collections, per-page metadata and anything configured in native settings rather than content. A full crawl and the export, compared, is the inventory.
- 02The platform's own redirect list can hold entries no crawl will find.A crawler follows a redirect silently and records the destination. Only the platform's redirect table shows the old source URLs, and it is deleted with the account.
- 03Tracking is often split between a tag container and native settings, and a container can be broken by a single character.Capture both. Test the container on the new site with a tag debugger before launch; a typographic quote pasted into custom HTML is enough to stop it firing.
- 04Change only the web records in DNS, and keep the old site live until every redirect is verified.Mail, SPF, DKIM, DMARC and verification records live in the same zone. Google recommends keeping redirects at least a year; the old platform only has to stay until the redirects are proven, which is days, not months.
01 — The problemWhy the export is not the site
A hosted builder stores a site as objects it understands: pages, collections, assets, settings, integrations. Its export function serialises some of those objects, usually the ones a new owner would call content. It rarely serialises the rest. Drafts and hidden sections stay behind because they are not published. A second blog created under a different collection is exported only if someone knew it existed. Redirects, tracking IDs typed into integration fields, custom head code and crawler settings are configuration, not content, and configuration is what the cancellation deletes first.
The result is a migration that looks complete on the new platform and is missing a few hundred URLs, a pixel, and the redirects that were protecting the site's oldest links. Each of those is easy to capture while the old site is live and impossible after. The inventory below is organised by what disappears, not by what the export offers.
02 — The inventoryThe capture inventory: six groups
| Group | Capture | What the export tends to miss | Where the copy lives |
|---|---|---|---|
| Content | Every page, post and collection item, including drafts, unpublished and password-protected pages, and any secondary blog or collection the builder treats as a separate object. Page titles, meta descriptions, slugs, publish dates, authors, categories and tags. | Hidden sections, drafts, a second blog set up years ago, and per-page metadata that the export flattens into the body. | The platform export plus a full crawl, stored side by side. |
| URLs and redirects | The complete list of live URLs from a crawl and from the sitemap; the platform's own redirect table; URLs that receive traffic per analytics; URLs that carry inbound links per Search Console. | Redirects created inside the platform years ago that no crawl can see, because the crawl follows them silently; image and file URLs that other sites hotlink. | A mapping sheet: old URL, new URL, source of the row. |
| Tracking and pixels | The tag container's export; every tracking ID entered in the platform's native settings fields; consent-banner configuration; conversion and event definitions; form-submission destinations. | IDs typed into the builder's own integration fields rather than the container, so the container export looks complete and half the tracking is missing. | The container export, and a list of native settings with a screenshot of each. |
| Media | Every image, video, PDF and download at original resolution, with alt text and the URL it was served from. | Files served from the platform's CDN that stop resolving when the plan ends, taking image search and hotlinked embeds with them. | Mirrored to your own storage before the old plan ends; alt text in the content export. |
| DNS and verification | The full zone: A and AAAA, CNAME, MX, TXT (SPF, DKIM, DMARC, Search Console and other verifications), SRV and CAA records, plus registrar details and who holds them. | Mail and verification records that live in the same zone as the web records and break when someone replaces the zone instead of editing the web records. | A zone export, and a change plan that touches only the web records. |
| Settings | Robots rules and crawler access settings; canonical and hreflang configuration; custom code injected into head and body; 404 page; language and locale settings; integrations and API keys. | A crawler-blocking setting copied from the old site's staging days, or head code that carried a verification the new site now lacks. | Screenshots and a settings list, checked off on the new platform. |
Two of the six groups deserve a second look because they fail quietly. Tracking first: a container export can be complete and the site still under-tracked, because the builder offered a field for the analytics ID and someone used it. List every native integration field and what is in it. Then, on the new site, load the container and confirm every tag fires; a custom HTML tag pasted through a word processor can arrive with typographic quotes that break the script without any visible error.
Redirects second: a crawl of the old site records where each URL ends up, not where it started. If the platform holds a redirect from a 2019 campaign URL to a current page, the crawl sees only the current page. The platform's redirect table is the only record of the source, and it goes with the account. Export it before anything else, and treat every row as a URL the new site must answer.
03 — The rulesWhat Google asks you to keep, and for how long
Google's site-move documentation, updated August 20, 2026, is the reference for the URL side of the inventory. Its advice on finding old URLs matches the table: start with the sitemap, server logs or analytics for the URLs that get traffic, and Search Console's links report for pages with inbound links; use the content system for a full listing; and include images, videos, JavaScript and CSS, which "need to be moved in the same way as all other content". It asks you to save two lists for the final move: a sitemap of the new URLs and the list of sites linking to the old ones.
On redirects, the redirects guide and the site-move page agree: server-side permanent redirects, 301 or 308, wherever technically possible; client-side redirects only as a last resort; no chains where a direct redirect is possible, and ideally no more than three hops. Google says permanent redirects do not cause a loss of PageRank. And on duration, the site-move page asks you to keep redirects "for as long as possible, generally at least 1 year", so that links pointing at the old URLs can be recrawled and reassigned. That year belongs to the new host, not the old platform.
Change one thing at a time: Google's example is to move domain first and change the layout later, not both at once. And submit a Change of Address in Search Console only when the domain or subdomain changes; it is not needed for HTTP to HTTPS, www to non-www, or path moves within the same domain.
04 — The checkReconciliation: crawl, export and redirect list, compared three ways
An agent-run migration is a deterministic pipeline: export, crawl, map, build, redirect, verify. The step that makes it safe is a reconciliation that compares the three sources of truth and sends every disagreement to a person. The router below is the decision table we use; it is also the acceptance test for the migration before the old platform is cancelled. Our post on building a source index before an agent rewrites content describes the same discipline for the content itself.
The verification request is the part to automate fully: for every row in the mapping, fetch the old URL, follow redirects, and assert the status code and the final destination. Our guide to auditing redirects as preserved, thinned, merged or lost gives the four outcomes to classify each row into.
05 — The orderCancel last, and only after the redirects are proven
Capture everything in the table
Export, crawl, redirect list, container, native settings, media mirror, zone export. Store them together with the date. This is the point of no regret: from here, any later mistake can be repaired from the copy.
Build and reconcile
Build the new site from the export, run the reconciliation, resolve every disagreement, and place the redirects on the new host. Test the tag container with a debugger on the new site before DNS changes.
Change only the web records
Edit the records that point the domain at the new host. Leave MX, SPF, DKIM, DMARC and verification TXT records untouched. Replacing the whole zone from a template is how a migration takes down email.
Verify, then cancel
Run the verification across the full mapping from outside your network, check Search Console for crawl errors over several days, confirm forms and tracking fire, and only then cancel the old plan. Google's one-year redirect advice applies to the new host, not to keeping the old subscription.
The old platform costs one more month of subscription to keep alive through verification. That is cheap insurance against the one step that cannot be undone. Our web development practice runs migrations on this order, with the capture inventory signed off before any build starts.
06 — ConclusionEverything but the cancellation can be redone; capture as if it cannot
Export the platform's redirect list and mirror the media today, reconcile crawl against export before building, and keep the old plan until every redirect verifies
A migration goes wrong quietly, months later, when an old link or an old pixel turns out to have been in the part the export never covered. The inventory is how you find that part while it can still be copied.