How to rebuild an old website without losing its SEO

Rebuilds lose search traffic for a short list of mechanical reasons. Addresses change and nothing redirects them. Pages that other sites linked to disappear. Redirects bounce through three or four hops, or all land on the homepage. The new pages send mixed signals: a canonical pointing one way, a sitemap listing another, internal links still aimed at old URLs. Nearly all of it can be checked before launch.

Rebuilding a live site is the easier case, because you can crawl it, export its analytics and read its Search Console history before anything changes. This guide also covers the harder one: a site that has already gone because the hosting lapsed, the domain dropped and was registered again, or an agency switched it off. There, the list of old addresses has to be reconstructed from evidence before any of the usual advice applies.

The sequence is the same either way: inventory, map, redirect, align, validate. The evidence you start with is not.

In the right-hand column, two things change. Your inventory will be incomplete however carefully you build it, so the plan needs a rule for the addresses you never found: a genuinely useful not-found page, and server logs watched closely after launch. And the newest picture you have of the old site may be well out of date.

In the same sample, 839 domains (11.48%) had no working homepage capture in the five years before the drop. Because the sample leans towards well-linked names, these figures describe it, not every dropped domain. The practical point holds either way: the structure you reconstruct from an archive is the structure the site had when a crawler last saw it working, often a year or more before the lapse. The full study is in what can actually be recovered from an archived website.

Google's site-move guide lists where to look for old URLs: your sitemaps, server logs or analytics for the URLs that get the most traffic, the Links report in Search Console, and your content management system. For a live site, use all of them and crawl it as well, because each source misses something. Sitemaps leave out pages nobody added, analytics misses pages nobody visited in the period you exported, and a crawl misses orphaned pages. The same guide says to transfer images and downloads such as PDFs, which "might already be getting traffic from Google Search or links", and to include embedded content (videos, images, JavaScript and CSS files) in the plan.

For a site that has gone, the inventory comes from public web archives such as the Internet Archive's Wayback Machine, archived copies of the old sitemap, backlink data, and whatever the previous owner kept: analytics exports, a CMS export, an old .htaccess file in a backup. Archives are a sample, not a backup. The Internet Archive says some sites are missed because its crawlers "were unaware of their existence at the time of the crawl", and that "If there are no links to your pages, the robot won't find it". Gathering, cleaning and ranking these sources is a job of its own, covered in how to recover old URLs and build a redirect map.

A redirect map gives each old URL a decision and, where it applies, a destination. Five decisions cover almost every case.

1. Keep. The page survives at exactly the same address. For any URL that matters this is the best outcome: nothing to redirect and nothing for search engines to relearn.
2. Redirect to the equivalent. The content moves to a new address that answers the same need, with one permanent redirect straight to the final URL.
3. Merge. Several thin or overlapping pages become one better page. Google's site-move guide allows this: "if you have consolidated content previously hosted on multiple pages to a new single page, you can redirect the older URLs to that new, consolidated page."
4. Retire. There is no equivalent and no reason to create one. Return 404 or 410, with a helpful not-found page.
5. Hold for a person. The evidence is unclear: a URL with links but no recoverable content, or a page about a product the new business does not sell. Decide it deliberately.

What a script must never do is default the leftovers to the homepage. Google's guide is specific: "Don't redirect many old URLs to one irrelevant single URL destination, such as the home page of the new site. This can confuse users and might be treated as a soft 404 error."

Google also advises against changing everything at once. If you are moving domain, changing CMS and redesigning, its site-move guide says to "do them one at a time". Its Change of Address help warns that if you combine a move with a redesign of the content and URL structure, "you will probably see some traffic loss as Google might need to relearn and reassess the individual pages." Keeping URLs where you can is the cheapest way to limit that.

HTTP status codes are defined in RFC 9110, the IETF standard for HTTP semantics. Google's handling overlaps with the standard but is not identical, and its documentation says so.

Google states that "301 and other permanent redirects don't cause a loss in PageRank", so there is no reason to avoid a permanent redirect where one is needed, though keeping the URL saves every visitor a round trip. Do not choose 410 because you have heard it clears pages from the index faster: Google's crawling documentation says "All 4xx errors, except 429, are treated the same". Use 410 when it is accurate. RFC 9110 says it is "primarily intended to assist the task of web maintenance" by telling clients the resource is intentionally unavailable.

Whatever you return for a retired page, the status code has to be real. A page that says "not found" but returns 200 is what Google calls a soft 404: "a URL that returns a page telling the user that the page does not exist and also a 200 (success) status code". Check your own not-found page rather than assuming. And prefer server-side redirects. Google reads an instant meta refresh as permanent, but warns that "if you set a JavaScript redirect, Google might never see it if rendering of the content failed."

Chains

Two Google documents give two numbers, and they answer different questions. The crawling documentation describes a capability: "Googlebot generally follows 10 redirect hops when crawling for general web content." The site-move guide gives the recommendation: redirect "to the final destination directly", and if that is not possible, "keep the number of redirects in the chain low, ideally no more than 3 and fewer than 5", because chains add latency and "not all user agents and browsers support long redirect chains."

Plan for one hop. Chains creep into a rebuild from three places: protocol and host rules stacked in front of path rules (http to https, then non-www to www, then old path to new path); redirects inherited from an earlier redesign that now point at addresses which redirect again; and CMS plugins that add redirects of their own. When you add a rule, rewrite any older rule that pointed at its source so that it points at the final destination. On a site that has gone, the archive's redirect captures show where the previous owner had already moved content, and your map should send those addresses straight to today's equivalent.

How long to keep them

Again there are two Google pages with two figures, and both are often misquoted.

• Google's site-move guide: "Keep the redirects for as long as possible, generally at least 1 year." It adds: "From users' perspective, consider keeping redirects indefinitely."
• Search Console's Change of Address help: "Maintain the redirects for at least 180 days--longer if you still see any traffic to them from Google Search." After the 180-day period, it says, Google "treats the old site as an unrelated site, if still present and crawlable."

The 180-day figure belongs to the Change of Address tool, which only applies to moves between domains or subdomains, and it is a minimum, not a removal date. For any rebuild, "at least 1 year" is the safer planning floor, and there is rarely a good reason to delete a working redirect at all. The same help page recommends continuing to pay for an old domain "for at least a year" after a move, so that nobody else can buy it and misuse it.

Google describes redirects and rel="canonical" annotations as strong canonicalisation signals and sitemap inclusion as a weak one, and says "these methods can stack and thus become more effective when combined." They can also contradict each other, which is how a rebuild ends up with Google choosing a different canonical from the one you intended.

Canonicals. Google's site-move guide says each new URL should have a self-referencing canonical. Use an absolute URL, put it in the <head> of the HTML the server sends, and make it match the URL in your sitemap and internal links. Google calls a canonical "a hint, not a rule", so an inconsistent site leaves it room to choose otherwise.

Internal links. Point every one at the final URL; the guide suggests using your mapping to "find and update the links as needed". Links that rely on redirects still work, but they add a hop for every visitor and keep old URLs in circulation. Check navigation, footers, body copy and anything hard-coded in templates.

Titles and headings. Each redirected page should plainly answer the same need as the page it replaces. You need not copy old titles word for word, but rewriting every one removes another piece of continuity. For a site that has gone, the archived copy shows the old titles and headings even where you cannot, or should not, reuse the old text.

Metadata set by JavaScript. Some site builders set the title, description and canonical in the browser. Google's JavaScript SEO guide says you can use JavaScript to set the meta description and the <title> element, but "The best way to set the canonical URL is to use HTML"; a noindex in the original HTML can stop rendering, so JavaScript that removes it "may not work as expected"; and Google "can only discover your links if they are <a> HTML elements with an href attribute." The quick test is to view the raw page source, not the inspector's rendered view, and check that the title, description, canonical and main links are already there. While you are there, confirm that any noindex tags or robots.txt blocks used on staging have gone. Google lists forgetting them among the common migration mistakes.

The new XML sitemap should list only final, indexable, canonical URLs that return 200: no redirects, no 404s, no parameter duplicates. Google's limit is "50MB (uncompressed) or 50,000 URLs" per sitemap file, so split larger sites with a sitemap index, and use "fully-qualified, absolute URLs".

Keep <lastmod> accurate. A rebuild is the moment many sitemap generators stamp every URL with the launch date, and Google's 2023 sitemap post explains the cost: "if your page changed 7 years ago, but you're telling us in the lastmod element that it changed yesterday, eventually we're not going to believe you anymore". The same post lists changes that do justify a new date: "if you changed the primary text, added or changed structured data, or updated some links". A rewritten page earns a new date; a restyled one does not. Bing says the same: "Avoid setting lastmod to the time your sitemap was generated unless the content on that URL was actually updated." Both search engines ignore <priority> and <changefreq>.

Old URLs are a less settled question. Google's site-move guide says at one point that you can remove your old sitemap once the new one is submitted. Its monitoring section describes submitting a sitemap of old URLs alongside the new one and watching the indexed count of old URLs fall towards zero, and calls the resulting redirect warnings "normal". For a site that has gone, a temporary sitemap of the recovered old URLs is one reasonable way to get them recrawled so the redirects are seen. Treat it as an option, not a rule, and take it down once they have dropped out.

URL Inspection "provides information about Google's indexed version of a specific page, and also allows you to test whether a URL might be indexable." Use it on your most important new URLs, with two limits in mind. Google's chosen canonical can be determined "only in the indexed data"; the live test "cannot predict" it. And Google's own documents disagree about redirects: the site-move guide suggests the tool for testing individual redirects, the Page indexing help says "The live URL Inspection test follows redirects and then tests the final URL", and the crawling documentation says "Google Inspection Tools doesn't follow redirects". Test redirects with a tool that shows every hop and its status code, and inspect the destination pages.

In the Page indexing report, "Page with redirect" is expected for old URLs. "Redirect error" covers a chain that is too long, a loop, a URL that grew past the maximum length, or a bad or empty URL in the chain; fix every one. "Not found (404)" is fine for URLs you retired on purpose, since Google says "404 responses are not necessarily a problem, if the page has been removed without any replacement", but an unexpected one is a missing line in your map. Investigate soft 404s, and treat "Duplicate, Google chose different canonical than user" as a sign that your canonicals, redirects, sitemap and internal links disagree somewhere. Then be patient. Google says "for medium-sized websites, it can take a few weeks or more for Google to gradually start showing the new URLs instead of the old ones (and for larger sites, even longer)".

The Change of Address tool is only for moving from one domain or subdomain to another. Google lists what it is not for: moving from http to https, moving pages within a site, switching between www and non-www, and changing hosting without changing URLs. You must own both properties in Search Console, using the same Google account. Rebuilding on the same domain, including a lapsed site on a domain you have just got back, does not need it.

In Bing Webmaster Tools, submit the new sitemap; Bing says it will "attempt to fetch it immediately upon submission" and then revisit it, "typically at least once per day". Bing Webmaster Tools once offered a Site Move tool, but we could not confirm from a current Microsoft page that it still does, and Bing's own 2014 help already described 301 redirects as "sufficient". IndexNow, which Bing and the other engines listed on indexnow.org support, says in its FAQ that after "a migration or redesign, it is acceptable to submit all URLs using IndexNow". Google is not among the engines it lists.

Rebuilding a site that has lapsed, whether it was yours or came with a domain you have bought, adds four checks that live-site checklists leave out.

1. Check the domain's history in Search Console. Verify a Domain property through DNS as soon as you control the name. Google's site-move guide says to clean up "your recently purchased domain": look for manual actions from previous spam, and make sure no URL removals are left over "from the previous owner, especially a site-wide URL removal."
2. Separate the old site from what came after it. Archives often record a lapsed domain's afterlife too: parking pages, registrar holding pages, redirects to unrelated sites, sometimes spam from a compromised final year. Capture dates and status codes show where the real site ended, and only its addresses belong in your map.
3. Decide what you have the right to reuse. An archived copy is evidence of what existed, not permission to republish it. The old URL structure and topics can guide a rebuild, but the old text and photographs belong to whoever created them unless you own them or have permission. How to restore a website from the Wayback Machine covers the rights question in more depth; this is general information, not legal advice.
4. Build for the people who arrive. Old links bring visitors who expect the old site. Google's March 2024 announcement on expired domain abuse says "It's fine to use an old domain name for a new, original site that's designed to serve people first." If the new site is a different business, say so, and read how to repurpose an old domain safely before you build.

Treat facts taken from an archive with suspicion until someone confirms them. An archived contact page shows the phone number, prices and opening hours of years ago, and republishing them as current is a quick way to mislead a customer.

DropOps Sites, our website builder for domains you own, works this way when it rebuilds on a domain with history. It reads the old addresses and a sample of old pages from public web archives, holds recovered details such as phone numbers and prices until the owner confirms, replaces or removes them, and gives every important old address a decision based on evidence such as linking sites and archive records, not on the AI. An address whose evidence could not be gathered goes to human review rather than being retired silently. Nothing goes live until the owner publishes, and the HTML export carries the redirects as an .htaccess file of 301s and a _redirects file, with a sitemap and a 404 page. If you have not secured the domain yet, you can check a .uk name first.