What I Learned Migrating 30 Pages of My Own Website (And Watching Half My Rankings Disappear)

In April this year I changed roughly 30 page URLs on my own website. Old slugs like /areas-we-serve/sussex/eastbourne became /web-design-eastbourne. The reasoning was sound. The execution was mostly right. The aftermath was worse than I expected.

Half my Sussex location rankings disappeared for two weeks. Pages that had been ranking position 8 dropped to position 40. Two pages 404’d. One ended up in a redirect loop. My traffic for “web design crawley” — a query I’d been comfortably picking up clicks on — went from three a week to none.

I’ve come out the other side now. Most of the rankings have recovered, some are better than they were, and a small handful are still lagging. But I want to write down what actually happened, because the version of this story you usually read in SEO blogs is sanitised. The real version has more sweating in it.

Here’s what I learned.

1. “I’ll just rename the slugs” is a sentence you should be suspicious of

The reason for the migration was reasonable. My old URL structure was /areas-we-serve/sussex/[town], which is hierarchically tidy but produced URLs nobody would type, share, or remember. I wanted shorter, flatter, more direct slugs. Web design at top level. /web-design-eastbourne. /web-design-haywards-heath.

This is a sound choice on paper. Shorter URLs perform better for click-through rate. Flatter hierarchy is easier for Google to crawl. The old structure was a relic from when I was still figuring out the site architecture three years ago.

What I underestimated was how much link equity had built up at those old URLs. Three years of internal linking, two years of backlinks, sitemap submissions, and search engine memory had concentrated authority in /areas-we-serve/sussex/[town] for every Sussex location I served. Renaming the slug doesn’t transfer that authority instantly. It transfers some of it, slowly, via 301 redirects, while Google decides whether to trust the new URL.

The honest read is that I treated the migration like a content update when it was actually an architectural change. I underestimated the disruption. If I were doing it again, I’d treat it like moving house.

2. Yoast’s auto-redirect is a kindness, not a strategy

I run Yoast Premium. When you change a slug, Yoast offers to set up a 301 redirect from the old URL to the new one. I clicked yes 30 times in a row.

What I didn’t notice until later was that some of those redirects were redirecting to URLs that didn’t exist yet, because I’d planned to create the new pages but hadn’t quite done so when the slug change went live. One of them — /web-design-lancing — created an actual loop, redirecting back to /areas-we-serve/sussex/lancing, which redirected back to /web-design-lancing, ad infinitum. Google saw an infinite redirect chain and stopped trying to crawl either URL.

The fix was obvious in hindsight. Build all the new pages first. Then change the slugs. Then test every single redirect manually with a tool like httpstatus.io. I did the second and third in the wrong order, and one of the redirects didn’t get a sanity check at all.

If you’re contemplating a migration, the order is: build new pages → test new pages → set up redirects from old to new → test every redirect manually → wait for Google to recrawl → only then trash the old URLs. Don’t shortcut.

3. Google takes 4-6 weeks to make up its mind. Sometimes longer.

The standard advice on URL migrations is “rankings should recover within 2-4 weeks.” That has been roughly true for half my pages. The other half have taken six to eight weeks, and three of them aren’t fully recovered now, almost a month later.

There’s no warning system for which pages will be in which group. The pages that recovered fast all had something in common — they had stable backlinks, they were already ranking well, and the new content was substantially the same as the old. The pages that took longer had usually had some content change at the same time, or the new short slug had no historical equity at all.

What I learned is that you have to budget for an uncomfortable middle. The middle where the old URL is no longer ranking, the new URL hasn’t started, and the only thing you can do is sit on your hands and wait for Google’s index to refresh. That period is six weeks long. It feels like six months.

4. Search Console reports are lagging indicators

I spent a fortnight in late April convinced that 76 of my pages weren’t being indexed. The “Discovered — currently not indexed” report in Search Console listed 76 URLs and the trend line was getting worse.

What I didn’t realise until later was that the report is significantly stale. When I spot-checked individual URLs from that list, three out of four were already indexed. Google had simply not refreshed the report. Search Console is showing the state of Google’s last considered judgement about each URL, not the current state of the index.

This matters because if you panic-react to a report that’s two weeks behind reality, you can do harm. I almost rewrote 12 portfolio pages because they appeared as “rejected for quality.” When I checked the live SERPs, several of them were actually ranking. The report was just slow to catch up.

Lesson: don’t treat the Search Console reports as gospel during a migration. Spot-check the URLs themselves. The “URL inspection” tool is closer to ground truth than the aggregate reports.

5. Rankings shown in GSC are not the same as rankings on Google

This sounds like the same point. It isn’t. During the migration I’d open Search Console, see “average position 22.6”, and feel disappointed. Then I’d go to Semrush or pull a live SERP from a separate tool and see I had 9 keywords ranking in the top 3 and 47 in the top 10.

The difference is that Search Console aggregates every query that ever surfaced your site, including the thousands of low-quality LLM-generated and bot queries that are flooding GSC for everyone right now. Those queries pull your “average position” into the gutter. Real human searches were ranking much better than the average suggested.

If you’re going through a migration and watching the average position number, watch it with caution. Strip out branded queries, strip out the AI-generated weirdness, and look at where you actually rank for the keywords that matter commercially. The picture is usually less alarming than the dashboard suggests.

6. The migration exposed problems I should have fixed before I started

Some of the pain wasn’t caused by the migration itself. It was caused by the migration revealing weaknesses that had always been there.

I had four different Eastbourne pages competing with each other. /web-design-eastbourne, /seo-eastbourne, /wordpress-support-eastbourne, and the old /areas-we-serve/sussex/eastbourne. The migration changed the URL structure, but it didn’t fix the underlying problem that Google had no idea which page should be authoritative for “Eastbourne”.

I had broken internal links pointing to slugs from 2023. I had a sitemap that hadn’t been resubmitted since January last year. I had pages that had never received an internal link from anywhere except the parent hub. None of these were caused by the migration. The migration just exposed them in a way I couldn’t ignore anymore.

If you’re thinking about a similar move, do the audit first. Find the orphan pages. Find the duplicate pages. Find the broken internal links. Fix those before you change the URL structure. The migration goes much smoother on a tidy site than on a messy one.

7. The recovery is real, even if it doesn’t feel real for a month

Six weeks after the migration started, my position numbers are better than they were before. The site is ranking for more keywords. The pages that survived the consolidation are stronger. Some of the locations I was already ranking for have moved up two or three positions because Google’s no longer split between two URLs.

The aggregate is a clear win. I’d do the migration again.

But I wouldn’t do it the same way. I’d build the new pages first. I’d test every redirect before going live. I’d not panic-read GSC reports for two weeks. I’d budget six full weeks of disrupted traffic and not fight it. And I’d remember that an architectural change is a bigger commitment than the few clicks it takes to rename a slug.

What I’d do differently next time

The shortlist:

• Build everything first. Every new page live and tested before any old slug changes.
• Test every redirect manually. Httpstatus.io. Not just for status code, for the actual destination.
• Don’t rely on Yoast’s auto-redirects alone. Use a dedicated redirect manager (I prefer the WordPress 301 Redirects plugin) and treat the redirect map as a deliverable, not a side effect.
• Audit the site first. Find orphan pages, duplicate pages, broken internal links. Fix those before touching URLs.
• Resubmit the sitemap immediately after. And then again two weeks later.
• Don’t read Search Console reports daily. The lag will drive you mad. Weekly is enough.
• Budget six weeks of disruption. Tell yourself this in advance. Stick to it when you panic.

If you’ve got a similar migration coming up and you’d rather not do it solo, the practical bits — redirect mapping, content audit, internal link review — are exactly the kind of thing I help clients with through my WordPress support service. It’s cheaper than getting it wrong yourself, and considerably less painful.

If you’ve already migrated and you’re sitting in the uncomfortable middle right now wondering if the rankings will ever come back, the answer is they probably will. But check your redirects. Properly.