How do you keep your Google rankings when rebuilding a website?

In website rebuild projects, design, colours and animations get talked about most. But for search engines, the critical issue is transferring the value the old site earned on Google to the new site correctly. Your old pages may have links from other sites and visibility for certain searches. If those pages disappear on the new site, that value is largely lost too.

The good news is that much ranking loss can be prevented. That requires planning the migration as a technical move project.

Why do rankings drop?

The most common causes of lost visibility in site rebuilds are:

• Old URLs changing without being redirected to the new addresses
• Removing or merging well-performing pages on the new site
• Page titles, descriptions and content changing significantly
• Internal link structure breaking
• Forgetting test-environment “no-index” blocks on the live site
• Page speed or mobile friendliness getting worse

Almost all of these causes can be prevented with careful preparation before launch. So SEO checks should not be treated as a last step added after the design is approved, but as part of the plan from the start of the project. Knowing which pages of the old site are valuable when the site structure, menu and page list are being decided helps both the design and content teams make the right decisions.

1. Make an inventory of URLs

The first step is listing every address on your old site. The list should include not just pages in the menu but blog posts, product pages, PDF files, images and campaign pages. Use these sources together for the inventory:

• The current site’s sitemap (sitemap.xml)
• Performance and page reports in Google Search Console
• The list of visited pages in your web analytics tool
• A crawl of the site with a crawling tool
• Pages that get links from other sites

Put this list into a spreadsheet and note for each URL whether it gets traffic, whether it has earned links and what its counterpart on the new site will be. This table will be the main document of the migration.

2. Prepare a 301 redirect map

A 301 redirect tells browsers and search engines that a page has moved permanently to another address. Every page whose old URL changes should get a 301 redirect to the most suitable new page.

A common mistake is redirecting all old pages en masse to the home page. This misleads both users and search engines and doesn’t pass on the pages’ value properly. Each old address should be redirected to the new page closest in content. Also avoid redirect chains (page A to B, B to C); where possible, each old address should go straight to its final destination.

3. Keep titles and content

The title tag, meta description, main heading (H1) and content of a well-ranking page are the basis of that ranking. Changing these elements completely in the new design can lead to the page being reassessed.

Our advice: keep the titles and content of pages that get traffic largely unchanged during the migration. If content improvements are planned, make them after the migration has settled, in a controlled and gradual way. That way you can tell the effect of one change apart from the others.

Also check that these technical elements work correctly on the new site:

• Canonical tags
• Alt text for images
• Structured data markup
• Language and region tags (hreflang) on multilingual sites
• Internal links pointing to new addresses, not old ones

4. Close the test site safely and plan launch day

A new site is usually built in a test environment, with blocks to keep it out of search engines. The most commonly forgotten thing on launch day is removing these blocks. If a rule blocking the whole site stays in robots.txt, or a tag telling search engines “no-index” stays on pages, the site may start dropping out of search results.

Conversely, leaving the test environment public and indexable is also a problem, because it puts the same content at two different addresses. Password-protecting the test environment and closing access after launch is the safest approach.

Tips for launch day

Schedule launch day for a time when the team and developer are available. With migrations done at the weekend or before a holiday, a problem may not be fixed quickly even if it’s spotted. Right after launch, run these checks:

• Pick a sample of addresses from the redirect map and test them one by one in a browser.
• Check that the home page, service pages and contact form work.
• Check that analytics and measurement tags are collecting data on the new site.
• Keep a backup of the old site somewhere you can turn to if needed.

5. After launch: sitemap, Search Console and 404 tracking

Sitemap and Search Console

After the new site goes live, submit the current sitemap to Google Search Console. The sitemap should only contain pages that are live, not redirecting, and that you want indexed.

If the domain is changing as well, you may need to use the change of address tool in Search Console. Check Google’s official Search Console help pages for the current conditions and steps; the platform changes from time to time.

In the days after launch, track these Search Console reports regularly:

• Page indexing report: which pages are indexed, and which have errors?
• Performance report: how have impressions and clicks changed?
• Sitemap status: are there errors in the submitted sitemap?
• Experience reports: are there issues with mobile use or page experience?

Tracking 404 errors

However carefully you prepare, you’ll find after launch that some old addresses were missed. So monitoring 404 errors regularly in the first weeks is essential. Search Console’s page reports, server logs and a crawling tool can be used together for this.

Update your redirect map for every important 404 address you find. Addresses that receive links from other sites or have brought traffic in the past should take priority. Where possible, also ask important sites that link to you to update their links to the new address; redirects work, but a direct link is always healthier.

Don’t remove redirects soon after launch. Old addresses live on for a long time in emails, print materials, catalogues and on other sites. Keeping redirect rules permanently also makes any future migration easier.

6. Read the migration dip correctly

Even after a well-executed migration, it is normal to see some fluctuation in rankings after launch. Google needs time to recrawl and reassess the new structure. Making constant changes in a panic during this period can make things worse.

While the fluctuation lasts, the things to do are: fix errors, complete redirects, then wait and watch. But if particular pages show long, unexplained drops, their content, redirects and technical state should be examined separately.

Site rebuild checklist

1. A full URL inventory of the old site has been made.
2. Pages with traffic and inbound links have been flagged.
3. A 301 redirect target has been set for every old URL.
4. Mass redirects to the home page and redirect chains have been avoided.
5. Titles, descriptions and content of important pages have been kept.
6. Canonical tags, structured data and internal links have been checked.
7. Robots.txt and “no-index” blocks have been removed on the live site.
8. The test environment has been password-protected and closed to indexing.
9. The new sitemap has been submitted to Search Console.
10. 404 errors and index reports were monitored regularly in the first weeks.

Conclusion

Rebuilding a website, when planned properly, is a big opportunity to strengthen your brand without risking your rankings. A URL inventory, a careful redirect map, preserved content and regular monitoring after launch are the foundation of the process. If you’re curious how we handle corporate website projects in Gebze together with the SEO migration, see our web design and SEO page.