The story arrives in our inbox a few times a year: a company launched its beautiful new website and its Google traffic fell off a cliff, and now, months later, someone wants to know why. The cause is almost always the same. The redesign changed the site's addresses and structure, nobody mapped the old signals to the new pages, and years of earned ranking equity evaporated on launch night. It's entirely preventable, and prevention is cheap compared to recovery.

Why redesigns kill rankings

Google's understanding of your site attaches to URLs. Every address has history: links pointing at it, rankings earned by it, user signals accumulated on it. A typical redesign changes URLs (new structure, new slugs), removes pages that were quietly earning traffic, and rebuilds fast pages as slow ones. Each change severs a signal, and severed signals don't transfer themselves. Google's own guidance on site moves says it directly: without redirects, the new pages start over.

The checklist we run, in owner's language

Inventory before anything. Export every URL the old site has, from Search Console and analytics, ranked by traffic and by what ranks. This is the map of what you're about to risk. Redesigns that skip this step are flying at night. Map every old URL to its successor. Page by page. Where content merges, the old address points at the merged page; where a page truly dies, it points at the closest living relative. The result is a redirect table, and building it is tedious, which is exactly why it gets skipped by vendors billing by the launch. Ship permanent redirects on launch day. The 301 redirect is how you tell Google "the equity of the old address belongs to the new one." Launch without redirects and every inbound link on the internet now points at an error page. This single omission causes most redesign traffic collapses we're asked to autopsy. Preserve what was working. If a page ranked, its new version keeps the substance that earned the ranking: the topic, the depth, the questions answered. Redesigns often "clean up" long pages into elegant thin ones and delete the ranking content along with the clutter. Beauty and substance are not rivals; keep both. Relaunch faster, not just prettier. A redesign is your one cheap chance to fix performance architecture. If the new site paints slower than the old one, you've paid to move backwards; our [Core Web Vitals guide](/blog/website-speed-core-web-vitals-gcc-conversion) covers what the numbers should look like. Watch the instruments for a month. Search Console after launch: crawl errors, coverage, the performance graph. A dip in the first week or two is normal while Google re-reads the site. A dip still deepening in week four means something on this list was skipped, and early detection is the difference between an adjustment and an archaeology project.

The bilingual layer

In this market, redesigns often add or restructure the Arabic side. Every rule above applies per language, and the hreflang pairing between the two must survive the move intact. Get it wrong and the languages start competing against each other, a quiet failure mode that shows up as slow bleed rather than sudden drop. A redesign should be the moment your ranking curve steepens, not the moment it resets to zero. That outcome is a checklist, run by people who've run it before. When we take on [redesign work](/services/web-development), the migration table is part of the deliverable, and traffic continuity is part of the definition of done. If your last redesign came with neither, the recovery is also a defined project, and sooner beats later.