Moving your author website without losing your Google rankings

When an author loses traffic in a website move, the cause is almost always the same. Pages Google had indexed for years stopped existing, and nothing told Google where they went. The fix is mechanical: list every URL Google knows about, point each one at a single new URL with a permanent redirect, and leave those redirects running for at least a year.

That’s a solvable problem, and Google is explicit about the link equity: “301 and other permanent redirects don’t cause a loss in PageRank.” Done properly, a move costs you a few weeks of wobble. Done carelessly, it costs you the six years of accumulated authority sitting on your /books/the-glass-door/ page, and you usually don’t notice for a month.

This is written for someone who already has traffic worth protecting. If nothing on your site ranks yet, none of the risk below applies and you can move however you like.

Work out which move you’re actually doing

Google splits site moves into two categories, and the work is different.

The first is same URLs, different infrastructure. You’re switching host or rebuilding on a new CMS, but yoursite.com/about/ is still yoursite.com/about/ afterwards. That’s a DNS and testing problem rather than a redirect one, and it comes down to four things: confirm your Search Console verification survives the rebuild, lower your DNS TTL a week ahead, check analytics tags and structured data on every template rather than just the homepage, and make sure a URL that doesn’t exist still returns a 404. Google’s guidance for this case barely mentions redirects, and warns mainly that crawling wobbles. Its wording is that “it’s normal to see a temporary drop in Googlebot’s crawl rate immediately after the launch, followed by a steady increase over the next few days”.

The second is different URLs: a new domain, or the same domain with a new structure, so /blog/2019/05/my-post/ becomes /blog/my-post/. That one needs a redirect map, it’s where the damage happens, and it’s what the rest of this guide is about.

Plenty of author-site moves are secretly the second kind. You think you’re moving from Wix to WordPress, but the new permalinks put dates in your URLs, or your blog lived at /news/ and the new theme wants /blog/. Check before you start, because the answer changes the size of the job.

Build the URL inventory before you migrate anything

You cannot redirect what you can’t list. Before anything else, produce one spreadsheet of every URL on the old site that Google knows about, including the pages you’d long forgotten.

Pull from several sources, because each one misses something different:

Export the Search Console Performance data now. Google keeps 16 months of it on a rolling basis, so once a date falls off the back you can’t get it back, and a CSV saved before the move is the only honest “before” you’ll have to compare against.

For the crawl, Screaming Frog’s SEO Spider is the standard tool. The free version has a “Crawl Limit - 500 URLs”, which covers most author sites outright, and although there’s a paid annual licence for bigger crawls you’re unlikely to need it at this scale.

Deduplicate the list and keep the odd entries in. Image files that other sites hotlink, the PDF sample chapter you emailed a reviewer in 2021, the RSS feed. At least one of them is load-bearing.

Keep the URL structure if you possibly can

The cheapest migration is the one where nothing needs redirecting. Every URL you preserve is a redirect you don’t have to write, test, monitor and maintain for a year.

Authors talk themselves out of this because the new platform’s defaults are different, or because the old URLs are “ugly”. Ugly URLs that rank beat pretty URLs that don’t, so unless your structure is actively broken, keep it.

Four details change the URL silently even when you meant to keep it. Trailing slashes are the first, because /about and /about/ are different URLs; most platforms canonicalise one to the other, so if the old site used one convention and the new one uses the other, you’ve just changed every URL on the site. Case is the second, and it bites when you move onto a host that cares. Vercel’s documentation is blunt that its CDN “does not normalize URL paths to lowercase. URLs are case-sensitive”, returning a 404 if nothing exists at that exact casing, and an old case-insensitive CMS will have left mixed-case URLs in the wild.

Third are feed paths, which differ between platforms. Hugo, which is what publishing.co.uk runs on, generates its feed at index.xml by default, and moving between conventions without a redirect means every subscriber’s reader quietly stops updating. If your newsletter is set up to pull new posts from that feed, it stops too, and nobody complains. They just stop arriving. Fourth are date and category prefixes: going from /2019/05/post-title/ to /blog/post-title/ is a full-site URL change dressed up as a tidy-up, worth doing eventually but not alongside a platform move. Make structural changes weeks before or weeks after the platform move, never in the same week, so that when something goes wrong you know which change caused it.

One decision is specific to UK authors: whether to keep your .co.uk. Google says country-code domains “provide a strong signal to both users and search engines that your site is explicitly intended for a certain country”, so swapping .co.uk for .com gives up that signal on top of everything else a domain move costs. If you sell mainly into the US it may be a trade worth making, and either way you’ll be renewing the old domain for years afterwards, which belongs in the budget alongside everything else an author website costs.

Map every old URL to exactly one new one

Get this wrong in the easy direction and you’ll sweep the whole old site to your homepage. Google warns against that by name: “Don’t redirect many old URLs to one irrelevant single URL destination, such as the home page of the new site. This can confuse users and might be treated as a soft 404 error.” A soft 404 is worse than a plain 404, because you think you’ve handled it.

So for each old URL, name the one new page that replaces it. Consolidating several similar old pages onto one good new page is fine, and it’s the blanket sweep that causes the trouble.

Use a permanent server-side redirect. Google ranks the methods by how reliably it can interpret them, strongest first: server-side HTTP redirects, then meta refresh, then JavaScript, then a plain text link, and its recommendation is to “use a permanent server-side redirect whenever possible”.

Hugo users get caught here, because the built-in aliases feature is client-side by default: “Hugo uses client-side redirection, generating a small HTML file for every alias. This file contains a meta http-equiv="refresh" tag”, which is the second-tier method rather than the first. The docs describe the server-side alternative as “more efficient because the redirect happens at the HTTP header level before any page content is processed”, though you build the rules for your host yourself from the Aliases data. If you assumed Hugo aliases were 301s, that’s worth checking before you rely on them.

Point each old URL at its final destination directly, because chains do work but every extra hop is another thing to break.

Redirect mechanics by platform

Verified as of August 2026 from each vendor’s own documentation. This is the mechanics of adding redirects; if you’re still choosing where to land, start with our author website platform comparison.

Three limits are worth knowing before you start. Squarespace caps the mappings field at 400 KB, “usually around 2500 redirect lines”, and fires rules “from top to bottom, so higher redirects will take priority over conflicting redirects below them”, which catches people at any size: put specific rules above wildcards or the wildcard swallows them. Wix imports “a maximum of 500 redirects” per CSV file and “any redirects listed beyond this limit will not be imported”. Netlify defaults a rule to 301 if you don’t set a status, while Vercel recommends “status code 307 or 308 to avoid the ambiguity of non GET methods”, where 308 is the permanent one.

Moving from Wix or Squarespace to WordPress

This is the most common author migration, and it carries one trap that can undo everything else you get right. Wix and Squarespace redirects are served by those platforms. They only run because DNS points at Wix or Squarespace, so the moment DNS points at your new WordPress host, every redirect you ever configured there stops firing, including the ones you set up years ago and forgot about. Nothing warns you. The old URLs simply start 404ing.

That changes the order of work. Export the URL list and the existing redirect rules before you touch anything, because both get much harder to retrieve once the site is gone, then rebuild every rule on the new host and test it before you switch DNS rather than after.

The second thing to settle is your permalink structure. Set it before you import content, because changing it afterwards renames every post you’ve just brought across. If your old URLs had no date in them, make sure the new ones don’t either, and if they did, keep it. Every difference you accept here is another line in the redirect map, and the redirect map is the thing that has to be maintained for a year.

Canonical tags are a hint, a redirect is an instruction

A rel="canonical" tag tells Google which URL you consider the real one when several pages show similar content. It’s worth getting right, and it doesn’t do a redirect’s job.

Google lists redirects above rel="canonical" in its ordering of canonicalisation methods but describes both as “a strong signal”, and notes the methods “can stack and thus become more effective when combined”. The practical difference is what each one does: a canonical is a signal Google can overrule, and it leaves the old URL live and reachable, whereas a redirect moves the visitor as well as the signal.

Three rules cover a migration:

1. Every page gets a self-referential canonical. Google recommends you “include a rel="canonical" link on the canonical page itself (also known as a self-referential canonical)”.
2. Use absolute URLs, with the right protocol and hostname. Google’s list of common mistakes says to “use absolute paths rather than relative paths”, and notes the tag “is only accepted if it appears in the <head> section of the HTML”.
3. Check that nothing on the new site canonicalises back to the old domain. This catches people who duplicate the old site to build the new one. The canonical tags come along for the ride, and every new page ends up telling Google the real version lives on the site you just redirected away from, so grep the built HTML for the old hostname before you launch.

Cross-domain canonicals have a legitimate use when both sites have to stay live. In a migration they shouldn’t, so redirect.

Search Console, including the parts people skip

Verify the new property before you move, not after. An HTML verification file needs to exist on the new site and a meta tag needs to be sitting in the new templates, because if you lose verification on move day you’re flying blind exactly when you most need instruments.

If the domain is changing, use the Change of Address tool. It forwards signals and “tells Google to prefer the new site over the old when determining canonical pages”, but the conditions are narrow:

• You must own both properties in Search Console, under the same Google account.
• It works at domain level only. You “cannot move properties at the path level, such as http://example.com/petstore/".
• Google says to “use this tool for all subdomain variants of the old domain, including www and non-www”.
• Don’t use it for a move from HTTP to HTTPS.
• “After the 180 day period, Google does not recognize any relationship between the old and new sites.”

Google’s own documentation gives two different redirect lifespans. The Change of Address help says “Maintain the redirects for at least 180 days”. The site move documentation says keep them “for as long as possible, generally at least 1 year”, because that window “allows Google to transfer all signals to the new URLs, including recrawling and reassigning links on other sites that point to your old URLs”. Follow the longer one, renew the old domain, and don’t set yourself a calendar reminder to kill the redirects.

Submit a sitemap of the new URLs once the move starts, then remove the old one. Google describes the expected pattern as the old sitemap’s indexed count dropping to zero over time with a corresponding rise on the new one, which makes a useful progress gauge.

Bing runs its own Site Move tool, which needs you to verify ownership with Bing first, and it asks for longer redirects than Google does: “the redirects on the old domain need to remain live for at least 1 to 2 years, preferably longer”. It also expects server logs monitored “at first on an hourly basis, later on a daily basis”.

One tool to leave alone is Removals. Google lists “To move content. This tool won’t remove old content or URLs” among the jobs it isn’t for, and warns that a request “could remove all versions (http/https and www/non-www) of a URL”.

What actually breaks in a site migration

The most expensive failure is the one you can’t see. You built the new site on a test URL and, quite correctly, blocked it from indexing, which is exactly what Google recommends. Then you launched, the noindex tag or the blocking robots.txt came with it, the site looks perfect, and traffic drains away over the following week or two while you admire it.

Analytics is the mirror image, and it produces a false alarm rather than a real one. The homepage carries the tracking tag and the blog post template doesn’t, so traffic appears to have halved when nothing has actually changed. Check every template type, not just the pages you visit.

After those two, the failures get quieter. Media files move to a new path or CDN, so every hotlinked image on other people’s blog posts breaks along with your social preview cards, which means image paths need redirecting as well as pages. A wildcard rule mapping /blog/* to /posts/* can quietly discard ?utm_source=newsletter, at which point email and paid traffic reports as direct and you spend a fortnight thinking a channel died. And plenty of custom “page not found” designs serve an HTTP 200 with an apology on it, which is the soft 404 Google flags when a 2xx response comes back carrying error content. That one does need fixing: a genuinely missing page has to return a real 404. What does not matter is which 4xx you pick, because Google states that “All 4xx errors, except 429, are treated the same” — so 404 and 410 land in the same place, and it is the HTTP 200 that is the bug.

Internal links are the slow leak. Every internal link still pointing at an old URL is a wasted hop, and when you eventually retire the redirects they become 404s, so rewrite them in the content rather than leaning on the map forever. Structured data goes the same way: your Book, Article or Person schema lived in the old theme, and if it doesn’t survive the rebuild the rich results vanish a few weeks later in a way that reads exactly like a ranking drop. Given how much AI-era discovery leans on that markup, it’s worth checking before you launch rather than after.

Two more cost you nothing in rankings and something in credibility. A rebuild routinely drops the cookie banner or the privacy policy, and the policy that does survive usually still describes the old host and the old analytics setup, which a UK reader notices well before Google does. And if you sell books directly from your site, every checkout link you’ve pasted into a newsletter or a book’s back matter is pointing at the old URL.

Finally, expect the new host to change how you’re crawled. Google’s own wording is that a temporary drop in crawl rate straight after launch is normal, followed by a steady increase over the next few days, so a quiet first week isn’t automatically a fault.

Migration day: the launch sequence

Lower your DNS TTL well ahead. Google’s advice is to “Consider lowering the TTL to a conservative low value (for example, a few hours) at least a week in advance of the move to refresh DNS caches faster”, which also means you can reverse the switch quickly if something goes wrong.

Test on a temporary hostname first, beta.yoursite.com or similar, with noindex applied, and confirm Googlebot can reach it using the URL Inspection live test. Then remove the noindex before you go live, because that’s the step that gets forgotten.

Move everything at once if you can. Google recommends “moving all URLs on your site simultaneously instead of moving one section at a time”, and only suggests staging it for larger sites.

Pick your week deliberately, clear of a launch or promotion. Google’s line is that “with any significant change to a site, you may experience ranking fluctuations while Google recrawls and reindexes your site”, and that “a medium-sized website can take a few weeks for most pages to move in our index”, so you want to be at your desk while it settles.

How to verify the migration worked

This is the part that gets skipped, and it’s the only part that turns “I think it’s fine” into “I know it’s fine”.

Within an hour of going live

Take fifteen URLs from your inventory: five highest-traffic pages, five random deep pages, and five oddities such as an image, the RSS feed and a PDF. Then:

Check the actual HTTP response. curl -sIL https://oldsite.com/old-page/ prints every hop and status code. You want one 301 (or 308) landing straight on the intended URL with a final 200. A 302 tells Google the move is temporary, two hops means a chain, and a 200 on the old URL means the redirect isn’t firing at all.

Crawl the whole old-URL list. In Screaming Frog, switch to Mode → List and upload your inventory. Turn on “always follow redirects” under Config → Spider → Advanced, which follows each redirect until it reaches a non-3XX response. Export the All Redirects report, which maps the full chain in one file, and Redirect Chains, which records start and final URLs and flags loops. Anything that isn’t a single hop to a 200 is a bug, and this report is as close to proof as you’re going to get.

Read the live robots.txt and view source on three pages. Do it in a browser, at the real domain. Confirm four things: no noindex, canonical present, canonical absolute, canonical pointing at the new domain.

Request a URL that doesn’t exist. yoursite.com/definitely-not-a-page-12345 must return 404. If it returns 200, fix that before anything else.

Live-test five pages in URL Inspection. The live test tells you whether Google can fetch and render the page as it stands right now. It will not tell you which URL Google has chosen as canonical — that only appears once the page has been indexed, in the main URL Inspection result rather than the live test.

Weeks one to four

The 404 log is the row that earns its keep, because every entry is a real request for a URL you didn’t map. Add it to the map and move on. Bing wants logs checked hourly at first and daily thereafter, which is more than an author site needs; weekly is realistic and catches almost everything.

After the first month, compare at query level, because totals hide the interesting information. A move that goes wrong usually goes wrong in a cluster, one section or one template, and a total will never show you that. Judge recovery against the pre-move trend line, since seasonality moves the absolute number in both directions anyway.

If rankings drop and stay down

Work in order and stop at the first failure. Most cases end at step one or two.

1. Can Google fetch it? Live-test in URL Inspection. Blocked, a server error, or a redirect loop.
2. Is it indexed? Page indexing report, and read the exclusion reason. “Excluded by ’noindex’ tag” and “Blocked by robots.txt” both mean a five-minute fix.
3. Is the canonical right? Once the page is indexed, the URL Inspection result shows Google’s selected canonical next to the one you declared. If they differ, Google has overruled your tag, usually because something else on the page contradicts it. This is the indexed view, not the live test.
4. Is the redirect right? One hop, permanent, correct destination.
5. Is the content actually the same? Rebuilds lose text, and a page that was 1,400 words on the old site and is 300 on the new one didn’t lose its rankings to the migration.

Resist the urge to bulk-redirect everything to the homepage while you work it out, because that converts a recoverable problem into soft 404s across the whole site.

Should you move at all

We build author websites for £199 plus £15 a month for care, so read the next paragraph with that in mind.

If you already have a site that ranks, converts and doesn’t embarrass you, moving it is usually not worth the risk. The honest reasons to move are a platform being discontinued, being unable to edit your own site without paying someone, real slowness on mobile, or paying a lot for something you could run for very little. “It looks a bit dated” isn’t on that list. If you are moving, everything above is doable yourself over a weekend for a site of 50 or 100 pages, the tools are free at that scale, and the only part that needs discipline rather than skill is the verification.

If it’s your book files that worry you rather than your website, the free KDP readiness audit and our book formatting service are a different door.

Frequently asked questions

Do 301 redirects pass SEO value?

Yes. Google’s wording is that “301 and other permanent redirects don’t cause a loss in PageRank”, so a correctly mapped redirect carries the old URL’s link value to the new one. What loses value is the URL nobody redirected at all, or a chain long enough that the signal gets lost on the way. One hop, permanent, to the page that replaces it.

How long should I keep 301 redirects after a site move?

Google’s site move documentation says “for as long as possible, generally at least 1 year”, while its Change of Address help sets a floor of “at least 180 days”. Bing asks for more again: “at least 1 to 2 years, preferably longer”. Follow the longest of those, keep renewing the old domain, and treat switching the redirects off as a job you never quite get round to.

How long does it take to recover rankings after a migration?

Google says “a medium-sized website can take a few weeks for most pages to move in our index”, and that any significant change can bring “ranking fluctuations while Google recrawls and reindexes your site”. Shape matters more than size here: a dip that flattens out week on week is the move settling, while one that keeps deepening is a fault you can find with the checklist above.

Do I need the Change of Address tool if I’m keeping the same domain?

No. It only works between domains at domain level and cannot handle path-level moves. You don’t need a new Search Console property either, though you do need to confirm your existing verification method survived the rebuild. Redirects and a fresh sitemap are the whole job.

How do I find my old site’s URLs without Search Console access?

Your Google Analytics landing-page report going back a couple of years, plus the Internet Archive’s copies of the old site, will reconstruct most of it, and a crawl catches everything still reachable by internal link. Plan on picking up the remainder through your 404 logs over the following months.

Will moving my website affect my Amazon book listings or Author Central links?

Your Amazon listings don’t depend on your website, so the sales pages carry on unaffected. The exposure runs the other way: every link you’ve pointed at your old domain keeps pointing there. Author Central and social bios can be updated in an afternoon, but the back matter of books already printed cannot, which is the strongest argument for keeping the old domain registered indefinitely.

Should I redirect the page for a book I’ve unpublished?

If it has inbound links or any search traffic, redirect it to the closest equivalent: the series page, your author page, or your books index. If it has neither, letting it 404 is fine and honest. What to avoid is sending it to your homepage, which is the pattern Google warns produces soft 404s.