A company launches a redesigned bilingual service website. The new homepage works, its navigation is tidy, and editors can publish content. During the first review, nobody notices that the old English service page now redirects to a general services overview. Its Arabic equivalent still loads, but carries a canonical reference to the English page. An old downloadable service guide returns an error.
From inside the new website, most journeys appear healthy. Someone arriving through an older search result, a bookmark, or an external link has a different experience. And the signals Google receives about which pages should be indexed may conflict with what the business intended.
This is a hypothetical scenario, not a Technway client incident or an observed search-traffic decline. It illustrates why technical SEO migration work cannot be signed off by looking at the new navigation. A search entry point has a history and an intended destination. The release must preserve or deliberately change that relationship—and verify it after the switch.
Our broader article on website migrations discusses business journeys, forms, content and operational continuity. Here the focus is narrower: the decisions that keep relevant pages discoverable while URLs, content systems and indexing signals change.
Treat search entry points as inventory, not as an afterthought
A URL can be valuable before anyone on the project remembers it exists. People may reach it from Google, documents, directory listings, adverts or links on other websites. Rebuilding a website from only the pages visible in its current menu is therefore an incomplete starting point.
Begin with an inventory of existing public URLs. Combine the CMS export with XML sitemaps, Search Console search and linking data, and server logs or analytics where available. The lists answer different questions: the CMS shows records the business maintains; a sitemap expresses preferred discoverable pages; search and server data can reveal older addresses that still receive attention. None is automatically complete on its own.
For every important URL, agree whether its address remains unchanged, its content moves to an equivalent new page, several useful pages are genuinely consolidated, or the content is intentionally retired. A new design should not silently decide this by generating different slugs.
Google’s site-move guidance (opens in a new tab) makes URL mapping a central preparation step for moves that change addresses. Its separate hosting-change guidance (opens in a new tab) applies when the visible URLs remain the same. That distinction matters: switching hosting or CMS does not, by itself, justify changing every public URL.
Before migration, save a comparison baseline for the main page groups, including the pages that attract important searches, and record the measurement period. Search Console impressions, clicks, queries and indexed-page observations can help later analysis. They are evidence of the earlier situation, not a target the new design can guarantee to reproduce exactly.
Give each old URL an intentional outcome
Consider a service page at /en/services/maintenance/ that will become /en/maintenance/. If it describes the same service, the old address should take visitors directly to the new maintenance page. Its Arabic counterpart should reach the corresponding Arabic content, not the English homepage. A PDF guide with an approved new location also needs an explicit decision: move it and redirect the old file URL, replace it with a useful current document, or retire it transparently.
Google recommends permanent server-side redirects (opens in a new tab), such as HTTP 301 or 308, for genuinely moved pages. A permanent redirect helps visitors follow an old link and signals the new preferred destination to Google. A temporary redirect communicates a different intention. The correct status should represent the actual move, not simply whichever rule is easiest to configure.
The redirect must be tested all the way to its final response. A technically functioning 301 that lands on a generic homepage can still be the wrong result; Google notes that mass redirects to irrelevant destinations may be treated as soft 404s. Multiple unnecessary redirects also add work and delay. Prefer an old URL pointing to the final relevant page rather than passing through earlier site structures.
Sometimes no replacement exists. A genuinely removed page may correctly return HTTP 404 or 410 instead of sending visitors to an unrelated category page. A consolidated service page can be a sensible redirect destination when it actually answers the earlier page’s purpose. The choice is editorial as well as technical: only the content owner can confirm what counts as an equivalent destination.
For a client, the useful deliverable is not merely a redirect spreadsheet. It is a map with a named decision owner and a pass condition for important old links. That turns SEO preservation into work a developer can implement and someone else can independently verify.
Keep the new site’s indexing signals in agreement
A new page can load successfully while telling search engines contradictory things. Its internal links might use the new address, its XML sitemap might list the old one, and its canonical tag might prefer an unrelated page. The technical checks are individually small; the combined message is confusing.
Google’s canonicalization guidance (opens in a new tab) distinguishes signals of different strength: redirects and rel=”canonical” annotations are stronger signals than sitemap inclusion. A canonical annotation expresses a preference, not a command guaranteeing which URL Google selects. For an intended new indexable service page, check that its canonical points to the right new URL, its internal links point there directly, and the sitemap lists the preferred new address.
The sitemap is a discovery and preference signal, not a list that forces Google to index everything. Google recommends fully qualified URLs (opens in a new tab) and inclusion of the canonical pages you actually want in search results. A sitemap filled with redirects, deleted URLs or unintended staging addresses is not evidence that migration work is complete.
The team’s verification should record the HTTP result, final URL, canonical target, internal-link destination, sitemap presence and whether the expected content is available. A green automated report that checks only for a canonical tag cannot establish that the tag points to the right page.
Remove development restrictions before they reach production
Staging environments are often deliberately hidden from public search. That is appropriate, but restrictions can become dangerous when they are copied into the live site without review. A production page may render normally to a logged-in reviewer while still carry a noindex instruction or sit behind a crawler restriction.
Google explains that a noindex rule (opens in a new tab) prevents indexing when a crawler can access and read it. Robots.txt disallow rules control crawling; if Googlebot cannot crawl the page, it cannot see a noindex instruction on that page. Blocking crawling is therefore not a reliable substitute for preventing the appearance of a URL in search results, nor is either mechanism appropriate for protecting confidential staging content. Password protection or proper access control is the safer boundary for a private preview.
At cutover, test the actual public response, not only the CMS switch labeled ‘discourage search engines’. Confirm that representative indexable service pages return HTTP 200, are not unintentionally noindexed or blocked, and expose the intended substantive content to the crawler. A visually complete browser page can still hide missing source content or a rendering dependency worth investigating.
A migration should distinguish its own intended exclusions—such as private account pages—from accidental restrictions on public content. Removing every robots or noindex rule indiscriminately would be as careless as keeping every staging rule.
Preserve language relationships as carefully as page addresses
A bilingual website adds a second mapping problem. Each service may have an English page, an Arabic page, or only one translated version. A new CMS can preserve the text and still generate wrong alternates, mismatched translations or canonicals that all point to one language.
Google’s localized-page guidance (opens in a new tab) says that hreflang alternate annotations should use fully qualified addresses and reference their own and reciprocal language versions. The annotations help Google understand equivalent localized pages; they do not translate the content or replace a page’s own canonical decision.
For an English and Arabic maintenance-service pair, check both pages after migration: each should show the correct language-specific content, the correct indexable URL and mutually consistent alternate links when those equivalents really exist. Avoid inventing an Arabic alternate when there is no corresponding localized page. A language selector that links to the homepage instead of the equivalent service page deserves a separate user-journey check.
These are not necessarily cosmetic faults. They can change which page Google selects for a language-specific query and where a person arrives after choosing a language. That makes localized SEO a joint responsibility of content editors and the technical team.
Make the launch decision with evidence, not a homepage screenshot
Before release, I would select a representative set of search entry points: an unchanged page, a moved high-value service page, an Arabic equivalent, a consolidated page, a deliberately removed page and an asset that has incoming links. Test the outcome of each using a request to the old URL and an inspection of the new destination.
The following compact release matrix illustrates what a reviewer should see. It is not a report of results from a real migration.
| Page type | Approved outcome | Release proof |
|---|---|---|
| Unchanged service | Keep URL and indexable content | HTTP 200; correct canonical |
| Moved English service | Permanent redirect to equivalent new page | Old 301/308; final new 200 |
| Arabic equivalent | Correct Arabic target and language pair | Locale content; reciprocal hreflang |
| Consolidated content | Redirect only to genuinely relevant new page | Content-owner approval; direct route |
| Retired asset or page | Use relevant replacement or real 404/410 | Explicit retirement decision; no homepage |
A failed check should have a clear consequence. An important page that redirects to the wrong service or remains noindexed is a stronger reason to delay launch than an optional metadata improvement. But a low-impact retired URL intentionally returning 410 is not necessarily a defect. The review must compare observed behavior with an approved mapping, not demand that every old URL resolve to HTTP 200.
For a domain or subdomain move, Google’s Search Console Change of Address tool (opens in a new tab) can be relevant after the new site and redirects are in place. The tool is not meant for routine path changes within one domain or merely switching HTTP to HTTPS. Knowing which kind of move is occurring prevents an unnecessary or incorrect configuration step.
After launch, distinguish expected movement from a silent failure
Google may need time to recrawl old and new addresses, process redirects and select canonical pages. Its migration guidance explicitly warns that search visibility can fluctuate during this transition. A temporary movement in ranking is not, by itself, proof of broken SEO; nor should a migration team dismiss a rising set of errors as normal fluctuation.
There are stronger diagnostic signals. Check whether priority old URLs still reach the planned destinations, whether the public sitemap contains the right new canonical URLs, whether important pages are indexable, and whether Search Console shows unexpected increases in missing or blocked pages. Where possible, compare search queries and landing-page groups rather than assuming every change in total clicks was caused by the new website.
Google recommends keeping permanent redirects for as long as practical, generally at least a year, and potentially longer to protect visitors following older links. Turning off the old redirects after the first successful week would leave a future problem for bookmarks, search recrawling and external links. A migration is not finished because the old hosting bill or redirect configuration can be cancelled.
The following symptom guide helps separate observations from possible causes. Each interpretation still needs evidence from the affected URLs and configuration.
| Post-launch symptom | Possible explanation | Next evidence |
|---|---|---|
| Important pages excluded | Old noindex or robots rule carried over | Inspect public headers, robots and URLs |
| Old links land on homepage | Over-broad redirect mapping | Trace affected old-to-final paths |
| Arabic result missing | Wrong canonical or alternate relationship | Check both locale URLs and links |
If new pages are slow to appear in search, verify that sitemaps and internal links point to the new URLs, check whether crawling has occurred, and allow for normal reprocessing time. If search clicks decline, compare affected queries and landing-page groups against the baseline before deciding that the migration caused the change. Search Console reports are diagnostic tools, not instant full-site crawls; Google also notes that demand and seasonality (opens in a new tab) can change search traffic independently of site moves.
Define who closes the SEO migration
A launch plan should name the owner of the URL mapping, redirect rules, production indexing controls, content-language equivalents, Search Console properties and post-launch review. Those roles may belong to the same small team, but responsibility should not disappear between a designer’s sign-off, a developer’s deployment and a content editor’s publication.
For a small business, the final report can be concise: what changed; which important URL groups were preserved, moved, merged or retired; what was actually tested; what remains uncertain; and which follow-up checks have a named owner. It should separate verified defects from normal indexing transitions and avoid promising unchanged rankings or traffic.
A working new website is one part of the release. A successful technical SEO migration also protects the addresses people already know, gives Google coherent discovery and canonical signals, and leaves enough evidence to identify faults that do not show up in a visual preview.
The business question is not simply ‘Does the new site look finished?’ It is ‘Can the important pages still be found through old entry points and understood at their new addresses—and who will notice if that stops being true?’
