Redesigning a website without losing Google rankings

Most redesigns are presented as a visual upgrade, but I’d start by identifying what the existing website already does well. Which pages attract relevant visitors? Which generate inquiries? Which have useful links pointing to them?

The redesign should improve the customer experience while protecting valuable content and working paths into the website. I would avoid changing URLs, removing useful pages, or replacing detailed content simply to make the site look cleaner.

On my website projects, protecting useful existing content and search visibility is an important planning concern.

I would not claim that a rebuild preserved every ranking or increased traffic without the records to support it. A useful case study would include the original baseline, launch date, changes made, and subsequent traffic and inquiry patterns, with seasonal differences considered.

Before launch, I would inventory the existing URLs, review available Search Console and analytics data, and identify important content, links, and customer actions. I would also preserve a backup and establish a recovery plan.

Then I would map the old site to the new one. Useful URLs should stay the same where practical. If a URL changes, I would plan a permanent redirect to its closest relevant replacement—not send every old page to the homepage.

During development, I would check page titles, headings, internal links, canonical tags, intended indexing settings, images, and important functionality. The staging site should not accidentally compete with the public website.

At launch, I would test redirects, remove any unintended launch-blocking restrictions, verify the sitemap and preferred URLs, and check analytics, forms, calls, and booking links. Submitting a sitemap helps discovery; it does not guarantee rankings.

The problems I would be most concerned about are lost pages, broken URLs, missing content, accidental indexing blocks, and forms that no longer deliver inquiries. A new design can look finished while those issues remain underneath.

I would also avoid changing the domain, content, navigation, and every URL at once without a clear reason. The more changes we combine, the harder it can be to identify what caused a problem. That is a planning principle, not a claim that every redesign must follow the same process.

Before you redesign, know that no one can guarantee zero ranking movement. The goal is to reduce avoidable risk and detect problems quickly, not promise that search engines will respond exactly as we expect.

Ask whether the quote includes a content and URL inventory, redirect planning, tracking checks, and post-launch review. Also establish ownership and access to the domain, hosting, repository, and relevant accounts.

My focus is rebuilding on the platform I develop and support. A platform change should serve a practical need, and the migration plan should be part of that conversation—not an afterthought.

It would also help to monitor the important old and new URLs after launch, review indexing and crawl issues, and watch relevant traffic and inquiries. I would test the contact process again rather than rely only on automated reports.

The work log should record the launch, redirects, corrections, and follow-up findings. Permanent redirects need to remain available long enough for users and search systems to follow them; they should not be removed shortly after launch.

If performance drops, I would compare affected pages and searches with the baseline, then check technical changes, content changes, measurement problems, and seasonality before deciding what to fix.