Rebrand with a new domain: the redirect checklist

Who this is for

You have renamed the company, often around a funding round or a product launch, and the website is moving from oldname.com to newname.com. The new site looks right on launch day. The problem shows up later and quietly: the press article about your seed round, the investor's portfolio page, last year's job ads and the QR code on the conference banner all point at the old domain. If those addresses return errors or dump everyone on the new homepage, you lose the traffic and the trust those links carried.

Most of the work happens before launch, and most of it is a spreadsheet.

Before launch: build the URL map

Collect every old URL

Start a sheet with two columns, old_url and new_url. Fill the first column from every source you have, then remove duplicates:

• the old site's XML sitemap;
• Search Console for the old domain: the Pages report and a Performance export of pages with clicks;
• your analytics landing-page report for the last twelve months;
• Search Console's Links report, which shows the pages other sites link to;
• addresses you have printed or sent yourself: pitch decks, press releases, job ads, email signatures, QR codes, app store listings and help docs.

The last group is the one teams miss, because those URLs never appear in a crawl.

Decide where each one goes

Each old URL gets one destination. Three rules cover most rows. If the page still exists under a new address, redirect to that address. If its content was merged into another page, redirect to the page that absorbed it. If there is no equivalent, let the old URL return a 404 or 410 rather than redirecting it to the homepage. Google's site-move guide warns specifically against redirecting many old URLs to one irrelevant destination such as the new homepage.

A few rows from a typical startup map:

If the rebrand renamed the product as well as the company, search the map for the old product name. Feature pages, docs and changelog entries often carry it in the path.

If you are planning the rebrand and the new site together, as in our brand and website work, draft the new page structure with this list open beside it. Every old page then has a destination decided before design starts, and nobody discovers a missing pricing archive in launch week.

What else moves with the domain

Pages are only part of it. Before the switch, check these:

• Subdomains your customers use, such as app.oldname.com or docs.oldname.com. Decide whether they move, and if they do, give them their own rows in the map.
• Email on the old domain. Keep its mail records working so replies to old threads still arrive.
• Files linked from outside: PDFs, press kit images and pitch decks.
• Campaign links with UTM parameters. Make sure the redirect keeps the query string, or the attribution on links that are still circulating breaks.
• On the new site, canonical tags, hreflang annotations, structured data and the sitemap should all use the new URLs.

Setting the redirects

Google recommends HTTP permanent redirects, 301 or 308, set on the server. A 302 tells search engines the move is temporary, which is the wrong message for a rebrand. JavaScript or meta-refresh redirects are a fallback when you cannot change the server.

Send each old URL straight to its final address. A common accidental chain is http://oldname.com/pricing, then https://oldname.com/pricing, then https://www.newname.com/pricing, then https://newname.com/pricing. Google advises redirecting to the final destination directly. Write rules that cover all four variants of the old domain (http, https, with and without www) and point each one at the canonical new URL.

The old domain also needs a valid HTTPS certificate for as long as the redirects run. Without one, a visitor arriving at https://oldname.com gets a browser security warning before the redirect can fire.

If the warning already appears, this guide explains the causes.

Testing the map

For each row, three things must be true: the first response is a 301 or 308, its Location header matches the new_url you planned, and that new URL returns a 200 without redirecting again.

You can check a single row from a terminal:

curl -sI https://oldname.com/pricing

The output shows the status line and the Location header. For a few hundred rows that gets slow, so we built an n8n workflow that does it from the same sheet: it reads each old_url and new_url pair, requests the old URL without following the redirect, and writes the status code, the Location, the destination's status and a pass or fail beside each row. It works from Google Sheets or an uploaded CSV.

It checks the first hop and the destination only. Long chains beyond the first hop, page content and indexing still need a manual look.

Run the check on staging if your host allows it, again within the first hour after the switch, and again whenever someone edits the redirect rules.

Launch week

• Verify both domains in Search Console, if you have not already.
• Use Search Console's Change of Address tool from the old property. Google says it is only needed for moves from one domain or subdomain to another, which is exactly this case.
• Submit a sitemap with the new URLs.
• Remove any noindex tags or robots.txt blocks that were only there during the build.
• Update the links you control: social profiles, Google Business Profile, app store listings, job boards, email signatures and the investor update template.
• Ask the owners of your most valuable inbound links, such as press articles, accelerator pages and investor portfolio pages, to change them.

Google also suggests timing the move for a lower-traffic period, so avoid the week of a funding announcement or a product launch.

The first months after the move

Expect search results to lag. Google says it can take a few weeks or more before it starts showing the new URLs, and longer for larger sites. Watch the new property's Pages report for 404s, and check analytics or server logs for requests to old URLs that are not in your map. Add those rows and test again.

Keep the redirects for as long as you can; Google's guidance is generally at least a year. Keep the old domain registered for longer than that, on auto-renew, in a company account rather than a founder's personal one (the account ownership table covers the registrar and DNS too). If it lapses, someone else can register it and take over every link that still points there.

Sources

• Google Search Central, "Site moves with URL changes": https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes (permanent redirects 301/308, server-side preferred; avoid mass redirects to an irrelevant page such as the homepage; 404/410 for content with no equivalent; redirect directly to the final destination; Change of Address tool only for domain or subdomain moves; sitemap with new URLs; update canonical and hreflang; remove migration-only noindex/robots blocks; verify both sites; time for lower traffic; a few weeks or more to show new URLs; keep redirects generally at least 1 year).
• Minimolo redirect-check workflow notes, redirect-check-workflow-readme.txt (what the workflow checks and its stated limits).

Related project and service