How to Fix Broken Links After a Domain Transfer

What a domain transfer actually changes

“Domain transfer” can mean two very different things, and the fix for broken links depends on which one happened.

• A registrar transfer moves the registration of the same domain from one registrar to another. The name stays the same. If DNS is handled correctly, visitors should notice nothing.
• A domain migration moves a website from one domain name to another, for example after a rebrand or an acquisition. Every URL changes, so every old link needs a redirect.

In practice, many transfers also involve moving DNS hosting, switching web hosts or reissuing SSL certificates at the same time. That is usually where links break. This guide walks through diagnosing the cause and repairing it in a sensible order. If you have not transferred yet, read our domain transfer lock guide and our explanation of transfer authorisation codes first.

Step 1: Confirm DNS survived the transfer

The most common cause of a site going dark after a registrar transfer is DNS. Some registrars provide free DNS that stops working once the domain leaves them, and the new registrar may assign its own default name servers with an empty zone.

Check which name servers are now in use and whether key records resolve:

dig NS example.com +short
dig A example.com +short
dig A www.example.com +short
dig MX example.com +short

Compare the results with a saved copy of your old zone. If records are missing, recreate them at the current DNS provider, or point the name servers back to the provider that holds the correct zone. Changes can take time to be visible everywhere, depending on TTL values; our article on how DNS propagates explains why.

You can also run a lookup with the TLDix WHOIS and RDAP tool to confirm the registrar, status codes and name servers listed at the registry, which helps rule out a transfer that is still pending.

Step 2: Check hosting and SSL

If DNS points to a new server, the site files, virtual host configuration and certificates must exist there too. Typical symptoms and causes:

The TLDix hosting lookup shows which provider an IP address belongs to, a quick way to confirm traffic is reaching the server you expect.

Step 3: Find every broken link

Once the site loads, find what is still broken. Use several sources, because each sees a different part of the picture.

Crawl the site

A site crawler follows internal links and reports status codes. Look for 404 and 410 responses, redirect chains, redirect loops and links that still point to an old domain. A simple check for a single URL looks like this:

curl -sI https://example.com/old-page | head -5

Read your server logs

Logs show what real visitors and crawlers request, including old URLs linked from other sites that a crawl of your own pages will never find:

grep " 404 " /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -50

Use Google Search Console

The Page indexing report lists URLs Google tried to crawl that returned “Not found (404)”. The Links report shows top linked pages, so you can make sure the most valuable ones resolve correctly.

Step 4: Map redirects for a domain change

If you moved to a new domain name, every old URL needs a permanent redirect to its closest equivalent. Build a mapping spreadsheet with the old URL, the new URL and the status code. Rules of thumb:

• Use 301 (or 308) redirects for permanent moves.
• Redirect each page to its specific replacement, not everything to the home page. Google may treat mass redirects to the home page as soft 404s.
• Avoid chains. Old URL should go straight to the final URL in one hop.
• Keep the path structure where possible so a single pattern rule covers most pages.
• Keep redirects in place for at least a year; Google recommends this for site moves, and keeping them longer does no harm because external links persist.

When paths are unchanged, a single server rule handles the whole domain. For Nginx:

server {
    listen 443 ssl;
    server_name old-example.com www.old-example.com;
    ssl_certificate     /etc/ssl/old-example.com/fullchain.pem;
    ssl_certificate_key /etc/ssl/old-example.com/privkey.pem;
    return 301 https://new-example.com$request_uri;
}

For Apache with mod_rewrite:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www[.])?old-example[.]com$ [NC]
RewriteRule ^(.*)$ https://new-example.com/$1 [R=301,L]

Note that the old domain still needs a valid certificate. Otherwise HTTPS visitors see a warning before the redirect can happen.

Step 5: Update internal links and technical signals

Redirects are a safety net, not the final fix. Update your own references so users and crawlers reach the destination directly:

• Search and replace the old domain in your database and templates. Back up first, and use a tool that handles serialised data if your CMS stores it.
• Update canonical tags, hreflang annotations and Open Graph URLs.
• Regenerate XML sitemaps with new URLs and submit them in Search Console.
• Update robots.txt if it references sitemap locations.
• Check structured data, analytics settings, CDN rules and third-party scripts that reference the old hostname.

Step 6: Tell Google and fix important external links

For a move to a new domain, verify both the old and new properties in Search Console and use the Change of Address tool from the old property. It requires the 301 redirects to be in place and helps Google move signals to the new site more smoothly. Expect rankings and traffic to fluctuate for some weeks; the length varies by site size and crawl frequency.

Then contact the owners of your most valuable external links, such as partner sites, directories and profiles you control, and ask them to update the URL. Redirects will carry visitors either way, but direct links are more robust if the redirects are ever removed.

A realistic recovery timeline

How quickly a site recovers depends on what went wrong. The table below gives rough expectations; actual timing varies with TTL values, site size and how often search engines crawl you.

Prioritise by value

When there are hundreds of broken URLs, do not work alphabetically. Start with pages that receive the most external links, the most organic traffic and the most conversions. Your analytics, the Search Console Links report and server logs together show which URLs carry real value. Fix those first, then work through the long tail in batches.

Document what you did

Keep the redirect map, the old DNS zone export and a short log of changes in a shared place. If something breaks months later, or a colleague changes server configuration, that record makes it far easier to see which rules must stay. It also helps if you ever move the site again, because old redirects need to be carried forward rather than replaced, otherwise links that pointed at the first domain will break a second time.

Preventing broken links next time

Most transfer problems are avoidable with preparation:

• Export the complete DNS zone before starting any transfer.
• Lower TTLs a day or two before changing name servers, then raise them again afterwards.
• Crawl the site beforehand and save the URL list as your redirect baseline.
• Check that certificates will be valid on any new server before switching DNS.
• Keep the old domain registered after a migration. If it expires, someone else can buy it and your redirects disappear.

That last point is easy to forget. Adding both old and new domains to the TLDix domain panel gives you expiry alerts for each, so a redirecting domain does not lapse quietly years later.