How to redesign your website without losing your rankings (or AI visibility)

A website redesign is one of the few routine business decisions that can quietly destroy years of accumulated visibility in a single afternoon. It happens constantly: a business launches a beautiful new site, and within weeks the enquiries dry up, the rankings slide, and nobody can say why.

The why is almost always the same. The new site changed URLs without redirects, dropped content that was quietly earning citations, or shipped with a setting that told search engines to ignore it. None of these are design problems. All of them are preventable with an unglamorous checklist.

Before you start: know what you are protecting

You cannot protect what you have not inventoried. Before any design work begins:

• List every page that earns its keep. Which pages bring search traffic, which get cited in AI answers, which convert. Your analytics and a diagnostic scan will show you. These pages are load-bearing walls: move them carefully, never demolish them casually.
• Record your current state. Run a scan before the rebuild so you have a baseline health score and AI visibility score to compare against after launch. Without a baseline, you will not know whether the new site helped or hurt until the damage shows up in revenue.
• Decide the URL map early. Every old URL needs a documented destination on the new site. The best destination is the same URL. Where that is impossible, the new URL should be decided before development starts, not discovered after launch.

During the build: parity is the rule

The design can change as much as you like. What needs parity is everything underneath it:

• Redirects, one to one. Every changed URL gets a permanent (301) redirect to its specific replacement. Redirecting everything to the homepage is the classic shortcut, and it throws away the relevance of every individual page. Search engines treat it accordingly.
• Content parity on load-bearing pages. If your "hot water repairs Sutherland Shire" page earns rankings and citations, the new site needs a page that answers the same need at least as well. Consolidating ten thin pages into three strong ones can be a good move. Deleting the content that earned your visibility is not.
• Schema parity. If the old site emitted LocalBusiness, Service, or FAQ markup, the new one must too. Templates rarely carry this across automatically; check it explicitly against our schema starter guide.
• Watch the staging site. Staging environments should be blocked from indexing, and the live launch must remove that block. Both halves of that sentence have burned businesses: a staging site that leaks into Google, or worse, a launch that ships with noindex still switched on. Make "remove the noindex" a named launch-day task with a named owner.

After launch: watch, then verify

The first weeks after launch are when problems are cheapest to catch:

• Re-scan immediately. Compare against your baseline. A drop in crawlability, speed, or structured data is far easier to fix in week one than to diagnose from a revenue dip in month three.
• Check the redirects in the wild. Click through from your old URLs (search results, old links, your own bookmarks) and confirm they land where intended.
• Expect some settling, but watch the trend. Rankings and AI citations commonly wobble for a few weeks after a migration while systems re-crawl and re-evaluate. A wobble that becomes a slide is the signal to investigate. This is exactly the window where fortnightly monitoring earns its keep: it turns "something feels quieter" into a measured trend you can act on.

AI visibility adds one more reason to be careful

Generative engines cite pages they have already learned to trust. When a trusted page disappears or changes address without a clean redirect, the model's confidence in citing you goes with it, and rebuilding that trust is slower than preserving it would have been. The same parity rules protect you: keep the content, keep the structure, redirect the URLs, and give the systems that cite you no reason to drop you.

Website redesign FAQs

Will I lose rankings after a redesign?

If URLs, content, and structured data carry across cleanly, most sites hold their position after a short settling period. Losses happen when redirects are missing or sloppy, content is deleted, or technical settings regress. In other words: losing rankings is not an inherent cost of redesigning. It is a symptom of a rushed migration.

How long should redirects stay in place?

Treat 301 redirects as permanent. Google's own site-move documentation says to keep them for as long as possible, generally at least a year, and from a user's perspective to consider keeping them indefinitely. In practice: keep them for as long as the old URLs exist anywhere, in search indexes, in directories, in other sites' links, in AI training data. The cost of keeping a redirect is near zero. The cost of removing one too early is a dead link wherever your old URL still lives.

Can I change my domain name at the same time?

You can, but you are stacking two migrations on top of each other, and if visibility drops you will struggle to tell which change caused it. If a domain change is genuinely needed, do it separately from the redesign, with its own redirect map and its own monitoring window.

My developer says the new platform handles SEO automatically. Is that true?

Modern platforms handle the basics well: clean markup, mobile rendering, sensible defaults. What no platform can automate is your migration: which URLs map where, which content carries across, which schema is emitted. Those are decisions, not features. Ask your developer for the redirect map and the content inventory. If those documents do not exist, the platform's automation will not save you.

How soon after launch will I know if something went wrong?

Technical regressions show up immediately on a scan: crawl errors, missing schema, slower pages, broken redirects. Ranking and citation effects take longer to surface, typically weeks. That order is your friend. Catch the technical issues in week one and the slower-moving effects mostly never arrive.

Should I bring in a specialist, or can my web designer handle it?

A good designer or developer can execute everything on this checklist. The question is whether migration planning is explicitly in their scope, because by default it often is not: design briefs say "make it look better", not "preserve every earning URL". If your site has meaningful search or AI visibility to lose, having a specialist own the migration plan while the designer owns the design is the cheap insurance option.