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.
Soheil Saheb-Jamii · Anym Studio06 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, A connection that allows two pieces of software to communicate., 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.
A migration worksheet to complete before release
Create one row per existing URL with these columns: old URL, clicks and impressions for the chosen period, known inbound links, decision, new URL, planned redirect, pre-release check and post-release check. Record the period and data source at the top. An unknown value stays “not measured”, rather than becoming zero.
Choose keep, merge or remove for each row based on its content and usefulness. A merged page needs a destination that still answers its original need. Redirecting to the homepage can lose that connection. Test old addresses in the browser too: destination, HTTP status, no redirect chain and the expected content.
Prepare two acceptance lists: the addresses most useful to the business and a sample from every template. After release, check these lists, the sitemap, internal links, forms and Search Console data over a comparable period. Keep the release date in the worksheet to distinguish migration errors from changes already happening beforehand.
- A destination agreed for every important URL.
- “Not measured” wherever evidence is missing.
- Redirects tested for status and destination.
- A named reviewer for each template.
- A dated log of issues and fixes.
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.