Keeping Google rankings during a site redesign: a checklist.

The way to keep Google rankings during a site redesign is to connect every old address Google knows to the equivalent page on the new site with a permanent (301) redirect in a single step, to test this line by line on launch day, and to monitor for weeks after the move. Rankings usually drop not because the design changed, but because addresses quietly disappeared.

A new website is usually discussed as a design job: colors, typeface, photos. To a search engine, though, a site is a list of addresses. Over the years Google has learned hundreds of your site’s addresses and attached to them the links from other sites, the matches with queries and their history. If the new site breaks this list, everything tied to the old addresses goes with it. That is why the real subject of website redesign and migration is not design but preserving this list.

The list below is split into three phases: before launch, on launch day and after launch. Each item is explained in detail in its own guide; this page exists to keep the order and to make sure no step is skipped.

Why do rankings drop during a site redesign?

Google’s site move documentation says plainly that rankings may fluctuate during a move: while Google crawls and indexes the new addresses, old and new addresses appear side by side for a while. On a medium-sized site it can take a few weeks or longer for the new addresses to replace the old ones; on large sites even longer. This temporary fluctuation is to be expected.

Permanent loss, by contrast, mostly comes from three causes. First, old addresses without a redirect: visitors and Google hit an error page, and the value of the external links pointing to that address is passed nowhere. Second, mass misdirection: sending hundreds of old addresses all to the homepage. Google does not see this as an “equivalent page”; the old addresses are treated like error pages. Third, a change in the content itself: if the title, text or scope of a well-ranking page was narrowed in the redesign, that page may not carry its old queries even when the address is redirected correctly.

What should be done before launch?

• Compile the full list of old addresses — sitemap, Search Console and a crawl of the site itself, together. This list is called a URL inventory; the rest of the migration rests on it.
• Mark the addresses that receive traffic and external links. These are the most expensive to lose; none of them is skipped for being “old” or “small.”
• Write down a single decision for each old address: a 301 to the equivalent page on the new site, or 404 or 410 if there is no equivalent. How to write it is explained in the 301 redirect guide.
• Leave no chains in the map: every old address should reach its final address in one step. Google recommends keeping chains to at most three hops; one hop is best.
• Compare the titles and text of the new pages with the queries the old page carried. A page whose content is lost cannot carry its rankings, even if the address is redirected correctly.
• Every page of the new site should declare its own address as canonical; on a multilingual site, hreflang links should point to the new addresses.
• List the noindex tags and robots.txt rules you added to keep search engines out of the test environment — they are to be removed at launch.
• If the domain, HTTPS or www is changing, make these decisions separately; a domain change and HTTPS and www redirects require separate steps.

The map itself looks dull but is the most valuable output of the job: a two-column table, the old address on the left, the new address and the status code on the right. The lines below show the format of such a map; the addresses are examples.

1. /hakkimizda.html → /kurumsal/ · 301
2. /urun.php?id=14 → /urunler/orme-kumas/ · 301
3. /blog/2019/05/fuar-notlari/ → /yazilar/fuar-notlari/ · 301
4. /kampanya-2021/ → (no equivalent) · 410
5. /index.html → / · 301

What should be checked on launch day?

• Test every line of the map on the live site: is the status code correct, is the DESTINATION address the one in the map, does the destination page return 200?
• Test all of them, not a few random addresses. A map with a hundred lines is tested with a tool, not by hand.
• Remove the noindex and robots.txt blocks left over from the test environment; open and read the live site’s robots.txt file.
• Submit the new sitemap to Search Console. If the domain changed, use Search Console’s Change of Address tool.
• Switch internal links from old addresses to new ones; having your own site pass through your own redirects is an unnecessary step.
• Type a non-existent address by hand and see that it really returns 404; if the error page returns 200, that is a soft 404.

How long should you monitor after launch?

Google recommends keeping redirects in place for as long as possible, generally at least one year; the reason is that it takes time for old links on other sites to be recrawled and passed to the new addresses. That is also why monitoring does not end the day after launch. In the first weeks, watch for increases in 404 and redirect errors in Search Console’s page indexing report, and for impressions of old and new addresses in the performance report. The schedule, and which report to read how often, are in the post-migration monitoring guide.

• First week: new 404s and redirect errors in the page indexing report. Every new 404 is a line forgotten in the map.
• First month: are impressions of the old addresses falling and those of the new ones rising? If both fall together, look not only at the redirects but also at the content of the new pages.
• Three months: tell the most important sites linking to you about the new address; the redirect works, but a direct link is one step shorter.
• At least one year: do not switch off the redirects or the old domain.

What about deleted pages?

Not every old page needs a counterpart on the new site. For a page with no equivalent, the right answer is not to redirect it to an unrelated page but to return 404 or 410. Google’s own help page states that 404s do not harm the indexing or ranking of the rest of the site. When to use a 301 and when a 410 is detailed in the 404 error guide.

What did we measure on this site?

On 22 August 2026 Search Console knew 93 addresses for this site; the site had 58 pages. The difference was not missing pages: it was the non-www, http, no-trailing-slash and /index.html versions of the same pages. We measured on the live site that all of them were consolidated to a single address with a 301 or 307. The lesson: the number of addresses Google knows is always higher than your page count — the inventory is built from what Google sees, not from your page list.

The second lesson came from an error log. For a while this site’s live verification tool looked only at the final status code. One address was redirecting to a different page than expected, and because that page returned 200, the tool counted the line as “passed.” Since 22 September 2026 every line also checks the destination address. To count a redirect as “working” you have to see that it goes to the right place; the status code alone does not tell you that.

The third record comes from the past: another site was previously live on this domain. In September 2026, 70 addresses appeared as 404 in Search Console’s list of non-indexed pages; every sample we tested on the live site was left over from that previous site. Google remembers old addresses for a long time and keeps retrying them. This is the cost of not compiling an address list during a redesign: even after the removed site is gone, its addresses keep showing up in the report.

Redesigning a site means giving every address Google knows an answer on the new site.

Does it make a difference when moving from WordPress or another platform?

The principle stays the same; the job gets bigger. When the platform changes, the address pattern changes too: post addresses that contain dates, category and tag pages, product addresses with query parameters. Each pattern becomes a separate rule in the map. On top of that, the things the old system did automatically through a plugin — sitemap, title and description fields, structured data — must be rebuilt in the new system. Details are in the guide to moving from WordPress.

Should the migration happen all at once or in stages?

For small and medium-sized sites, Google recommends moving all addresses at the same time, so the new structure is recognized faster. On very large sites, moving section by section is an option because it makes problems easier to monitor. Most corporate sites fall into the first group: a single launch day and a single map tested in advance.

No item on this list guarantees that rankings will stay the same after the migration; no process can guarantee that. The list only eliminates the loss that is in your hands: the lost address, the wrong redirect, the forgotten block. The rest is determined by Google’s recrawling, and its timing can only be seen by monitoring.

If you don’t want to lose traffic while relaunching your site, website redesign and migration inventories the old addresses, builds a chain-free 301 map and monitors the site for 90 days after the move.