Website redesign without losing SEO rankings, a business checklist

Home / Blog / Website redesign without losing SEO rankings

A redesign is usually a good decision. The site looks current, the content is easier to read, forms work properly on a phone, and enquiries improve. The risk sits underneath the design. Your current website has pages that rank, other sites linking to specific URLs, and content that answers what people search for. A redesign that ignores those can produce a better-looking website that brings in less business.

Website redesign SEO is the work that prevents that outcome. Most of it costs very little when it is planned early and a great deal when it is discovered after launch. One honest point before the checklist: even a well-run project can see short-term movement in search results while Google recrawls and reprocesses the site. Google says plainly that temporary ranking fluctuation is normal during a move, and that for medium-sized websites it can take a few weeks or more for its systems to start showing new URLs instead of old ones. The goal is not a promise of zero movement. It is to avoid permanent, avoidable losses and to settle quickly.

This is a practical checklist for before, during and after a redesign, with tables you can lift into your project plan. It is written for business owners, marketing managers and website managers in Dubai and the UAE, and the technical guidance follows Google's own site move and redirect documentation, linked at the end.

How a website redesign can affect SEO

The risk depends on what actually changes. People use the word redesign for three quite different projects.

Google's advice for the third group is worth taking literally: change only one thing at a time. Moving hosting, switching CMS, changing the domain and relaunching a new design in the same release makes any problem far harder to diagnose, because you cannot tell which change caused it. Where the project allows, separate the moves by a few weeks. On large sites, Google also suggests splitting a move into smaller steps and testing one section first.

Within any of these projects, the changes that actually move rankings are usually the same short list. URLs change without redirects. Content is cut because it looked long in the new layout. Navigation changes, so internal links to important pages disappear. Text that used to sit in the HTML now loads through scripts. Page performance drops under heavier design assets. Or a staging rule that blocked search engines goes live with the site.

Before the redesign, record your SEO baseline

You cannot protect what you have not measured, and you cannot prove recovery without a starting point. Do this before design work begins, not before launch.

• Crawl the whole site and export every URL with its status code, title, meta description, H1, canonical tag, indexability and word count. This file becomes your before picture.
• Export Search Console data for the last 12 months: clicks, impressions and average position by page and by query, plus the page indexing report.
• Export GA4 data for the same period: organic landing pages, sessions, conversions, enquiries and revenue.
• List the pages that earn. Traffic is only one measure. Include the pages that generate calls, form fills, WhatsApp messages and sales.
• Check your backlinks and note the exact URLs other sites link to. Those URLs must survive or redirect.
• Save the content. Keep a copy of every page's text, so nothing is lost if a page is deleted during the build.
• Note the technical setup that already works: sitemap location, robots.txt rules, structured data types, hreflang tags and any existing redirects.

Keep all of it in one shared folder that design, development, content and SEO can all see. Every later decision refers back to it.

Agree who decides and who signs off

Most redesign damage comes from a gap between suppliers, not from a lack of skill. The designer assumes the developer will handle redirects. The developer assumes the agency exported the old URLs. Nobody owns the sitemap.

Before work starts, write down four things: who approves which pages are kept, changed or retired; who owns the URL map; who implements and tests redirects; and who checks the site on launch day. Put names next to those roles, not company names. The checklist table further down has an owner column for this reason.

Protect your highest-value pages and content

With the baseline in front of you, decide what happens to every page: keep as is, improve, combine with another page, or retire. Make that call with the data visible, not with the wireframe.

The most common mistake is not deleting a page. It is keeping the page and stripping its content. A service page that ranked because it answered fifteen practical questions becomes a clean layout with three short paragraphs and a large photo. The design improves and the page stops matching what people were searching for.

Where pages are combined, move the useful content into the surviving page instead of dropping it. Where pages are retired, check for links and traffic first, then redirect them to the closest relevant page. A redesign is also a good moment to fix genuine duplication, where several thin pages compete for the same search, by merging them into one stronger page.

Plan your URLs and redirects before development

Keep existing URLs wherever they are still accurate. There is no search benefit in changing a working URL because the page has a new design. Change them only when the structure genuinely improves or a platform move forces it. Every URL you keep is a redirect you never have to write, test or maintain.

When URLs do change, build the mapping sheet before development starts. Pull the old URL list from your crawl, your sitemaps, analytics and server logs, so you catch pages that are linked but rarely visited.

Google's guidance on redirects is specific, and it is worth following exactly.

• Use server-side permanent redirects where technically possible, meaning 301 or 308. Google treats those as a strong signal that the new URL should be the canonical one. A 302, 303 or 307 is temporary and tells Google the old URL may still belong in results.
• Use JavaScript redirects only when a server-side or meta refresh redirect is impossible.
• Map one to one. Sending many old URLs to a single irrelevant destination such as the homepage can be treated as a soft 404, which means the redirect achieves nothing.
• Keep chains short. Googlebot follows up to ten hops, but chains slow users down, so keep them under three and ideally at one.
• Keep redirects live for at least a year. Google recommends keeping them as long as possible so all signals transfer.
• Do not worry about lost link credit. Google states that permanent redirects pass PageRank, so a correctly redirected page does not lose the value of its links.

Test the full redirect list on staging before launch, and again on the live site within the first hour.

Build SEO into the new design and development

These decisions cost almost nothing while the design is still editable. Our website design and development services in Dubai handle them inside the build rather than as a repair job afterwards.

• Navigation and internal links. Confirm your most important pages are still reachable from the main navigation and linked from related content. A page that loses its internal links loses visibility even when its URL is untouched. Update internal links to point at the new URLs directly rather than relying on redirects.
• Headings. One clear H1 per page, with H2s that describe content rather than layout.
• Crawlable content. Important text belongs in the HTML. Content inside accordions and tabs is fine when it is present in the page source rather than fetched on click.
• Metadata. Carry over or improve titles and meta descriptions page by page, and make sure a template does not overwrite them with one title sitewide.
• Canonical tags. Self-referencing canonicals on standard pages, correct handling of filters, sorting and pagination, and no canonicals left pointing at staging or the old domain.
• Structured data. Rebuild whatever the old site had, such as organisation, breadcrumb, product, service, article or FAQ markup, and validate it before launch.
• Images and media. Descriptive file names, alt text, modern formats and correct dimensions, so a heavier design does not slow the site.
• Core Web Vitals. Test loading, interaction responsiveness and layout shift on real mobile devices during development, on a normal mobile connection rather than office wifi.
• Arabic and English. If you run both, keep each language on its own URL, connect them with hreflang tags, carry those annotations across to the new URLs, and check that right-to-left layouts, navigation, forms and phone fields work properly in Arabic.
• Server capacity. Google crawls a moved site more heavily than usual for a period, so make sure hosting can take the extra load in the first weeks.

Platform choice belongs in this conversation. Moving to or from WordPress website development changes URL patterns, plugin behaviour, metadata handling and redirect management, so plan the URL map around that decision rather than discovering it mid-build. If hosting changes without URLs changing, lower your DNS TTL to a few hours at least a week beforehand so the switch propagates quickly, and expect a brief dip in crawl rate straight after the change before it climbs again.

The pre-launch SEO checklist

Give every check an owner and a date. A shared sheet beats a conversation.

The crawl comparison in row four is the check most projects skip and the one that catches the most problems. Crawl the staging site, put that export next to your baseline export, and look for pages that lost their title, lost their H1, became non-indexable, or disappeared entirely.

Launch-day checks that protect search visibility

Do these in the first hours, while everyone involved is still available.

1. Confirm the site is live on www and non-www, over HTTPS, with a valid certificate.
2. Check indexing controls. Confirm the staging block is gone from robots.txt, and that no important page carries a noindex tag or leftover password protection.
3. Test your top old URLs. Take the top 20 pages by traffic and links, open each old URL and confirm a permanent redirect to the right new page, with no chain.
4. Test the new priority URLs. Confirm they return 200, render correctly on mobile and show the intended content.
5. Submit the new sitemap in Search Console. During a URL change it helps to also submit a sitemap of the old URLs for a short period, so Google discovers the redirects faster, then remove it once the old URLs drop out.
6. Inspect priority pages with the URL Inspection tool and request indexing for the most important ones.
7. Run a full crawl of the live site and check for 404s, redirect chains, missing titles and non-indexable pages.
8. Verify tracking. Confirm GA4 is receiving data and that form submissions, call clicks and WhatsApp clicks are recording as conversions.
9. Submit a real enquiry through every form and confirm it reaches the inbox and the CRM.
10. Update the links you control elsewhere: Google Business Profile, social profiles, directory listings, email signatures, email templates and the destination URLs in every live ad campaign.

If the move involves a new domain or subdomain, also submit a Change of Address request in Search Console for every verified variant of the old domain.

Monitor SEO performance after the redesign

Review weekly for the first month, then monthly. Compare against the baseline you saved, and always at page level, because a stable site total can hide a collapse on your three most valuable pages.

Before treating a drop as a ranking problem, check whether tracking broke. A missing GA4 tag on one template produces an alarming chart and has nothing to do with search. Search Console is the safer reference here, because it does not depend on your site's tracking code.

Common website redesign SEO mistakes

• Deleting pages that earned traffic or links, with no replacement and no redirect.
• Redirecting everything to the homepage instead of mapping page to page, which can be treated as a soft 404.
• Leaving the staging noindex tag or a robots.txt block live on the new site.
• Cutting useful content because the new layout looks better with less text.
• Removing internal links, so important pages sit with nothing pointing at them.
• Losing titles, meta descriptions, structured data or hreflang tags in the rebuild.
• Using temporary redirects where permanent ones are needed.
• Building long redirect chains, often by stacking a new redirect on top of an old one.
• Changing the domain, the platform, the hosting and the design in a single release.
• Launching late on a Thursday before a long weekend, with nobody available to check.
• Forgetting old sitemaps, feeds, ad campaign URLs and hard-coded links in email templates.
• Removing redirects after a couple of months because the old URLs looked quiet.

What to check if traffic drops after a redesign

Work through this in order. Most drops are explained in the first four steps.

1. Tracking. Is the analytics code on every template, and are conversions still firing?
2. Availability. Is the site up, fast and returning 200 for its main pages, including from a mobile connection?
3. Indexing controls. Check robots.txt, noindex tags, canonical tags and any password protection left in place.
4. Redirects. Crawl your old URL list and find anything returning 404, chaining, or landing on the wrong page.
5. Content. Compare the new version of your top pages against the saved old version and restore what was cut.
6. Internal links. Check whether priority pages lost links from the navigation, footer or related content.
7. Rendering. Use the URL Inspection tool to see the page as Google renders it, in case key content now loads only through scripts.
8. External factors. Check whether a Google update, a seasonal pattern or a paid campaign that ended explains part of the change before rebuilding anything.

Fix what you find, request indexing on the affected pages, and then allow time. Google says it can take a few weeks or more for medium-sized sites before new URLs replace old ones in search results, and longer for large sites. Nobody can promise a recovery date, and anyone who does is guessing.

Planning an SEO-focused website redesign with Tomsher

Tomsher Technologies runs redesigns with design, development and SEO inside one project, from our Dubai office and with a fully in-house team. In practice that means the URL map is agreed before the build starts, content decisions are made with Search Console data on the table, redirects are tested on staging and again on launch day, and the first month after launch is monitored rather than assumed.

If you are planning website redesign services in Dubai and your current site already brings in enquiries, the best insurance is to put search into the brief at the start. Send us your website and what you want the new one to achieve, and we will tell you which pages need protecting and what the redesign should change.

Frequently asked questions

Sources

• Google Search Central, Site moves with URL changes
• Google Search Central, Site moves without URL changes
• Google Search Central, Redirects and Google Search