Technical
Redesigning or moving your website without losing traffic
Ilyes Massoudi7 min readThe short answer
A redesign or a move loses traffic for one recurring reason: URLs change without a permanent redirect from old to new, so Google loses the pages that built their rankings over years. The checklist that prevents the loss: inventory every old URL with its traffic from Search Console before launch, a 301 redirect map from every old URL to its new equivalent page by page rather than to the homepage, preserved titles, content and hreflang, then daily checks of indexing and 404 errors in the first week. A new design does not raise rankings by itself, but it can drop them in a day.
Why sites lose traffic after a new design
The scene repeats across the Gulf every month: a company launches a new site, prettier and faster, and two weeks later traffic from search drops by half or more. In most cases the cause is not the design but what changed silently with it: the URLs.
The page that lived at /services/seo-audit now lives at /ar/services/audit, and Google knows only the first. External links point to the first. A ranking built over years is attached to the first. And the first now returns a 404. The new site starts from zero, and its owner believes Google “penalised” the design.
Before launch: the inventory
Launch nothing before you know what you own:
- A list of every existing URL. From the old sitemap, from a free crawler, and from the Performance report in Search Console exported to a file, with clicks and impressions per URL.
- The pages that receive external links. From the Links report. These are your most valuable assets, and their URL must never change without a redirect.
- The current titles and descriptions of every page that brings traffic. You will need them to compare after launch.
- The current hreflang and canonical tags, and the list of indexed pages from the Pages report.
This inventory is half the migration, and most developers do not know it exists because nobody asked for it.
The redirect map: page by page
The most important rule in the whole article: every old URL redirects permanently (301) to its closest new equivalent in meaning. Not to the homepage.
A blanket redirect to the homepage is treated by Google as a disguised not-found page, and the trust falls with it. An old page with no equivalent on the new site redirects to the nearest section, or is kept with its content if it brings traffic.
| Case | The correct redirect |
|---|---|
| Same page, new URL | 301 to the new URL |
| Two pages merged into one | 301 from both to the new one |
| Page deleted, close substitute exists | 301 to the substitute |
| Page deleted, no substitute, brings traffic | Do not delete it |
| Page deleted, no substitute, no traffic | An explicit 404 or 410 |
| Whole domain change | 301 from every URL to its equivalent on the new domain |
Beware redirect chains: old to intermediate to new. Redirect directly. And if the site was migrated before, the oldest URLs still need a direct redirect to the newest ones.
What not to change at the same time
A safe migration changes one thing at a time. If you change the design, the URLs, the content and the domain all at once, and then traffic drops, you will never know which change caused it.
The order I recommend: the new design with the same URLs and content first; then, after a month of stability, change URLs if you must, with redirects; then update content page by page. If it has to be one release, keep at least the titles and first paragraphs as they are.
For bilingual sites
This is where most Gulf migration errors happen:
- The Arabic version lived in an
/ar/folder and moved to a subdomain, or the reverse. Every Arabic page needs its own redirect. - Hreflang in the new theme points to the old URLs, or is absent because the developer built the theme from an English template.
- Arabic pages not migrated because “nobody asked for them”, returning 404 while the English ones are fine.
Review the hreflang guide before launch, and confirm every Arabic page has an equivalent on the new site and a redirect from the old one.
Launch day
- Test a sample of twenty important old URLs: does each redirect directly to its equivalent with a 301 status?
- Confirm the noindex tag that sat on the staging version has been removed. This is the most common day-one error.
- Submit the new sitemap in Search Console. If the domain changed, use the Change of Address tool.
- Check the new robots.txt; many themes ship with a blanket block rule.
- View the source of an Arabic page and search for the text and for hreflang.
The first two weeks
- Daily: the Pages report in Search Console for new 404 errors, and fix every one with a redirect.
- Daily: the Performance report, compared with the week before launch, page by page rather than in total.
- Once: PageSpeed Insights on mobile, because the prettier new theme is usually heavier.
- Once: the Links report after two weeks to confirm external links are counted for the new pages.
Fluctuation is normal for weeks. A persistent drop after eight weeks is a migration error, and the list above finds it.
When to request an audit
The best time for a full audit is before the migration, because it produces the inventory, the redirect map and the list of what must be preserved, and becomes a specification for the developer. The second time is eight weeks after a migration that caused a drop with no recovery. The Digital Presence Audit runs in both cases, and says exactly which URLs were lost and where their traffic went.