Addresses change without a map
A page that earned clicks, links or impressions disappears. Without an equivalent destination and a permanent redirect, the new address must be discovered and assessed without a clean connection to the old one.
Redesign and search
Redesign a website without losing SEO: the migration method
A redesign does not preserve search visibility by magic. It protects it by handling every address, link and signal before release, then watching what Google actually recrawls.
Short answer
Protecting what you have means preparing the move URL by URL
To limit avoidable losses, inventory the current URLs, decide what to keep, merge or remove, map each one to its new address, set direct permanent redirects, update internal links and annotations, then monitor crawling and clicks in Search Console. Temporary fluctuation can still happen during recrawling: no serious provider can promise zero movement.
The actual risk
Why a redesign can reduce organic traffic
The design is not the problem by itself. Risk appears when the new version changes how useful content is addressed, linked, rendered or made available to crawlers.
Useful content is simplified away
A cleaner-looking design can remove the answers, examples, evidence or vocabulary that made the page useful for a query. The review compares old and new content, not templates alone.
Internal links and technical signals drift
An internal link that still points to an old address adds a redirect on every visit. A canonical, hreflang annotation or sitemap left on the old plan sends contradictory signals too.
Release testing stops at the browser
A page can look correct while being blocked by noindex, robots.txt, an unexpected server response or incomplete rendering. Testing must inspect what a crawler receives as well as what a person sees.
Before release
Build the SEO safety net before changing addresses
The central document is not a list of pages to build. It is a decision table connecting the current site, the new architecture and the evidence behind every choice.
1. Inventory the addresses that matter
Combine the sitemap, a crawl, analytics landing pages, Search Console clicks and impressions, server logs if available, and known external links. A URL missing from navigation may still carry traffic or an important backlink.
- Current canonical URL and HTTP status
- Available clicks, impressions, conversions and inbound links
- Click depth and internal links received
- Page type, intent covered and content owner
2. Decide: keep, merge, redirect or remove
Keeping a page means keeping its address and role. Merging requires a truly equivalent destination that retains the useful information. Removal is legitimate when no replacement exists: a clear 404 or 410 is better than a redirect to an unrelated page.
- One final destination for every old URL
- No bulk redirects to the homepage
- No important content removed without an explicit decision
- Language variants handled as separate pages
3. Test the new site in a closed environment
Test templates, structured data, links, canonicals, hreflang, performance and mobile rendering before opening. Staging can remain noindex, but the list of temporary controls to remove at release must be written and testable.
- Every planned URL returns the right status and content
- The canonical references the new address itself
- Internal links point directly to final destinations
- The sitemap contains only canonical URLs meant for indexing
Redirect plan
The table that must be complete before release day
Every row connects an old address to its treatment. Cases with no equivalent are not hidden: they receive an explicit decision and owner.
| Decision | What the table containsevidence and destination | Release checkwhat must be true |
|---|---|---|
| URL kept | Old URL equals new URL, with content and intent compared. | 200 response, clean canonical, direct internal links. |
| URL moved | Old URL, equivalent new URL and reason for the move. | Server-side permanent redirect in one hop. |
| Pages merged | All source URLs and one destination retaining their useful information. | Every source redirects to the destination, with no chain or loop. |
| Content removed | Reason, no equivalent, traffic and links checked. | Real 404 or 410; no redirect to an irrelevant page. |
Google recommends server-side permanent redirects such as 301 or 308 and asks site owners to update internal links to the new URLs. A redirect is not a reason to keep sending your own visitors through it.
Release day
Go live in an order another person can verify
The release should be testable by someone other than the person who configured it. This checklist concerns the public website’s actual responses.
01
Open crawling
Remove planned temporary noindex and crawling blocks, then check robots.txt on the public domain. Private and deliberately non-indexable pages keep their own controls.
02
Enable and test redirects
Test a sample of every rule, then the full file: permanent status, correct final destination, no loop, chain or irrelevant redirect.
03
Verify signals on the new version
Check canonicals, hreflang, internal links, structured data, images and server responses. The new sitemap should list only URLs you want in search results.
04
Send the right Search Console signals
Submit the new sitemap. Use Change of Address only for a domain or subdomain change, not for a redesign that keeps the same domain.
After release
The first thirty days, then until the move stabilises
Thirty days are a first monitoring cycle, not a guaranteed finish date. Google says a move is processed URL by URL and a medium-sized site can take several weeks for most pages to move in its index.
| Signal | Days 0–2blocking defects | Days 3–14recrawl and coverage | Days 15–30+trend and gaps |
|---|---|---|---|
| Server and crawl | 5xx, loops, chains, robots and unexpected noindex. | New 404s, old URLs still requested, crawl activity. | Persistent errors, missed assets and old URLs still active. |
| Indexing | Inspect a priority sample. | Sitemap discovery and exclusion reasons. | Old URLs declining as new ones enter the index. |
| Visibility | Keep the baseline; do not conclude from a few hours. | Compare impressions, clicks and queries by page group. | Measure gaps by template and intent, not domain total alone. |
| Behaviour | Analytics and critical events still arrive. | Compare landing pages, forms and journeys. | Check conversion and traffic quality alongside visibility. |
Keep redirects for at least one year according to Google, and longer where possible for people and old links. Monitoring does not stop because a dashboard is green; it stops when old and new URLs tell a coherent transition story.
Applied to your website
What an audit should provide before work begins
A useful pre-redesign audit does not stop at a global score. It produces a usable inventory: URLs still earning impressions, buried pages, broken links, inconsistent canonicals and templates creating the same defect at scale.
The decision remains human. The tool gathers findings and evidence; the agency then compares the move with the offer, CMS constraints, content to preserve and the available review rhythm.
To frame the starting point and delivery: see what the SEO audit checks, see the steps in our redesign method.
To prepare the inventory and internal linking: the 12 checks to run before rebuilding the website, find pages buried in the website architecture.
Primary sources
Rules checked against Google’s documentation
The time-sensitive recommendations on this page were checked on 12 August 2026 against official Google Search Central documentation.
Move with URL changes
Inventory, mapping, permanent redirects, link updates, sitemaps and Search Console monitoring.
Hosting change without URL changes
The distinct case where DNS and infrastructure capacity become central concerns.
Consolidating duplicate URLs
How permanent redirects, canonicals and sitemaps influence the primary URL.
SEO migration questions
Straight answer
No. Temporary fluctuation can happen while Google recrawls and reindexes new URLs, but lasting decline is not inevitable. Avoidable losses mainly come from unmapped URLs, removed content, incorrect redirects or contradictory technical signals.
Before the first redirect
Inventory the website you already have
The audit creates a baseline before the new architecture hides the old defects — and the pages that already carried your visibility.