Site Migration SEO: Real Data, Eight Weeks In

On 12 June 2026, at 09:40, this site went through a full site migration, domain and all, when digitalpromarketing.net became griffithpromarketing.com. Eight weeks on, here’s what site migration SEO actually looks like in Search Console, not the tidied-up version.

Why the Move Happened

digitalpromarketing.net had picked up real content and some genuine rankings along the way, but the name never really fit what the site had turned into, something more specific and personal than a generic marketing brand. griffithpromarketing.com just says that plainly. The trade-off is real though. Changing your domain is about as big a lever as you can pull on your own rankings, and pulling it on purpose doesn’t mean it pulls in the direction you want.

It wasn’t a fast decision either. A domain carrying real backlinks and a few years of indexed history is worth something concrete, that’s not sentimental, it’s actual ranking equity sitting there whether you use it or not. Walking away from that on purpose, for a name that better matches the work rather than for any technical reason, is a harder call to justify with a spreadsheet than most of the fixes this site normally writes about.

The honest version of the decision is closer to this: the mismatch between the domain and the actual work was going to keep costing trust with readers indefinitely, while a domain change costs visibility for a defined, if uncertain, stretch of time. One of those problems has an end date. The other one doesn’t, unless you fix it. That trade-off is really the whole story of site migration SEO: a known, temporary cost weighed against an open-ended one.

What the Cutover Actually Looked Like

301 redirects went in first, old URL mapped to new URL through Rank Math’s redirection manager, tested before DNS actually changed. The new domain went into Search Console that same morning. If you’re looking at the sitemap and wondering why there’s a separate cluster of posts dated through mid-to-late July, that’s not the migration, that’s me going back through the existing library and republishing it piece by piece over the following weeks. Nobody warns you that’s its own job.

Redirects were only one part of it. Before DNS actually changed, the sitemap was rebuilt against the new domain and resubmitted, the canonical tags across the site were checked to make sure none of them were still quietly pointing at the old URLs, and the tracking codes were carried across rather than left running against a property that was about to go quiet.

None of that is exciting to write about, and none of it shows up in a screenshot, but it’s the boring list that decides whether a migration is clean or whether you spend the next few months finding small things that got missed.

The mapping itself covered a few different shapes of URL, not just a blanket old-domain-to-new-domain swap. Blog posts and case studies mapped one to one, straightforward path for path since the URL structure didn’t change, only the domain. Category and tag archive pages needed checking individually, since a couple had drifted from what the default settings would have guessed.

The handful of image URLs referenced directly inside older posts got checked too, since a broken image doesn’t throw an error a redirect audit necessarily catches, it just quietly stops rendering. Testing meant working through a sample from each category and confirming a single 301 straight to the final destination, not a chain of two or three redirects stacking on top of each other, which is its own quiet tax on both crawl budget and page speed if it’s left in place.

One thing to get straight before the numbers: the domain moved, the hosting didn’t. This site’s still sitting on Hostinger, a separate move to Cloudways is its own project on its own timeline, and I’ve written about that honestly in the Cloudways review. Two different migrations that happened to land close together in time, not the same event, and mixing them up makes it harder to tell which change actually caused what you’re about to see below.

What Could Have Silently Gone Wrong

The failure modes that actually wreck a domain migration are rarely the obvious ones. Redirects that visibly 404 get noticed and fixed within a day, usually by whoever’s clicking around the new site checking it works.

What doesn’t get noticed as quickly is a robots.txt file still blocking crawlers out of habit from a staging environment, or a canonical tag on a handful of pages still pointing back at the old domain because a plugin cached the old setting somewhere. Both of those can sit there for weeks looking completely normal to a human visitor while quietly telling Google not to bother indexing the page properly.

Before going live, the checklist here was: confirm robots.txt on the new domain actually allows crawling rather than inheriting a staging block, spot check canonical tags across a sample of pages in every major content type rather than just the homepage, and make sure no noindex tag had survived the move from anywhere it might have been added temporarily during testing.

None of these would have shown up as an error anyone would notice by clicking around the site. They’d only show up months later as pages quietly missing from the index with no obvious cause, which is a much harder problem to diagnose after the fact than to prevent before DNS changes. Most site migration SEO problems aren’t dramatic, they’re just quiet.

There’s also the backlink side, which is out of anyone’s direct control. Every external site linking to an old digitalpromarketing.net URL is now relying on that redirect actually working, indefinitely, since there’s no realistic way to ask every one of them to update the link. That’s the strongest argument for keeping redirects live permanently rather than treating them as a temporary bridge to clean up later.

The moment a redirect gets removed because the destination looks quiet, any external link equity still flowing through it just stops, quietly, with no warning and no easy way to notice it happened until rankings unexpectedly dip on a page that seemed to be doing fine.

Site Migration SEO Results: What Search Console Shows, Eight Weeks On

Here’s the honest read of the graph. Impressions sat close to flat for the first few weeks after the 12 June cutover, then start climbing from around 20 July, about five or six weeks after DNS actually changed. That timing lines up with the new domain getting properly indexed and the old rankings starting to transfer across.

Clicks haven’t followed yet though, nine total across the whole three months, and an average position of 60.7 tells you why. That’s roughly page six of Google, which is to say nowhere anyone’s actually looking. Average CTR for the window sits at 0.3%.

A 0.3% CTR at position 60 isn’t a conversion problem, and it’s not a content problem either, it’s just what happens when almost nobody sees the listing in the first place. Fix the position first. The CTR sorts itself out once that happens.

This is the bit most site migration SEO checklists gloss over. Redirects being in place doesn’t mean search engines hand back your authority straight away, there’s a real lag while the new domain gets crawled, evaluated, and slowly trusted with the rankings the old one earned.

Eight weeks in, I’m sitting right in the middle of that usual recovery window, not past it. And the graph’s at least showing the right shape. Impressions recovering, not flatlining for good.

For what it’s worth, this isn’t an unusually slow recovery either. Even a well-executed migration typically comes with a real dip in search performance for several weeks afterward, and general estimates for how long it takes search engines to properly index and re-evaluate trust in a new domain commonly sit in the four to six week range, sometimes longer depending on how competitive the space is.

Eight weeks against that backdrop isn’t a red flag on its own, it’s closer to what should be expected. The actual test is what happens over the next month, not this one.

What Didn’t Break: Speed

Here’s the thing that could easily have gone wrong and didn’t: site speed held up through the whole move. Mobile PageSpeed sits at 96, First Contentful Paint 1.1 seconds, Largest Contentful Paint 2.7 seconds. Desktop’s at 99, FCP 0.3 seconds, LCP 0.7 seconds, Total Blocking Time 40 milliseconds, Cumulative Layout Shift a flat 0. Getting site migration SEO right doesn’t automatically mean speed survives the move too, it just means the SEO side isn’t actively working against you while you fix speed separately.

Speed is one of the more common casualties of a domain move, and usually for boring reasons rather than dramatic ones. A CDN still pointed at the old domain, a caching plugin holding onto rules keyed to URLs that no longer exist, or DNS not fully propagated when the first post-migration tests get run, any of those can make a perfectly fast site look broken for a few days without anything actually being wrong with the new setup underneath it.

The fix in most cases isn’t technical skill, it’s just knowing to check rather than assuming the old configuration carries across cleanly.

Not an accident. WP Rocket was already set up on this site before any of this started, and the first thing I did once DNS actually cut over was clear the cache completely and let it rebuild fresh against the new domain, rather than assume the old cache would just carry across cleanly.

A domain change does enough damage to the SEO side on its own without also letting the one metric that was actually fine quietly go backwards too.

What’s Next

This bit’s deliberately unfinished. Eight weeks is enough time to expect some movement, not enough to call it a finished recovery, or a stall. I’ll come back to this once there’s another full month of data and take an honest look at whether position and clicks actually follow the impressions up, or stall out completely. If they stall, that’s a post too, just as directly as if they don’t.

Publishing this now, with the ending still unknown, is deliberate rather than an oversight. It would be easy to wait another month, see how the numbers actually land, and write a single clean post with a tidy verdict at the end. That version reads better.

It’s also not how any of this actually happened, and pretending otherwise would mean cutting the exact part, the uncertain middle, that’s most useful to someone going through the same thing right now, not after they’ve already made the decision. That’s the real shape of site migration SEO recovery: slow, then all at once, or not at all.

Going forward, the actual tracking is fairly unglamorous: a weekly look at Search Console position and impressions for the pages that mattered most on the old domain, watching whether they’re climbing back toward where they used to sit or plateauing somewhere lower, and keeping an eye on whether click-through starts moving before position properly recovers or only after.

If clicks start showing up while position is still sitting around 60, that would actually be a more interesting result than the expected version, since it would suggest something else, brand recognition, direct navigation, is doing some of the work that organic ranking normally would. Right now there’s nothing in the data pointing that way, but it’s worth watching for rather than assuming it away.

The graph doesn’t lie either way. Not a disaster, not a comeback yet, just a domain eight weeks into earning back what it gave up on purpose.

If you’re about to do this yourself, the core of site migration SEO comes down to a short list of unglamorous steps: map and test your redirects before DNS changes, submit the new property in Search Console the same day, and don’t assume your caching setup survives the move untouched. Check it. The 21-point checklist covers the technical foundation items worth going through either way.