Rebuild a site without losing search ranking
A rebuild often changes URLs, content, and code at the same time. This guide separates the decisions, sets the checks before cutover, and organises follow-up after publication.
05 chapters
Start with the inventory, not the mockup
The first artefact of the job is the list of current URLs. It brings together the sitemap, pages found in measurement tools, internal links, and any pages that no longer appear in the navigation.
Each URL then gets a decision: keep, improve, merge, redirect, or remove. A page that still attracts visits or inbound links never disappears by accident. Website design and SEO therefore share the same roadmap from scoping.
An SEO rebuild is prepared before cutover
Google organises a site move as a sequence of checks. This order avoids discovering the URL map when it is time to publish.
- 01
Inventory
List current URLs, useful pages, internal links, and signals already earned.
- 02
Map
Give every old address a destination that genuinely takes over its intent.
- 03
Test
Check pages, links, canonicals, and redirects before launch.
- 04
Publish
Switch URLs and redirects without mixing in other domain or architecture changes.
- 05
Monitor
Watch both sites, the sitemap, and errors until the new addresses are taken over.
Google advises changing one thing at a time and generally keeping redirects for at least a year.
- Export indexed URLs and those that receive visits.
- Record titles, canonicals, HTTP statuses, and inbound links.
- Map each old URL to an explicit destination.
Write the redirect map before cutover
A 301 redirect must go straight to the page that takes over the intent of the old one. Chains, loops, and bulk redirects to the home page dilute the signal and make diagnosis harder.
The map is tested like code: a single source, a published destination, one hop, no conflict with domain or trailing-slash rules. The Créarègle case study shows this constraint in an e-commerce migration where URL history is part of the product to deliver.
Make every signal tell the same address
The server, the canonical tag, internal links, and the sitemap must name exactly the same URL: same protocol, same domain, same slash rule. If one of them differs, the engine spends time resolving an ambiguity the site created.
The sitemap contains only published, indexable pages. Prototypes, editors, APIs, and working pages stay reachable if needed, but are never offered as results to crawl.
Not every clue carries the same weight
Google lists redirects and canonical tags as strong signals. Sitemap inclusion is useful, but weaker.
- Signal 01Strong
Redirect
The old URL leads directly to the selected new address.
- Signal 02Strong
Canonical tag
The published page names the address that should act as reference.
- Signal 03Weak
Sitemap
The file confirms preferred URLs but cannot fix a contradictory redirect or canonical.
These signals can reinforce one another. They should all describe the same destination.
- One canonical tag per page.
- No redirected or private URL in the sitemap.
- Internal links already written in their canonical form.
Accept the exported site and the real journey
Acceptance is not opening the home page. It walks old URLs, priority pages, forms, mobile and desktop versions, the keyboard, and zoom. Exported HTML is checked before it is sent to the server.
HTTP responses and canonicals are recorded before and after launch. That snapshot makes gaps verifiable and allows a fast return if a page becomes unavailable or non-indexable.
Watch indexation without confusing movement with regression
After cutover, the sitemap is submitted again and priority pages are requested for crawl. Old URLs stay watched until engines have taken their destinations.
Impressions, clicks, queries, and conversions are read over several weeks. A rank fluctuation is not, on its own, a reason to roll back. A bad canonical, a broken form, or an unavailable page is. To scope the rebuild, the estimate gives a first order of magnitude before a conversation.
The remaining decisions
Must every old URL be kept?
No. Keep the intent. A useful page can stay, two redundant pages can merge, and a URL with no equivalent can go. Each decision must be explicit in the map.
How long should 301 redirects be kept?
As long as old URLs can still receive visits or links. In practice they stay in the site configuration instead of being removed after a short period.
Does a rebuild always cut traffic?
No. A period of movement is possible, but a lasting drop is not a given. The map, the redirects, the stability of useful content, and follow-up exist precisely to limit that risk.
Put the guide against a real project.
A few lines are enough: context, the main constraint, and the expected result.