The 2026 Website Migration Checklist for Ecommerce Agentic Builds
For digital strategy leads, ecommerce teams, and the
engineers they hand the work to, who need every check
written down with the inspection that clears it.
More builds now have agent assistants on the team, writing templates, wiring up the catalog import, and clearing in an afternoon what used to take a sprint. We build this way too, and we would not go back. What we keep seeing is a team arriving at launch week fast, confident, and missing one thing nobody thought to look for. This list is written to hold that pace and keep those steps in front of you.
- 152
- Checks
- 4
- Phases
Before you start
This is a systems check, not a project plan.
A slower build had dead time in it. Somebody waited two days on a ticket and noticed the product import had only brought half the catalog. That dead time is where these steps used to get caught. What slips through now takes weeks to surface. Alt text that doesn't prerender, or a staging noindex that ships to production because whoever added it moved to another project before launch week.
Every check is written to be handed over: what has to be true, and what a human or an agent should inspect before that piece gets the green light. Give your agents a phase at a time, at the point in the build where that phase is live, and each check arrives as work they can run rather than advice they have to interpret.
The goal of the list is to carry the traffic and the revenue the old site earned through the launch and out the other side.
Nothing here is tied to a platform or a schedule. The checks describe what has to be true of the site rather than how a particular system produces it, so a hosted store, a headless build, and a custom enterprise application all read the same list. A launch nine months out runs the same four phases as one four weeks out, in the same order, and a short timeline compresses them rather than removing one.
Every check comes out of the same place: more than 100 site migrations run over our careers. Nothing on this list is theoretical. Each row is here because its absence cost somebody traffic, revenue, or a month of recovery, and most of them are what a shortcut or a rushed week turns out to cost.
Want a second set of eyes before you cut over?
This is the checklist we run on client migrations. We have partnered with leading Shopify, Adobe, and Salesforce agencies on theirs, and we are glad to help with yours.
Phases
The URL structure and the templates are still in flight, so a decision made here costs a prompt rather than a rebuild.
Goal for this phaseBefore the build freeze, settle the decisions the build will be expensive to reverse: the URL structure and its locale handling, the rendering method for each template, the title and description patterns, and the AI crawler policy. Finish the inventory of what the old site earns page by page, and store that baseline somewhere the old platform cannot take with it.
Migration features
URL inventory
These tasks build the record of what the old site was worth, page by page. Keeps every URL carrying traffic, an inbound link, or revenue inside the plan before the rebuild starts. Avoid finding out a page mattered a month after it died.
-
The URL inventory is built from four sources, not one
What to inspectConfirm the list merges a full crawl, analytics landing pages, Search Console pages, and server log requests. A CMS export alone will miss the long tail that still earns links.
-
The inventory covers non-HTML assets that earn traffic
What to inspectCheck that PDFs, images, and feed URLs appear in the list. Filter the log file by extension to see what is actually being requested.
-
Every inventoried URL has a current status code recorded
What to inspectCrawl the inventory and store the response code per URL, so URLs that are already broken before the migration are handled rather than carried over.
-
URLs with external links are flagged separately
What to inspectJoin the inventory against referring-domain data. These are the URLs where a missed redirect costs link equity you cannot rebuild.
-
Revenue is attributed to URLs before the rebuild
What to inspectPull revenue or lead value per landing page for the last 12 months and attach it to the inventory, so mapping can be prioritized by value rather than by template.
-
Orphan pages are found while the old site is still up
What to inspectCrawl the old site and list pages that earn traffic but have no internal link pointing at them. A crawl-based inventory of the new site cannot find them by definition, so they are dropped without anybody deciding to drop them.
-
URLs that assistants cite are marked must-preserve alongside the ones that rank
What to inspectPull the pages that turn up as citations and flag them in the inventory. They are often not the pages that rank, so a list prioritized from search data alone leaves them unprotected.
-
When several sites merge into one, each source is inventoried separately
What to inspectRun the inventory per source property rather than in aggregate. Two of them will have a page on the same topic, and which one survives is a decision worth making deliberately rather than by whichever import ran last.
URL structure
These tasks settle what the new URLs look like before anyone builds against them. Keeps one structure that the platform can actually produce, agreed once rather than per template. Avoid discovering during the build that the pattern everybody planned around was never possible.
-
The new platform can produce the URL patterns the plan assumes
What to inspectAsk the build team to produce one live example of each planned pattern on staging, which is where platform limits become apparent.
-
URL depth and hierarchy are decided deliberately
What to inspectConfirm related content sits under a consistent parent path, and that important pages are not buried deeper than the old structure without a reason.
-
URLs are lowercase, hyphenated, and free of parameters where possible
What to inspectCrawl staging and filter for uppercase characters, underscores, and query strings on canonical pages.
-
Faceted and filtered URLs have a defined indexation rule
What to inspectConfirm which facet combinations are indexable, which are canonicalized, and which are blocked, before the templates ship.
-
Pagination has a defined, crawlable pattern
What to inspectCheck that page two onward is reachable by a crawler without JavaScript and that each page has a self-referencing canonical.
-
The domain itself is changing or it is not, and only one of those happens at a time
What to inspectConfirm whether the domain moves in the same release as the platform. Running both at once makes it impossible to attribute a drop to either, so separate them when the schedule allows.
-
Content stays on the domain rather than moving to a subdomain
What to inspectCheck where the blog, help center, and store will live on the new stack. Hosted platforms default a section onto a subdomain, and a section moved there restarts on authority it spent years building.
-
Locale URL handling is decided once, including non-Latin scripts
What to inspectConfirm whether slugs are translated per market and how scripts outside Latin are transliterated. Mixed handling across a catalog cannot be cleaned up with redirects later.
Catalog data
These tasks make sure essential products are not forgotten at launch. Keeps prices, stock, and identifiers matching the system of record. Avoid imports that fail partially and quietly, and shopping feeds that get rejected.
-
Product records are reconciled by count before and after the move
What to inspectCompare product, variant and image counts between the old export and the new catalog. Import failures are silent and partial.
-
Discontinued and out-of-stock products have a decided rule
What to inspectConfirm the rule per case: redirect to the closest replacement, keep the page live with alternatives, or return 410. Without one the outcome is silent 404s on former best sellers.
Redirect mapping
These tasks carry the value of the old URLs onto the new ones. Keeps the rankings and the link equity already attached to every page you are replacing. Avoid catch-all redirects, chains, and loops, which look handled right up until traffic drops.
-
The redirect map has a named owner and a start date before the build freeze
What to inspectName the person who owns the map, then check their start date against the build freeze. Start after the freeze and the map cannot change a single URL, so every awkward destination has to be lived with for the life of the site.
Rendering
These tasks decide whether a crawler sees a page or an empty shell. Keeps the content in the response, which everything else on this list assumes. Avoid a build that renders for shoppers and returns a skeleton to everyone else.
-
Every template has a rendering method, and it is written down
What to inspectAsk for the list: which templates are server-rendered, which are statically generated, and which are assembled in the browser. Anything earning revenue belongs in the first two. On a headless build this gets decided once, early, by whoever is closest to the framework, and nobody revisits it.
-
Rendering does not branch on a list of user agents
What to inspectAsk whether the server chooses what to send based on who is asking. Google treats that as a workaround rather than an answer, it puts you one step from cloaking, and every new crawler has to be added by hand before it can see anything.
On-page fundamentals
These tasks make sure every page can describe itself in a search result. Keeps titles, descriptions, and headings unique and editable. Avoid catalog templates generating thousands of near-identical titles nobody can override.
-
Templated pages generate unique titles and descriptions from real fields
What to inspectAsk for the title and description pattern per template, then render three live examples. Catalog templates that concatenate the same words produce thousands of near-identical titles.
-
Titles and descriptions can be overridden per page from the CMS
What to inspectEdit one product and one category in the CMS and confirm the override survives a republish. Pattern-only systems leave no way to fix an important page.
Structured data
These tasks keep the extra detail that makes a result stand out in the listing. Keeps rich results working on every template, generated from real fields. Avoid markup that disagrees with the page, which loses the result outright.
-
The profiles the brand actually controls are collected and confirmed
What to inspectGather the live social, marketplace, and directory profile URLs, and confirm each is held by the company rather than a reseller, a franchise, or an old agency account. These become the organization markup that tells engines which accounts are you, and a wrong entry attaches the brand to somebody else.
Internationalization
These tasks keep each market pointed at its own pages. Keeps every locale serving its own audience instead of competing with the others. Avoid hand-maintained hreflang, which goes stale the first time somebody publishes.
-
Hreflang is generated automatically, not maintained by hand
What to inspectPublish a page on one locale and confirm the corresponding hreflang entries appear on the others without manual work.
Performance
These tasks make sure the new site is not slower than the one it replaces. Keeps Core Web Vitals at or above what the old build delivered. Avoid a redesign that trades speed for appearance and pays for it in rankings.
-
A Core Web Vitals baseline exists per template before anything changes
What to inspectRecord field and lab numbers for each template while the current site is still live. This is a measurement you can only take once, and without it a reading after launch says what the new site does and nothing about whether it got worse.
AI channel
These tasks protect the visibility that never shows up in analytics. Keeps the AI crawler access and the citations the site already earns. Avoid losing the channel silently, since none of it appears in GA4.
-
AI crawlers are allowed or blocked by deliberate decision
What to inspectReview robots.txt for GPTBot, ClaudeBot, PerplexityBot, and Google-Extended, and confirm the decision is intentional rather than inherited from a template.
-
The AI crawler policy and llms.txt are decided together, in writing
What to inspectDecide which AI agents are allowed and whether an llms.txt ships, then record it. A platform default inherited without a decision either closes the channel or opens it wider than intended.
-
Bot activity is logged at the edge, in front of the application
What to inspectPut the logging at the CDN or worker layer rather than inside the platform, so it records requests the application never sees and survives the platform change intact. Analytics tags run in a browser and none of these agents load one, so a tag-based setup captures nothing here.
-
Product and category copy is scored for whether it can be quoted
What to inspectRate the highest-value pages on completeness, specification parity against the datasheet, and whether they answer a comparison outright. Assistants quote a page that settles a question and skip one that reads as a brochure.
Measurement
These tasks make sure you can prove what the migration did. Keeps one comparable record of performance either side of the cutover. Avoid losing the baseline along with the old platform, and having nothing to argue from afterwards.
-
A pre-migration baseline is captured and stored outside the platform
What to inspectExport traffic, revenue, rankings and index coverage per template before anything changes. Platform reporting rarely survives the platform.
-
Search Console and Bing properties are claimed for every variant before the build starts
What to inspectClaim the domain property and the URL-prefix properties for apex and www on both the old host and the new one, then verify each. History only accrues from the day a property is claimed, so one added during launch week has nothing to compare the launch against.
Infrastructure
These tasks make the cutover survivable. Keeps every hostname answering and the whole move reversible in minutes. Avoid TTL, certificate, and bot-protection defaults locking out visitors and crawlers.
-
The layer that serves the redirect map has a named owner
What to inspectConfirm which system answers when the platform's own redirect limits are exceeded, and who deploys to it. On a consolidation this is usually a CDN or an application tier belonging to a different team than the store, and it is discovered late.
The build is done and staging answers requests, with a date set. An agent can still fix anything on this list from one ticket, and that stops being true the moment real traffic is on it.
Goal for this phaseAt least two weeks before the launch date, clear every check against staging rather than against intent. Every revenue template returns complete HTML to a plain request, a real transaction completes end to end, the catalog reconciles against the system of record, titles and markup generate from real fields, and the crawl paths are open. Anything still outstanding at that point is a conversation about the launch date.
Migration features
Catalog data
These tasks make sure essential products are not forgotten at launch. Keeps prices, stock, and identifiers matching the system of record. Avoid imports that fail partially and quietly, and shopping feeds that get rejected.
-
Price, inventory and identifiers match the system of record
What to inspectSample across the catalog and compare against the ERP or PIM, including GTIN and MPN. Structured data inherits these fields, so an import error becomes a rich result error.
-
Reviews and other user-generated content carry over with their products
What to inspectCheck that review counts and ratings follow the product, not the URL. Review markup that empties out drops the stars from every listing.
-
The shopping feed points at the new URLs before the old ones expire
What to inspectConfirm the merchant feed regenerates from the new catalog and that item IDs stay stable, since changed IDs restart the learning on every shopping campaign.
Redirect mapping
These tasks carry the value of the old URLs onto the new ones. Keeps the rankings and the link equity already attached to every page you are replacing. Avoid catch-all redirects, chains, and loops, which look handled right up until traffic drops.
-
The destination list comes from imported data, not from a naming rule
What to inspectWait until the catalog and content import has finished on staging, then crawl the new site for the real URL list. Destinations predicted from a slug convention before the import routinely differ from what the platform actually generated, and every one of those is a redirect to a 404.
-
Both sides of the map exist as clean lists
What to inspectConfirm you have the list of URLs that are changing or already broken, and the list of new valid destinations, before any matching begins.
-
Each old URL resolves to its single best match, not a catch-all
What to inspectSpot check that redirects land on the closest equivalent page. Blanket redirects to the homepage or a category root pass almost no value and read as soft 404s.
-
The map contains no redirect loops
What to inspectRun the map through a crawler that follows chains and flag any URL that returns to itself.
-
Redirect chains are collapsed to a single hop
What to inspectCrawl the map following redirects and flag any source that takes more than one hop to reach a 200. Update the source to point at the final destination.
-
No redirect points at a URL that is itself broken
What to inspectCrawl every destination in the map and confirm a 200 response. A redirect to a 404 is worse than no redirect, because it looks handled.
-
Pattern rules cover the bulk, manual decisions cover the value
What to inspectConfirm the bulk of the catalog is handled by rules, and that manually mapped URLs are the revenue pages and the externally linked ones.
-
Platform redirect limits are known and designed around
What to inspectConfirm whether the target platform supports wildcards. Shopify redirects are one to one with no pattern matching, so a large catalog needs a generated bulk file rather than rules.
-
Query string behavior is tested, not assumed
What to inspectRequest a real URL carrying a tracking parameter and confirm it survives to the destination. Test the exact URL shapes campaigns and affiliates use.
-
Redirects are verified by response code, not by spreadsheet review
What to inspectRun the full map against staging or the live host and record actual status codes. A spreadsheet review only confirms what was intended.
Rendering
These tasks decide whether a crawler sees a page or an empty shell. Keeps the content in the response, which everything else on this list assumes. Avoid a build that renders for shoppers and returns a skeleton to everyone else.
-
The rendered response is the finished page, not a loading shell
What to inspectRequest a product and a category with curl and read the body rather than the status code. A prerender service that times out still returns 200, and the skeleton it sends looks healthy in every report you have.
-
The prerender cache serves current data
What to inspectChange a price on staging, then request the page without a browser and check the number. These caches hold copies for hours or days by default, which is how a page and its feed end up disagreeing about price.
-
Hydration does not replace what the server sent
What to inspectCompare the raw HTML against the DOM after the page settles on a product template. Where they disagree, the version you tested is not the version anyone sees, and the version indexed may be neither.
-
The agents that never run JavaScript receive the rendered response
What to inspectRequest a page as each AI crawler and as a plain HTTP client, and confirm the copy is in the body. Prerender allowlists get written for Googlebot and are rarely revisited, so these agents fall through to the client-rendered version and read nothing.
-
Rendering holds up at crawl rate, not just at browsing rate
What to inspectRequest a few hundred URLs in sequence and watch the response times and the error rate. Server rendering that is comfortable for shoppers can time out under a full recrawl, which is exactly when the whole catalog is being fetched at once.
Content parity
These tasks make sure the new page still says what the old one said. Keeps the copy, the internal links, and the markup that earned the current rankings. Avoid a rebuilt template quietly dropping the text block that made the page rank.
-
Page-level content parity is checked on the templates that matter
What to inspectCompare old and new versions of the top revenue templates for missing copy, specs, reviews, and internal links.
-
Titles and meta descriptions are generated, not left blank
What to inspectCrawl staging for empty or duplicated titles and descriptions, especially on generated pages such as products and categories.
-
One H1 per page, and it is the first heading in the source
What to inspectCrawl staging for pages with zero or multiple H1s, and confirm fixed elements such as the footer do not carry heading tags.
-
Internal links point at final URLs, not through redirects
What to inspectCrawl staging and flag internal links that return a 301. Fix them at the source rather than relying on the redirect.
-
Images carry descriptive filenames and alt text
What to inspectCrawl for missing alt attributes and for filenames that are hashes or camera defaults on templates that matter for image search.
-
Crawlers and visitors are served the same content
What to inspectRequest a template with a crawler user agent and with a browser one, then diff the two responses. Personalization or geo-routing that keys off the user agent is cloaking, whatever it was built for.
-
Content embedded from another host is accounted for
What to inspectList anything arriving in an iframe, including reviews, sizing tools, and configurators. Iframed content is credited to the source, not to the page that frames it.
-
Content held in custom fields moves with the record
What to inspectList the metafields or custom fields carrying copy, specifications, and schema input, then confirm each one populated on staging. These sit outside the main body field and are the most common thing a product import leaves behind.
On-page fundamentals
These tasks make sure every page can describe itself in a search result. Keeps titles, descriptions, and headings unique and editable. Avoid catalog templates generating thousands of near-identical titles nobody can override.
-
Every template renders exactly one H1, and it is the page subject
What to inspectCrawl staging and report H1 counts per template. Rebuilt themes commonly put the H1 in a logo or drop it from listing pages.
-
Heading order runs in sequence within the main content
What to inspectCheck that headings descend without skipping levels, and that headings in headers, footers and cookie bars are not competing with the page's own.
-
Every page carries a self-referencing canonical that resolves
What to inspectCrawl staging and confirm each canonical points at the live, indexable version of the same page, not at a staging host, a parameter variant, or a redirect.
-
Social preview tags are populated per page rather than sitewide
What to inspectRun three templates through a link preview and confirm the title, description and image describe that page. A single default image sitewide is a lost click on every share.
-
Titles and descriptions fit inside what a result actually displays
What to inspectCrawl staging and flag titles past roughly 60 characters and descriptions past roughly 155. Generated patterns overflow first on the longest product names, which are usually the ones worth the most.
-
Metadata on the highest-value URLs is diffed old against new, row by row
What to inspectCompare title, description, and H1 between the old site and staging for the top pages by revenue. Templated generation is where a page quietly loses the exact wording that earned it, and a crawl that only checks for blanks will pass it.
Images
These tasks protect a traffic source most rebuilds treat as decoration. Keeps image search traffic and the links images have earned. Avoid a bulk re-upload that renames files to hashes and drops alt text.
-
Images survive the move with their filenames and alt text intact
What to inspectCompare a sample of old and new product pages. Bulk re-uploads frequently rename files to hashes and drop alt text, which loses image search entirely.
-
Image URLs either carry over or are redirected
What to inspectCheck the image inventory from the old crawl against the new one. Images earn traffic and links, and a new CDN path without redirects breaks both.
-
Images are in the source on the templates that matter
What to inspectFetch a product page with JavaScript disabled and confirm image elements carry real src attributes, rather than being assembled by a gallery script after load.
Structured data
These tasks keep the extra detail that makes a result stand out in the listing. Keeps rich results working on every template, generated from real fields. Avoid markup that disagrees with the page, which loses the result outright.
-
Structured data is populated from CMS fields, not hand-written
What to inspectChange a product field on staging and confirm the markup updates without a developer touching a template.
-
Markup validates on every template type
What to inspectRun one URL per template through Google's Rich Results Test and confirm no errors. The older Structured Data Testing Tool is deprecated.
-
Breadcrumb markup matches the visible breadcrumb
What to inspectCompare the markup path against what renders on the page. A mismatch is a manual-action risk, not just a warning.
-
Open Graph and Twitter tags are populated automatically
What to inspectRun a few URLs through a social debugger and confirm image, title, and description resolve.
-
Every markup type the old site carried is present on the new one
What to inspectList the schema types found in the old crawl and diff them against the new. Video, FAQ, and organization blocks are the ones that disappear with the theme that produced them.
-
Organization markup carries the site search action and the navigation
What to inspectValidate the homepage and confirm the organization block includes the search action and the sitewide navigation element. Both are template-level and neither survives a rebuild by default.
Internationalization
These tasks keep each market pointed at its own pages. Keeps every locale serving its own audience instead of competing with the others. Avoid hand-maintained hreflang, which goes stale the first time somebody publishes.
-
Hreflang clusters are reciprocal and include x-default
What to inspectCrawl the locales and confirm each page references every alternate and is referenced back, with one x-default per cluster.
-
Locale routing does not redirect by IP address
What to inspectRequest a locale URL from outside its country and confirm a 200 rather than a redirect. IP-based routing shows a crawler one market and hides every other one.
-
Currency and locale switching does not fork the URL for identical content
What to inspectChange currency and confirm the URL and the canonical stay put, or that each combination is indexed deliberately.
Crawlability
These tasks make sure the engines can still reach the site on launch day. Keeps search and AI crawlers reading the pages without interruption. Avoid a staging index block reaching production, which removes the site from search altogether.
-
Staging is blocked from indexing
What to inspectRequest a staging URL and confirm the noindex header or robots block is present, and that the block is on staging only.
-
Removing the staging block is a written step in the launch runbook
What to inspectConfirm the runbook names the file, the line, and the owner. A staging noindex left in place after launch will deindex the site.
-
robots.txt on the new site is reviewed line by line
What to inspectDiff the new robots.txt against the old one and confirm every disallow is intentional.
-
The XML sitemap contains only live, indexable URLs
What to inspectCrawl the sitemap and confirm every entry returns 200 and is not noindexed, redirected, or canonicalized elsewhere.
-
A crawler can find the sitemap without being told where it is
What to inspectConfirm the index sitemap is referenced in robots.txt and reachable at the root.
-
Every page has a self-referencing canonical that can be overridden
What to inspectCrawl staging and confirm canonical tags resolve to the page's own final URL, and that the CMS allows an override where duplication is intentional.
-
Important content is present without JavaScript
What to inspectFetch a template with JavaScript disabled and confirm the primary copy, links, and navigation are in the source HTML.
Sitemaps and indexing
These tasks tell the engines what to index and what to leave alone. Keeps a sitemap crawlers can trust, with indexation decided page by page. Avoid noindex reaching production, which is the most expensive mistake on this list.
-
The XML sitemap contains only live, indexable, canonical URLs
What to inspectCrawl the sitemap itself. Redirects, 404s and noindex URLs inside a sitemap teach a crawler that the file is unreliable.
-
Sitemaps regenerate on their own when content changes
What to inspectPublish and unpublish a test page and confirm the sitemap updates without a developer. A sitemap that goes stale is worse than none.
-
Noindex is controllable per page, and nothing carries it by accident
What to inspectConfirm the CMS exposes the setting, then crawl staging for noindex and check every hit is deliberate. A staging-wide noindex shipped to production is the single most expensive migration mistake.
-
Internal search results and filtered views are kept out of the index
What to inspectConfirm search URLs and multi-facet combinations are noindexed or blocked, so the crawl budget goes to pages that can rank.
-
Images are submitted in a sitemap where image search matters
What to inspectConfirm image URLs appear either in a dedicated image sitemap or as image entries on the page sitemaps.
-
A crawlable index of the catalog exists outside the navigation
What to inspectCheck that an HTML sitemap or equivalent index page lists the catalog and renders without JavaScript. It is the fallback path into deep pages whenever the navigation changes shape.
Error handling
These tasks make sure the pages you removed are honestly gone. Keeps status codes truthful on everything that no longer exists. Avoid soft 404s, which hold dead URLs in the index for months and waste crawl budget the whole time.
-
The 404 page returns a 404 and helps a visitor continue
What to inspectRequest a nonsense URL and read the status code, not the page. Confirm as well that the page offers search and a route back into the catalog rather than a dead end.
-
The 404 template is editable and routes visitors back into the catalog
What to inspectConfirm the page can be changed from the CMS, and that it offers search and top categories rather than an apology.
Performance
These tasks make sure the new site is not slower than the one it replaces. Keeps Core Web Vitals at or above what the old build delivered. Avoid a redesign that trades speed for appearance and pays for it in rankings.
-
Core Web Vitals are measured on the new templates, not the old site
What to inspectRun lab tests on staging for LCP, INP, and CLS per template, and confirm the field data plan for after launch.
-
Render-blocking resources above the fold are eliminated
What to inspectCheck the critical request chain on the heaviest template and confirm blocking CSS and JS are deferred or inlined deliberately.
-
Images are sized and compressed at upload, not in the browser
What to inspectConfirm the CMS produces responsive sizes and modern formats, and spot check that a large source image is not being served at full resolution.
-
Scripts and styles are bundled and minified in the production build
What to inspectMeasure the production build rather than the development one, and confirm the count of blocking requests is no higher than the old site's.
-
Third-party tags are re-approved rather than copied across
What to inspectList every tag on the old site and decide individually which ones move. A replatform is the one opportunity to drop the accumulated ones, and each survivor costs interaction latency on every page.
Commerce journeys
These tasks make sure people can still buy and still sign in. Keeps checkout completing and migrated accounts working. Avoid hearing about a broken payment or a broken password reset from the customers themselves.
-
A real transaction completes end to end on staging
What to inspectBuy something with a live payment method in test mode, through to the confirmation page and the order in the back office.
-
Tax, shipping and discount logic produce the same totals as the old site
What to inspectPrice the same basket on both, across a domestic address, an international one, and a promotion code.
-
Customer accounts and their history survive the migration
What to inspectLog in as a migrated customer and check order history, saved addresses and the password reset flow. Reset is the step that breaks, because it depends on mail the new platform sends.
-
Promotions, gift cards, and loyalty balances carry over
What to inspectRedeem an active promotion code, a gift card balance, and a loyalty account on staging. These sit in apps rather than the core catalog, which is why they get left behind.
-
Internal search returns sensible results against the new catalog
What to inspectRun the top internal search terms from the old site and read the results. Search is rebuilt from scratch on most platforms, and it carries a large share of ecommerce revenue.
AI channel
These tasks protect the visibility that never shows up in analytics. Keeps the AI crawler access and the citations the site already earns. Avoid losing the channel silently, since none of it appears in GA4.
-
Key content is readable without executing JavaScript
What to inspectFetch a product and a guide template with JavaScript off. AI crawlers do not render, so anything client-side is invisible to them.
-
A pre-migration baseline of AI crawler activity exists
What to inspectCapture which AI bots hit which URLs, and how often, before the cutover. Without a baseline you cannot tell whether the migration cost you AI visibility.
-
AI crawlers are not challenged by the new host's bot protection
What to inspectRequest a page with each AI crawler user agent from outside your own network and confirm a 200 rather than a challenge page. Managed bot rules on new hosting block these by default more often than they allow them.
-
The answer-shaped content that earns citations survives the rebuild
What to inspectCompare old and new templates for the definitions, specifications, comparisons, and question headings that assistants quote. Rewriting those passages into marketing copy removes the exact part that was getting cited.
Measurement
These tasks make sure you can prove what the migration did. Keeps one comparable record of performance either side of the cutover. Avoid losing the baseline along with the old platform, and having nothing to argue from afterwards.
-
Ecommerce events fire on staging with correct values
What to inspectComplete a test purchase on staging and confirm the item, quantity, currency and revenue arrive intact. Tags copied across usually fire; the payload is what breaks.
-
Consent handling does not suppress measurement by default
What to inspectLoad a page and check what fires before any consent choice, then after each choice. A stricter default banner on the new build reads as a traffic collapse.
-
Campaign and affiliate destination URLs are updated with the map
What to inspectRun the live ad, email and affiliate destination lists through the redirect map. Paid traffic landing on a redirect chain costs money on every click.
Infrastructure
These tasks make the cutover survivable. Keeps every hostname answering and the whole move reversible in minutes. Avoid TTL, certificate, and bot-protection defaults locking out visitors and crawlers.
-
DNS TTL is lowered before the cutover, not during it
What to inspectConfirm the record TTL was dropped to a few minutes at least 24 hours ahead. A TTL still set to a day makes a rollback take a day.
-
A restorable backup of the old site exists, and someone has restored it
What to inspectRestore the backup somewhere and load it. An untested backup is a plan, not a rollback.
-
Access to the old host survives the launch
What to inspectConfirm the old hosting, database and DNS credentials stay valid for at least 30 days past cutover, and name who holds them.
-
The certificate covers every hostname the site answers on
What to inspectCheck the certificate against the apex, www, and any locale or shop subdomain. One uncovered hostname turns a redirect into a browser warning.
-
The firewall and bot rules allow verified search and AI crawlers
What to inspectRequest a page from the new host with a crawler user agent and confirm a 200 rather than a challenge. Default bot protection on a new host blocks the crawlers you need.
Launch day
These tasks make sure the plan actually happened. Keeps the cutover window short enough to reverse. Avoid accepting that a step ran instead of reading the response yourself.
-
Launch has a written go or no-go decision with a named signer
What to inspectProduce a short sign-off listing what was checked, what is still open, and who accepted the risk on each open item. A launch that proceeds on a verbal sense that things are probably fine leaves nobody to ask afterwards.
The cutover window itself. These are the checks to watch execute rather than read a report on, because a mistake reverses in minutes for a few hours and costs weeks after that.
Goal for this phaseInside the cutover window, confirm by request rather than by report: the index block gone, every hostname resolving one way, the caches purged, a real order placing with its confirmation email arriving, and analytics recording it. Finish before traffic reaches its daily peak, with the rollback path still open and someone on call who has read it.
Migration features
Error handling
These tasks make sure the pages you removed are honestly gone. Keeps status codes truthful on everything that no longer exists. Avoid soft 404s, which hold dead URLs in the index for months and waste crawl budget the whole time.
-
Soft 404s are not being returned in place of real ones
What to inspectCheck that removed pages return 404 or 410 rather than a 200 with an empty template, which is the pattern that keeps dead URLs in the index for months.
Commerce journeys
These tasks make sure people can still buy and still sign in. Keeps checkout completing and migrated accounts working. Avoid hearing about a broken payment or a broken password reset from the customers themselves.
-
Transactional email sends from the new platform
What to inspectPlace a live order after cutover and confirm the confirmation and shipping notifications arrive, and that they are not landing in spam from a newly sending domain.
AI channel
These tasks protect the visibility that never shows up in analytics. Keeps the AI crawler access and the citations the site already earns. Avoid losing the channel silently, since none of it appears in GA4.
-
The edge logging is still recording after the DNS change
What to inspectRequest a page with a crawler user agent once the cutover is done, then look for that hit in the log within a few minutes. A DNS or CDN change routes around the worker doing the capture, and the gap only surfaces weeks later when the comparison has nothing in it.
Measurement
These tasks make sure you can prove what the migration did. Keeps one comparable record of performance either side of the cutover. Avoid losing the baseline along with the old platform, and having nothing to argue from afterwards.
-
Search Console is verified for the new host and the change is filed
What to inspectConfirm verification on every property variant, and submit the change of address where the domain itself moved.
-
The cutover is annotated in every reporting tool
What to inspectAdd the date and a one-line note to analytics, rank tracking and the log platform, so the step change is explained when someone reads it in six months.
Infrastructure
These tasks make the cutover survivable. Keeps every hostname answering and the whole move reversible in minutes. Avoid TTL, certificate, and bot-protection defaults locking out visitors and crawlers.
-
Protocol, host and trailing slash each resolve one way in one hop
What to inspectRequest all four variants of a live URL and confirm each reaches the canonical form with a single 301.
-
Mail and verification DNS records survive the move
What to inspectCheck MX, SPF, DKIM and any domain verification TXT records after the change. A record set rewritten wholesale takes transactional email down with it.
-
Caches are purged after the redirects go live
What to inspectPurge the CDN and any page cache, then request a redirected URL from a cold edge. Cached copies of the old response outlive the deploy.
Launch day
These tasks make sure the plan actually happened. Keeps the cutover window short enough to reverse. Avoid accepting that a step ran instead of reading the response yourself.
-
The staging index block is confirmed removed by request
What to inspectFetch a live URL and read the headers and robots.txt yourself. Do not accept "it was removed" from memory.
-
Redirects are live and returning 301, not 302
What to inspectRequest a sample across every mapped pattern and confirm a permanent status code and the right destination.
-
The exceptions are tested, not just the patterns
What to inspectRequest the manually mapped URLs specifically. Patterns usually work; the hand-mapped exceptions are where errors hide.
-
Analytics and tag firing are confirmed on the new templates
What to inspectComplete a real transaction or lead submission and confirm it lands with the expected attribution, rather than assuming the tag copied over.
-
A rollback plan exists and someone has read it
What to inspectConfirm who decides, what the trigger is, and how long a rollback takes, and that the people on call have read it before launch night.
-
The new sitemap is submitted
What to inspectSubmit the index sitemap in Search Console and confirm it is read without errors.
The recrawl window. Losses surface over weeks, long after the build agents have moved on to the next project, so somebody has to own this on a calendar.
Goal for this phaseReturn organic sessions and revenue to the pre-migration baseline within eight weeks, measured per template against the numbers captured during the build. Across the full recrawl cycle, keep watching index coverage, real 404s, rendered output, crawler activity, and AI citations, and work whatever is still down in order of the revenue attached to it.
Migration features
Rendering
These tasks decide whether a crawler sees a page or an empty shell. Keeps the content in the response, which everything else on this list assumes. Avoid a build that renders for shoppers and returns a skeleton to everyone else.
-
Rendered output is re-checked after launch, not only before it
What to inspectFetch a sample across templates weekly for the first month, without a browser. Cache rules, feature flags, and personalization all get changed after launch by people who have no reason to think about crawlers.
Images
These tasks protect a traffic source most rebuilds treat as decoration. Keeps image search traffic and the links images have earned. Avoid a bulk re-upload that renames files to hashes and drops alt text.
-
Images are being served at a sane size and format after launch
What to inspectSample the largest pages and confirm the delivered bytes match the rendered dimensions. A rebuilt theme often ships originals where the old one shipped derivatives.
Error handling
These tasks make sure the pages you removed are honestly gone. Keeps status codes truthful on everything that no longer exists. Avoid soft 404s, which hold dead URLs in the index for months and waste crawl budget the whole time.
-
404s are triaged by the value of the URL that produced them
What to inspectJoin the 404 log against the revenue and referring-domain data already in the inventory, and fix in that order rather than by volume.
Performance
These tasks make sure the new site is not slower than the one it replaces. Keeps Core Web Vitals at or above what the old build delivered. Avoid a redesign that trades speed for appearance and pays for it in rankings.
-
Core Web Vitals are compared against the pre-migration baseline, template by template
What to inspectWait for enough field data to accumulate, then put it beside the numbers captured during the build. A single template that regressed is invisible in a sitewide score.
AI channel
These tasks protect the visibility that never shows up in analytics. Keeps the AI crawler access and the citations the site already earns. Avoid losing the channel silently, since none of it appears in GA4.
-
AI crawler activity is compared against the baseline after launch
What to inspectConfirm the same bots are reaching the new URLs at a similar rate. None of this appears in GA4, so it has to come from server-level capture.
-
Citation share is tracked against the pre-migration baseline
What to inspectRun the same prompt set monthly across the assistants that matter and compare against the baseline. This recovers more slowly than search, because each assistant recrawls on its own schedule.
Monitoring
These tasks catch the losses that only appear weeks later. Keeps performance visible across a full recrawl cycle, per template rather than in aggregate. Avoid calling the migration a success before the engines have finished recrawling.
-
Redirects are re-verified on live URLs after cutover
What to inspectRe-run the full map against production. Server configuration differences between staging and production are common and quiet.
-
Traffic and revenue are compared at template level, not in aggregate
What to inspectBreak performance out by page type. A flat sitewide number can hide one template collapsing.
-
404s are monitored from real requests, not guessed
What to inspectWatch server logs and Search Console for 404s with actual traffic or inbound links, and add redirects for the ones that matter.
-
Index coverage is tracked across a full crawl cycle
What to inspectWatch indexed page counts and coverage errors for at least six weeks. Losses appear as engines recrawl, not on launch day.
-
Crawlers are confirmed reaching the new URLs in the logs
What to inspectFilter server logs by verified crawler and confirm they are fetching new URLs rather than looping through redirects or hammering 404s.
-
The migration is reviewed against a defined success measure
What to inspectCompare against the pre-migration baseline on a date agreed in advance, so the project closes against numbers rather than against a general sense that it went fine.
-
Recovery has a stated window and a date to review it
What to inspectAgree in advance what recovery looks like and when it will be judged. A well-run migration recovers inside four to twelve weeks, so a flat result at week twelve is a signal to investigate rather than to keep waiting.
-
Losses are worked in order of the revenue attached to them
What to inspectRank the drop by the revenue recorded against each URL in the inventory rather than by percentage. A 40 percent fall on a page that earned nothing is not the problem to solve first.
-
Head terms are tracked individually, not as an average
What to inspectTrack the specific terms that drove the most revenue before the move. A sitewide average hides one category term collapsing while long-tail volume holds the total up.
-
Server errors are watched as closely as missing pages
What to inspectTrack 5xx responses next to 404s for the first few weeks. A new stack fails differently under real traffic than it did on staging, and a 5xx tells a crawler to come back later rather than that the page is gone.
-
The checks are handed back as a list somebody else can run
What to inspectWrite down what was checked and what broke, and give it to whoever owns the site next. The same list applies to every theme change and feature release after this one, and it is the only artifact from the migration with a life beyond it.
What each page template needs during Building
The phases above run in time order. These run by page type, because a launch gets divided among the people who own each template. Global applies everywhere.
Phase
Page templates
These hold true on every page. Check them once against a sample of each template.
-
Robots rules and the noindex flag are what production intends
What to inspectRead the live robots.txt and crawl a sample for noindex. Staging defaults reaching production is the failure that costs the most and is the easiest to miss.
-
One canonical per page, self-referencing and resolving
What to inspectConfirm the canonical points at the live indexable URL, not a staging host or a redirect.
-
Analytics, consent and server logging are all recording
What to inspectLoad a page and confirm the tag fires, the consent banner does not block measurement by default, and the request appears in the logs.
-
The header and footer link set matches the old site
What to inspectDiff the sitewide link lists. Global navigation carries most internal linking, so a dropped block changes the whole site's internal structure.
-
HTTPS, www and trailing slash all resolve one way
What to inspectRequest each variant and confirm a single redirect to the canonical form, with no chains and no loops.
The homepage carries more links than anything else on the site, and most crawls begin there.
-
Organization and site-level markup are present and valid
What to inspectRun the page through a structured data validator and confirm the organization block carries the real name, logo and profiles.
-
The primary navigation and featured links render server-side
What to inspectView source rather than the inspector. The homepage is where crawl paths begin, so client-side links cost the most here.
-
The old homepage URL variants still resolve
What to inspectTest index.html, default.aspx and any legacy locale root, since these accumulate links over years.
Category pages hold most of the catalog rankings. Pagination and filters are what break them.
-
Product links are in the HTML, not loaded on scroll alone
What to inspectFetch without JavaScript and count product links. Infinite scroll with no paginated fallback hides the catalog from non-rendering crawlers.
-
Pagination is crawlable and each page is self-canonical
What to inspectConfirm page two is reachable by a link and canonicals to itself, not back to page one.
-
Filter and sort combinations do not generate indexable duplicates
What to inspectCheck that faceted URLs are noindexed, blocked or parameter-handled, and that a plain unfiltered URL exists for each category.
-
Category copy survived the move
What to inspectCompare the intro and supporting copy against the old template. Rebuilt grids routinely drop the text block that made the page rank.
Product pages convert, and they are the ones most often rebuilt client-side.
-
Product markup carries price, availability and identifiers
What to inspectValidate a sample and confirm the values match what the page displays, since mismatches lose rich results outright.
-
Description, specifications and reviews are in the source
What to inspectFetch without JavaScript. Tabs and accordions that fetch content on click leave the page empty to anything that does not render.
-
Variants resolve to a stable, canonical URL
What to inspectConfirm each variant either has its own indexable URL or canonicals to the parent, consistently across the catalog.
-
Discontinued products have a decided destination
What to inspectConfirm the rule is decided in advance: redirect to the closest replacement, keep the page live with alternatives, or return 410. Without one, the outcome is silent 404s on former best sellers.
Editorial URLs change more than any others in a replatform, and they are the easiest to leave behind.
-
Article URLs are mapped individually, including dated paths
What to inspectCheck old patterns with year and month segments against the new structure. These rarely map by rule and are frequently dropped wholesale.
-
Article markup carries author, publish date and modified date
What to inspectValidate one article and confirm the dates are real rather than the migration date, which resets the apparent freshness of the whole archive.
-
Category and tag pages are deliberately indexed or not
What to inspectConfirm the decision per taxonomy, and that tag combinations are excluded. Auto-generated tag archives are a common source of thin duplicates.
Nobody demos these pages, so nobody catches them before launch.
-
Internal search results are excluded from the index
What to inspectConfirm the results template carries noindex, and that no internal link points into a search URL.
-
The 404 template returns a 404 status
What to inspectRead the status code for a nonsense URL rather than trusting what the page says.
-
Account, cart and checkout are excluded but reachable
What to inspectConfirm they are noindexed or blocked, and that blocking has not also removed them from the navigation a shopper needs.