Redesigning Your Website Without Losing Your Google Rankings

A redesign changes the thing Google has spent years learning about: your pages, your URLs and the links between them. Done carelessly, it throws that away on launch day. Done carefully, search barely notices.

The difference is not luck. Google publishes how it handles a site change, and most redesigns that lose traffic broke something that guidance covers. This is the practical version, using only what Google itself says, for UAE businesses whose enquiries depend on the site being found.

Decide first: does anything change in the URLs?

Google splits the problem in two, and your risk depends on which one you are in.

• Visual redesign, same URLs. New layout, same addresses. Google's guide for changes that do not affect user-visible URLs is its hosting-change guide, and the testing and verification advice there applies.
• URLs change. New structure, new slugs, a new platform or a new domain. This is a site move with URL changes, and it carries the real risk. Google says you may see ranking fluctuations while it recrawls and reindexes.

Our recommendation: keep the URLs of pages that already bring you enquiries exactly as they are, unless there is a strong business reason to change them. Every address you keep is a redirect you do not have to get right. Google also advises planning changes one after the other, not everything at the same time. That argues against moving domain, platform, structure and design in a single launch.

Before launch: build the inventory

Google's guidance is direct: it is important to map your old site's URLs to the URLs on the new site. You cannot map what you have not listed.

1. Crawl the live site and export every indexable URL, with its title, H1 and meta description.
2. Add what search and visitors already use. Pull the pages that earn clicks from the Search Console Performance report, and pages with inbound links or conversions from your analytics. Those are the pages you cannot afford to lose.
3. Decide each URL's fate: keep, replace with a closer equivalent, or retire.
4. Keep what ranks. Where a page already performs, carry over its content, title and structure rather than rewriting it for the new look. Google does not publish a formula for which on-page elements matter most, so treat the existing page as evidence, not as clutter. A new design is not a reason to rewrite a page that works.

The redirect map

For every old URL that will not exist, decide where it should redirect. Google says permanent redirects such as 301 and 308 do not cause a loss of PageRank. How you implement them matters, though.

• Server-side, not JavaScript. Google says a server-side redirect has the highest chance of being interpreted correctly. JavaScript redirects are the last resort, and rendering can fail.
• One page, one best match. Do not redirect many old URLs to one irrelevant destination such as the new home page. Google says this can confuse users and might be treated as a soft 404.
• No chains. Google's advice is to avoid chaining redirects, because it adds latency and not every browser or user agent supports long chains. Point each old URL straight to its final address, including old addresses that already redirect somewhere.
• Keep them. Google says to keep the redirects for as long as possible, generally at least one year, so it can transfer signals to the new URLs.

Staging: the mistake that is easy to miss

The new site needs testing, and Google's own advice is to test in an environment that is private or at least kept out of search. Its hosting guide suggests a testing environment, perhaps with IP-restricted access, and, for public testing, a temporary hostname with a noindex rule.

That is where the launch-day mistake lives. Google's site-move guide notes that some owners block all crawling while in development, and says to remove any noindex or robots.txt blocks that were only needed for the migration. Two rules follow:

• Check both on launch day. A noindex meta tag or header, and a blanket Disallow in robots.txt, are the two things most likely to travel from staging to the live site unnoticed. Google's Search Console page indexing report flags URLs marked noindex and URLs blocked by robots.txt.
• Do not use robots.txt to hide staging. Google says robots.txt is not a mechanism for keeping a page out of Google, and that if a page is blocked by it, the crawler will never see a noindex rule on that page. Use noindex or password protection, as Google advises.

Then test the live site as Google does. The URL Inspection tool in Search Console runs a live test of a URL, so you can see whether Google can index it.

Bilingual English and Arabic: hreflang breaks quietly

If your site serves both languages, the language tags are part of what you are migrating. Google's rules for localized versions are strict and easy to break in a redesign:

• Return links are required. If two pages do not both point to each other, the tags are ignored.
• Each version lists itself as well as every other language version.
• URLs must be fully qualified, including https. Relative URLs are not acceptable.
• Codes must be valid: ISO 639-1 language codes, with ISO 3166-1 Alpha 2 region codes where used.
• Optional x-default covers users whose language matches none of your versions.

When URLs change, Google says to update the annotations to use the new URLs. A new template that outputs the wrong English-to-Arabic pairing, or only one side of it, silently cancels the tags. Check them on a sample of pages in both directions before launch. Our guide to Arabic SEO in the UAE covers the wider strategy, and Arabic RTL website design covers the design side.

Canonicals, titles, structured data and sitemaps

• Canonicals. Google says each new URL should have a self-referencing rel="canonical" tag, and not to specify different canonical URLs for the same page using different techniques. Templates are the usual culprit: a canonical that still points at the staging domain or the old URL is a signal in the wrong direction.
• Internal links. Change the internal links on the new site from old URLs to new URLs. Do not rely on redirects to carry your own navigation.
• Titles. Google says every page should have distinct descriptive title text and to avoid repeated or boilerplate text in titles. A template that gives every page the same title is a common redesign regression. Google may also rewrite titles that do not match the page.
• Structured data. Google says not to mark up content that is not visible to readers, and that the data must be a true representation of the page. If the redesign moves or removes content, update the markup to match.
• Sitemap. Submit the new sitemap in Search Console. Google says this can make discovery quicker. A sitemap does not guarantee crawling or indexing, so it supports good redirects and internal links, not replaces them.
• Speed. Google highly recommends achieving good Core Web Vitals. A redesign with heavy new imagery or scripts can undo that. See our guide to Core Web Vitals and INP, and test the new templates before launch rather than after.

Change of Address: only for domain moves

Google's Change of Address tool is for moving from one domain or subdomain to another. It is not for moving pages around within one site. For those, Google's instruction is to add redirects and update your sitemaps.

If you are changing domain, the tool works only on domain-level properties, you need to be an owner of both properties under the same Google account, and Google expects the 301 redirect from the old homepage to the new one to be in place first. Google's site-move guide also says to submit the Change of Address for the old site. If your domain stays the same, skip it.

After launch: what to watch and what to expect

Google tells you plainly to expect temporary fluctuation in rankings during a move. For a medium-sized site, it can take a few weeks or more before Google gradually shows the new URLs, and larger sites take longer. We will not offer you a recovery number, because Google does not give one and no honest agency can.

What to do in the first weeks:

1. Day one. Fetch the live robots.txt and view source on the home page and a few templates for noindex. Confirm the sitemap is submitted. Spot-check old URLs: each should return a single redirect to the right page.
2. Watch the Page indexing report in Search Console for new errors, and check the report for unexpected spikes in URLs marked noindex or blocked by robots.txt.
3. Compare periods in the Performance report. Google's traffic-drop guide describes the Date filter's Compare tab, and says to check every tab to see whether the change affects only certain queries, URLs, countries, devices or search appearances. A drop confined to one section usually points at one broken template or redirect rule.
4. Keep the old Search Console properties. Google says to verify data for each property separately.
5. Do not make more large changes while Google is still sorting out the first ones.

If a technical fault is behind a drop, Google notes that page-level problems such as a stray noindex usually cause a slower decline, because Google has to recrawl the page first. That is another reason to check on day one and not wait for the graph to tell you.

The checklist

Before launch

• Full inventory of old URLs, with traffic and links per page.
• Decision recorded for each URL: keep, redirect or retire.
• Redirect map: server-side, one hop, specific matches, tested in staging.
• High-performing pages keep their content, titles and URLs wherever possible.
• Staging kept out of search with noindex or authentication, not with robots.txt alone.
• Self-referencing canonicals, internal links, hreflang pairs and structured data point at the new live addresses.
• New sitemap ready; Core Web Vitals tested on the new templates.

Launch day and after

• Remove staging noindex and any Disallow: /, then confirm both on the live site.
• Submit the sitemap; spot-check redirects, hreflang and canonicals.
• Domain change only: submit Change of Address for the old site.
• Monitor Page indexing and Performance reports for several weeks.
• Keep the redirects live for at least a year.

Where this fits in the build

None of this is difficult, but all of it is easy to skip when a launch date is fixed and the focus is on how the site looks. If you are rebuilding, ask whoever builds it for the URL inventory and redirect map before design sign-off. We can help with that on a custom website or a WordPress rebuild. If you are still deciding on the platform itself, our comparison of WordPress and a custom website is the place to start, and if local discovery drives your enquiries, read local SEO for UAE businesses before you touch the structure.

Planning a redesign and worried about your rankings? Tell us about the site and we will tell you what to protect before anything is rebuilt.

Guidance is as published by Google Search Central and Search Console Help on or before 13 November 2026. Google updates these documents; check them before a launch.