replatform seo
Same domain, same URLs, entirely new site. The reassurance that "the URLs are not changing" is exactly what makes this migration type dangerous — everything else changed and nobody checked.
Primary riskTemplates, markup, rendering and internal linking all change at once while everyone focuses on the URLs that did not.
“The URLs aren’t changing, so SEO should be fine.”
It is said in almost every replatform kickoff, and it is half right in a way that causes real damage. Preserved URLs do eliminate the redirect problem, which is genuinely the largest risk in most other migration types.
They eliminate nothing else. Behind those identical URLs, the entire site has been rebuilt: different templates, different markup, different rendering, different internal linking, different structured data. A URL is an address, not a guarantee about what is at that address.
Crawl parity between staging and production is the whole method for this migration type. Compared field by field, the diff finds things that are invisible in a browser and obvious to a crawler.
Titles that lost their brand suffix, or gained one, across an entire section. H1s that are now the logo because the new theme marks it up that way. Word counts halved on category pages because descriptive copy moved into a collapsed tab that loads on click. Internal link counts down 60% on deep pages because a “related items” module did not make the build. Structured data absent because nobody had it on the ticket.
None of these produce an error. Every page returns 200. Every page looks correct to a person reviewing staging. They appear as a gradual decline four weeks after launch, at which point diagnosing them requires the comparison you could have run before.
Replatforming increasingly means moving from a server-rendered CMS to a JavaScript framework, and that changes what a crawler receives.
The test is simple and rarely run: fetch the raw HTML and look for the body copy and the internal links. If they are not there, they exist only after hydration.
Google will usually render the page eventually. Rendering is queued, and the queue is not instant or guaranteed. More importantly, internal links that only appear after hydration are discovered slowly, which changes how quickly the rest of the site is found. On a large site this is the difference between a two-week settling period and a two-month one.
Server-rendering the templates that carry organic traffic is almost always cheaper than the alternative, and it is a decision that has to be made during the build rather than after it.
New platforms generate URLs the old one did not. Faceted navigation, pagination parameters, sort orders, session identifiers, tag archives that nobody asked for.
Compare indexable URL counts before and after. A large unexplained increase is index bloat, not growth — crawl budget spent on near-duplicates instead of on the pages that earn money. The new site can look thinner to Google than the old one despite having more pages on it.
Decide the parameter and faceting policy before launch. Enforcing it afterwards means undoing indexation that has already happened.
For a specific move to headless WordPress, see WordPress to headless. For ecommerce, Shopify migrations covers the platform-specific patterns. If templates are changing without a platform change, design refresh applies instead.
The verification sequence in full is on the technical scope page.
What you see Pages look identical in a browser. The raw HTML response contains a shell, and body copy plus internal links only appear after hydration.
What fixes it Server-render the templates that carry organic traffic. If that is not possible, at minimum ensure internal links exist as real anchors in the initial HTML.
What you see Rich results disappear a few weeks after launch. Nothing in the traffic graph explains it until someone checks the markup.
What fixes it Inventory structured data by template before the move and rebuild it as part of the template work, not as a post-launch task.
What you see Deep pages lose rankings while top-level pages are unaffected. The new templates simply have fewer links on them.
What fixes it Compare internal link counts per URL between crawls. Rebuild the modules that carried links, or replace them with an equivalent.
What you see Indexable URL count climbs sharply after launch. Faceted, paginated and parameterized URLs appear that never existed before.
What fixes it Decide the parameter and faceting policy before launch, and enforce it with canonicals, robots rules or routing rather than after the fact.
| Element | Typically changes? | Impact if it does | How to catch it |
|---|---|---|---|
| Title and meta description templates | Almost always | Click-through rate changes across whole sections at once | Parity diff on title and description fields |
| Heading structure | Often | Topical signals shift; H1 sometimes becomes the logo | Parity diff on H1 and heading hierarchy |
| Internal link counts | Often | Pages lose link equity when sidebar or related modules are cut | Compare inlink counts per URL before and after |
| Rendering approach | Sometimes | Content and links move out of the raw HTML into client-side rendering | Fetch raw HTML and compare against the rendered DOM |
| Structured data | Almost always | Rich results disappear when markup is not rebuilt | Compare structured data types present per template |
| Pagination and faceting | Often | New parameterized URLs appear and create index bloat | Compare indexable URL counts before and after |
| Image handling | Almost always | Alt text lost, filenames changed, image URLs broken | Crawl image URLs and alt attributes on both |
The whole job is the diff. Everything on this list exists to produce a comparison between what the old site presented and what the new one presents.
Two crawls of the current site — one executing JavaScript, one not. The difference between them is your existing rendering baseline.
Output Two production crawl exports
Using HTTP auth credentials rather than removing the protection. Removing auth so a crawler can reach staging is how staging sites get indexed.
Output Staging crawl export
Titles, descriptions, H1s, canonicals, meta robots, word counts, internal link counts, structured data types, image alt coverage.
Output Parity diff with variance counts per field
A large unexplained increase means the new platform is generating URLs the old one did not. That is index bloat arriving with the build.
Output URL count comparison
For each template that carries organic traffic, confirm body content and internal links exist in the raw HTML response.
Output Rendering report by template
robots.txt, meta robots and X-Robots-Tag on the live site. Staging noindex reaching production is the single most expensive launch-day failure.
Output Production directive audit
Yes, and the belief that it is not is what makes it risky. Templates, markup, rendering, internal linking and structured data all change. Identical URLs mean the redirect work is trivial; they say nothing about whether the pages behind those URLs still present the same signals.
The crawl parity diff between staging and production, compared field by field. It finds the differences nobody thought to test, which is reliably where the damage is. Everything else on this page is either an input to that diff or a response to it.
Verify what exists in the raw HTML response, not what appears in the browser. Google renders JavaScript, but rendering is queued and internal links that only exist after hydration are discovered slowly. Server-render the templates that carry organic traffic.
Two to six weeks of volatility when URLs are preserved and parity is genuinely close. Longer if URLs also changed or if the parity gaps were significant. Compare against a frozen benchmark on a matched URL cohort rather than week over week.
Send the launch date and what is changing. We will tell you which parts of this page apply to your situation and which do not.