Domain History Check Before a Site Move: Agency Checklist 2027

domain-history-check-before-site-move

Opinion piece by Lucy Kim, co-founder of Karma.Domains

A client rebrands, and the plan is to move the site from a.co.uk to a.com. Or the client has bought a second.co.uk and wants to merge the main site into it.

Either way, the agency gets asked about redirects, URL maps and launch dates.

The question that should come first is simpler: what has the destination domain been used for over the last ten or fifteen years? A domain history check answers that before any migration work starts, while walking away still costs nothing.

Why do a domain history check?

seo-consultant-examining-a-domains-historical-website-record

 

Old content, links and spam signals travel with a domain, and no redirect plan cleans them up. Below is the checklist I would use as an agency, ending in a go, hold or reject call for the client.

Before any URL mapping starts, we run a domain history check on the destination. I use Karma.Domains for that first pass: its database covers 13M+ domains and 40 auction sources, adds 400k+ new domains per day and has 90+ filters across archive history and SEO data.

Why the destination domain is an agency decision

Clients rarely see the destination domain as a risk. To them it is a name the board approved, or a purchase already made. The agency knows a domain brings its past into the new site, so the agency should own the check and say so in the scope of work.

If the history check happens after the URL map, the redirects and the new templates, a bad result means throwing away paid work. At kick-off, the same problem is only a scoping change. I put the check in the first week, before anyone estimates migration hours, and I name who signs it off: the SEO lead reviews the evidence, and the account lead takes the recommendation to the client.

Two gates: the domain decision and the migration

two-distinct-stages-for-domain-decision-and-migration

Google’s site-move documentation advises changing one major thing at a time where you can. Changing the domain, the CMS and the design together makes any later traffic change hard to diagnose.

So, I split the project into two gates:

  • Is the destination domain suitable for this client and this content?
  • If it is, can the migration be carried out and monitored safely?

The first gate is cheap and reversible. The second is where the budget goes. Keeping them apart means the client approves the domain on evidence before paying for the move.

Baseline the client’s current site first

Before looking at the new domain, export what the move must protect: important URLs, clicks and impressions, conversions, top landing pages, backlinks, indexation issues, and any manual action or security warning. Search Console shows how Google crawls, indexes and displays the site; GA4 shows what visitors do once they arrive. Google’s own documentation on using the two together explains that split well.

The baseline defines what the migration must preserve and what to compare against after launch. It also feeds the history check: once you know which topics earn the client’s traffic, you can judge whether the destination’s past fits them.

Run a domain history check on the destination

I go through three areas and write down the evidence for each, including what I could not find. The questions I want answered are these:

  • What did the site on this domain publish, period by period, and in which languages?
  • Were there long gaps, parked pages or redirect periods, and where did those redirects point?
  • Did the topic ever drift into gambling, pharma, adult, piracy or scraped coupon content?
  • Which old pages attracted links, and will the new site have a genuine equivalent?
  • Does anything in the domain’s past conflict with the client’s brand?

Archive topics, languages and redirect periods

Archive snapshots show what the domain actually hosted. I look for continuity. A domain with years as a related publication is a different case from one with a casino phase, two parked years and a redirect to something unrelated. A switch of language is a warning sign, and so is a redirect period nobody can explain. Snapshots are incomplete, so a quiet archive does not prove a clean past. I record gaps as open questions.

Registration and ownership signals

business-analyst-examining-domain-registration-dates-and-ownership-history

These get a line or two in the report: how long the name has been registered and whether it seems to have changed hands.

For UK clients I add two quick checks on the business side. Do the old site’s company claims match the record at Companies House? Does the name clash with a registered mark in the UK IPO trademark search?

Spam and expired domain abuse risk

Google’s spam policies describe expired domain abuse as buying an expired domain and repurposing it mainly to manipulate search rankings with content that offers users little value. A client moving an established brand onto a new domain is not doing that.

A destination with a spam history can still carry links and associations nobody wants, though. I check spam signals, the anchor text pattern and any spike of low-quality links, and I note whether the client’s real content follows on naturally from what was there before.

Compare backlinks with the client’s content map

Authority metrics help with triage, but the migration decision needs detail. I want to know which old URLs attracted links, what those pages covered, and whether the new site will offer a legitimate corresponding page.

Ahrefs and Semrush are the tools I use for deep link review on the finalist. The history check tells me where to spend that time. It cannot decide that an old URL and a new page are equivalent.

Google’s site-move documentation warns against pointing many old URLs at an irrelevant destination such as the new home page and recommends mapping each old URL to its closest new equivalent with permanent redirects. Apply the same thinking to the destination’s own old links. If strong links point at pages the client will never replace, count them as lost.

Go, hold or reject: how we report it to the client

Clients need a decision and the reason behind it, not raw archive notes, so the result goes into a short table at the top of the report:

Decision What it means What happens next
Go History and intended use fit, with no unresolved risk Start migration planning and URL mapping
Hold The domain may fit, but one named question is open: an unexplained redirect period, a link cluster or a trademark Resolve that question by a set date, then decide again
Reject History, spam risk or topic mismatch outweighs the benefit Recommend another name or stay on the current domain

Every hold gets an owner and a date. Without them, a hold tends to turn into a go once the launch date gets close.

Hand-off to the SEO site migration

After a go, the SEO site migration runs as its own project with its own plan. This is the short website migration checklist I attach to the hand-off:

  • Verify both the old and the new properties in Search Console.
  • Build the URL map from the baseline, matching each old URL to its closest new equivalent.
  • Set up server-side permanent (301) redirects, one hop each.
  • Update canonicals, internal links, hreflang and structured data to the new domain.
  • Submit the new XML sitemap and use the Change of Address tool.
  • Keep the old domain registered and its redirects live.
  • Monitor traffic, indexation and crawl errors on both properties against the baseline.

The history notes go into the project folder with the decision table, so anyone reviewing a dip later can see what was known before the move.

FAQ

1. Does changing domain name affect SEO?

It can. When you change domain name, SEO signals must be processed again for the new address, and Google notes that rankings can fluctuate while that happens. A clean destination, a complete URL map and permanent redirects reduce the risk. A destination with a messy history adds risk that redirects cannot remove.

2. Are expired domains legit for a client site?

Yes. Buying a previously registered domain is legitimate; the risk lies in how it is used. Run a domain history check first and use the domain for content that genuinely fits the client, rather than buying it for its old links.

3. How long should 301 redirects stay in place after a domain move?

Google’s documentation says to keep redirects in place for as long as possible, and generally for at least a year. I advise keeping the old domain registered and redirecting for longer, because old links and bookmarks keep sending visitors.

4. What should a website migration checklist include?

At minimum: a performance baseline, a URL map, server-side 301 redirects, updated canonicals and internal links, a new sitemap, a Change of Address submission where it applies, and monitoring of both properties after launch. For a domain change, the destination domain review comes before all of these.

 

Author Profile

ClickDo Reporter
Passionate content creator, contributor, freelance writer and content marketing allrounder.
Share to spread the knowledge!