Get a Free Quote

How To Migrate a Website Without Losing Rankings

A website migration is any change significant enough that Google has to re-learn your site: a new platform, a new domain, a new URL structure, a redesign that rewrites the templates, or a consolidation of two sites into one. Rankings do not drop because migrations are inherently dangerous. They drop because the signals Google spent years attaching to your old URLs were not carried across to the new ones, and by the time anyone notices, the evidence of what those signals were has usually been deleted along with the old site.

That is the thing to understand before anything else. Almost every serious migration loss is a preventable data problem rather than an SEO one. The old site held a set of URLs, each with its own links, rankings, internal link equity, metadata and history. If you cannot produce a complete list of those URLs and say where each one now lives, you are not migrating a website, you are launching a new one and hoping.

This guide covers what we do on every migration we run: how our SEO team benchmark the current site before anyone touches anything, the checklist we work through, the redirect and URL decisions that cause the most damage when they go wrong, the canonical and internal linking problems that hide for weeks, and how tracking gets rebuilt so you can actually prove what happened.

Start by deciding what kind of migration you are

Not all migrations carry the same risk, and the plan should be sized to the type rather than run at one setting for everything.

Migration typeWhat changesRisk level
Design or template refreshLook and layout, URLs unchangedLow to moderate
Platform changeCMS, templates, often URL patternsHigh
URL structure changePaths and hierarchy, same domainHigh
Domain changeHostname, everything inheritsHigh
Protocol or hostname changehttp to https, www to non-wwwModerate, often underestimated
ConsolidationTwo or more sites merged into oneHighest
Rebuild with all of the aboveEverything at onceHighest, and hardest to diagnose

The last row is the one to be honest about. Changing platform, domain, URL structure and content in a single release is common in practice, because a business rarely gets budget to rebuild twice. It is survivable, but it removes your ability to isolate a cause. If traffic falls three weeks later, you will not know whether it was the redirects, the thinner content, the slower templates or the lost internal links, and you will end up fixing all four while the losses continue.

Where the timeline allows, separate the changes. Move the platform first with URLs held identical, let it settle, then change the structure. Where it does not allow, accept that the monitoring burden after launch is considerably heavier and plan the resource for it.

Useful tip: A redesign that keeps every URL is still a migration. Templates carry headings, internal links, schema and copy, and a rebuild that halves the word count on every page will cost you rankings even though nothing moved. Treat any change to the templates as a content change, not a cosmetic one.

Benchmark the current site before anything is touched

This is the first thing we do on any migration, and it is the step most often skipped because it produces nothing anyone can look at. It is also the only thing standing between you and an unrecoverable loss, because once the old site is gone, most of this data is gone with it.

We take a full snapshot covering:

A complete crawl of the live site. Every URL with its status code, title, meta description, H1, canonical, indexability, word count, internal link count and depth from the homepage. This becomes the master reference for the redirect map and the metadata transfer, so it needs to be complete rather than a sample.

Every URL Google actually knows about. The crawl finds what is linked. It does not find orphaned pages, old campaign landing pages, or URLs that still earn traffic while being linked from nowhere. Those come from Search Console performance data at page level, GA4 landing page reports, the XML sitemaps, server log files where available, and the backlink profile. Merge all of it. A URL earning links or traffic needs a destination even if nobody internally remembers it exists.

Current performance, page by page. Sixteen months of Search Console data exported at page and query level, organic sessions and conversions by landing page from GA4, and revenue by page where the site transacts. This is what you compare against afterwards, and the page-level detail is what tells you which specific redirect went wrong rather than just that something did.

Rankings. A full position snapshot for your tracked terms, taken within a day or two of launch rather than a month before, so the comparison is clean.

The backlink profile. Referring domains and the exact target URLs they point at. Those target URLs are the ones where a broken redirect costs you the most, and they should be checked individually after launch rather than sampled.

Index and technical baselines. Indexed page counts, the Page Indexing report by status, Core Web Vitals field data, and the existing robots.txt and sitemap setup.

Keep all of it in one place with the date on it. Six weeks after launch, when someone asks whether a page has actually lost positions or was always ranking fourteenth, this is the only thing that answers the question.

Useful tip: Crawl the staging site as well, using the same configuration, and diff the two exports. Comparing old and new on titles, H1s, canonicals, word count and internal link counts surfaces most template-level mistakes before launch, and it takes minutes once both crawls exist. Missing H1s across a whole page type, or word counts that have dropped by 60% on every service page, show up immediately in that comparison and are almost invisible when clicking through the site by hand.

Work through a checklist rather than from memory

We run every migration against a bespoke checklist built from what has gone wrong on previous ones, worked through in order, with an owner and a sign-off against each item. It exists because migrations fail on the unglamorous items rather than the interesting ones, and because the work is split across a developer, a designer, a content team and whoever owns the DNS, all of whom reasonably assume somebody else has the SEO items covered.

The checklist runs across four stages:

Before the build. Benchmarking complete, URL structure agreed and signed off, redirect map drafted, staging environment secured from indexing, tracking plan agreed.

During the build. Metadata transferred, canonicals correct, internal links pointing at final URLs, structured data carried over, robots and sitemaps prepared, redirects built and tested on staging.

Launch day. Staging protections removed, redirects live and verified, tracking firing, sitemaps submitted, spot checks on the highest value URLs.

After launch. Daily monitoring for the first week, weekly for the first two months, with defined checks and defined thresholds for what warrants investigation.

The value is not that any single item is difficult. It is that nothing gets missed at three in the afternoon on launch day when the developer is under pressure and the client is asking why the contact form looks different.

Get the URL prefix right, because this one is silently expensive

Every site has a canonical hostname and protocol: https://example.co.uk or https://www.example.co.uk, one or the other, never both. This is the single most common thing to go wrong at launch and the one clients most often live with unknowingly for months.

What happens is straightforward. The old site ran on non-www. The developer sets the new site live on www, or on a new stack that defaults to www, and configures the redirect map correctly relative to that. Every old URL now resolves, so everything looks fine. But each request is being sent from the old URL to the old URL’s www equivalent to the new URL, and a redirect that should have been one hop is now two or three.

That looks like this:

http://example.co.uk/services/

  →  https://example.co.uk/services/

    →  https://www.example.co.uk/services/

      →  https://www.example.co.uk/what-we-do/

Four URLs to serve one page. Google follows redirect chains, so nothing appears broken in the browser and nothing throws an error in a crawl summary. What it does is slow every crawl, waste crawl budget across the whole site at once, and weaken the consolidation of link signals at every extra hop. On a large site it is a meaningful drag on recovery speed, and it compounds with every redirect already in place from previous changes.

So we fix the prefix first and build the redirect map against the final, agreed hostname:

  • Decide www or non-www and protocol before the redirect map is written, not after
  • Every old URL redirects in one hop to its final destination on the correct hostname and protocol
  • The non-canonical hostname redirects to the canonical one at server level, once
  • Trailing slash behaviour is consistent and enforced, since /services and /services/ are different URLs
  • URLs are lower case and enforced, since /Services/ and /services/ are different URLs too
  • Both hostname variants and both protocols are added as properties in Search Console so you can see what is actually being requested

Useful tip: After launch, crawl your full list of old URLs as a list crawl and report on redirect chains and hop counts specifically, not just final status codes. A report saying “100% of old URLs return 200” is compatible with every single one of them going through three hops to get there. Look at the hop count column, and re-point every chain at its final destination directly.

Map every redirect, including the pages you are deleting

The redirect map is the core deliverable of a migration. It is a row per old URL with its new destination, built from the merged URL list rather than from the site navigation.

The rules we work to:

One to one wherever a genuine equivalent exists. The old services page goes to the new services page. This covers most of the map on a like-for-like rebuild.

301, not 302. A temporary redirect tells Google to keep indexing the old URL and not to pass the signals across permanently. Developers default to 302 more often than you would expect, particularly on framework-level redirects, so this gets checked rather than assumed.

Removed pages go to the closest relevant page, not the homepage. Every migration removes something: old service lines, dead blog posts, discontinued products. Each one still needs a destination, and it should be the nearest thing a visitor arriving from that link would want. A discontinued product goes to its category or its replacement. An old blog post goes to the piece that superseded it. Mass-redirecting a few hundred removed URLs to the homepage gets them treated as soft 404s, which throws away whatever links they held and gives the visitor nothing.

Where nothing relevant exists, return a 410 deliberately. Better an honest gone than a pointless redirect, and it gets the URL dropped cleanly.

Assets and non-HTML URLs are in scope. Images, PDFs, brochures and spec sheets earn links and rankings of their own, and they are routinely left out of redirect maps entirely.

Old redirects are collapsed, not stacked. If the current site already redirects a legacy set of URLs, those legacy URLs need to point at the new final destination directly rather than at the current intermediate one. This is where chains breed.

Test the map on staging before launch, with the full old URL list run against it, and again within the hour after launch. Then check the specific URLs holding your best backlinks individually, because those are the ones where a failure costs the most and a sample will not find them.

Useful tip: Keep the redirect map as a permanent document, not a launch artefact. Twelve months later somebody will ask why a URL behaves oddly, and the map is the answer. It is also what you hand to the next agency, which saves a repeat of the whole benchmarking exercise.

Transfer the metadata rather than regenerating it

Titles and meta descriptions written and refined over years are an asset, and a platform change frequently discards them in favour of whatever the new CMS generates from the page name. The result is a site where every title suddenly reads “Boiler Repair | Brand Name” because the template says so, and clickthrough rates fall across the board while positions look broadly unchanged.

We transfer, from the pre-migration crawl, against the new URLs:

  • Page titles and meta descriptions
  • H1s and the heading structure beneath them
  • Image alt text
  • Structured data, including LocalBusiness, Organization, FAQ, Product and Article markup, with IDs and URLs updated to the new domain
  • Open Graph and Twitter card tags
  • hreflang annotations, updated to the new URLs on both sides of every pair

Then crawl the new site and compare against the old export, field by field. Missing titles, duplicated titles across a page type, empty H1s and truncated descriptions all show up in that diff in a way they never do by eye.

Content is part of this too. Where a redesign has cut the copy on key pages to suit a new layout, that is a ranking change waiting to happen, and it is better identified in the word count comparison before launch than inferred from a traffic chart afterwards.

Check the canonical tags, particularly what they point at

Canonical tags are the quietest way to lose a migration, because a wrong canonical produces a page that loads perfectly, looks perfect, and is not indexed.

Three failures are worth checking specifically:

Staging URLs left in the canonical tag. The most damaging and the most common. The site is built on staging.example.co.uk or a developer subdomain, canonicals are generated absolutely, and the base URL is not updated at launch. Every page on the live site now tells Google that the authoritative version of itself lives on a staging domain that is either password protected, noindexed or offline. Google is being instructed by your own markup to disregard the live page. Crawl the live site after launch and filter for any canonical that does not contain the live hostname, before anything else.

Canonicals pointing at the wrong hostname or protocol. The same problem as the prefix issue, expressed in markup. If the site serves on www but canonicals are written non-www, you have created a contradiction between your redirects and your tags.

Pages canonicalised to a parent. A template that sets the canonical to a parent category or a hub page removes the child pages from the index by instruction. This one is usually a well-meaning attempt to handle duplication that has been applied too broadly.

Every indexable page should carry a self-referencing canonical using the final, absolute, live URL. Anything else needs a reason.

Useful tip: Check the same thing in reverse before launch. Staging sites need to be blocked from indexing while they are built, ideally by HTTP authentication rather than robots.txt alone, since a disallowed staging URL can still be indexed if it picks up a link. Then make sure the block is removed at launch. A site launched with noindex still on the templates, or Disallow: / still in robots.txt, is the other half of this problem and it disappears from Search Console faster than anyone expects.

Fix the internal links rather than relying on redirects to carry them

Redirects handle external links and old bookmarks. They should not be doing the work for your own navigation.

After launch, every internal link should point at its final destination directly: navigation, footer, breadcrumbs, in-body links in blog posts and service pages, image and CTA links, and anything hardcoded into templates or widgets. Links inside body content are the ones that get missed, because migrating content wholesale carries the old absolute URLs across with it.

Internal linking is also a ranking signal in its own right, and a redesign can quietly dismantle it. A new navigation that drops the services mega-menu in favour of a tidier three-item header can remove hundreds of internal links from your most commercially important pages overnight. That is why the internal link count per URL comes out of the benchmarking crawl and gets compared afterwards. If a page went from ninety internal links to four, that is a cause, and it is visible in a column rather than in a hunch.

Sitemaps get rebuilt at the same time: new URLs only, final destinations only, no redirected or noindexed URLs included, submitted at launch. Keeping a temporary sitemap of the old URLs for a few weeks is a legitimate trick to accelerate discovery of the redirects, as long as it is removed once they have been processed.

Rebuild tracking so you can prove what happened

Analytics rarely survives a migration untouched, and losing measurement at the exact moment you need it is a bad trade.

GA4. Confirm the tag fires on every template of the new site, not just the homepage. Rebuild conversion events, since form IDs, button classes and thank-you page URLs almost always change. Check enhanced measurement settings, ecommerce events and any custom dimensions. Re-link Google Ads and Search Console. Update referral exclusions and cross-domain settings if the domain has changed. Then add an annotation on the launch date, because in eight months nobody will remember exactly when it happened.

Search Console. Add and verify the new property before launch where the domain is changing, keep the old property, and use the Change of Address tool once the redirects are live. Verify both hostname variants and both protocols. Submit the new sitemaps. Watch the Page Indexing report by status rather than the overall count, since the shape of the change tells you more than the number.

Everything else. Bing Webmaster Tools, Google Tag Manager containers and triggers, call tracking numbers and dynamic number insertion, heatmap and session recording tools, CRM lead source tracking, and rank tracking pointed at the new domain.

Keep read access to the old property. The historical data lives there, and once the domain lapses it becomes considerably harder to work with.

Launch day, in order

SequenceAction
Before launchFinal crawl of the old site, final rank snapshot, final GSC export
LaunchDeploy, confirm the correct hostname and protocol resolve
Immediately afterRemove staging protections, check robots.txt and noindex tags
Immediately afterRun the full old URL list through a list crawl, check status codes and hop counts
Immediately afterCrawl the live site, check canonicals and indexability
Within the hourConfirm GA4 and tag firing in real time
Same daySubmit sitemaps, request indexing on key pages, Change of Address where relevant
Same daySpot check the top twenty URLs by traffic and the top twenty by backlinks, individually
Day one to sevenDaily monitoring of crawl errors, index status, redirect failures and traffic by landing page

What to expect afterwards

Some fluctuation is normal, and reacting to week one is how good migrations get undone. A like-for-like migration with clean redirects often shows a modest dip for two to four weeks while Google reprocesses. A domain change usually takes longer, commonly six to twelve weeks before things settle, and longer again on large sites where crawling the full URL set takes time.

What is not normal is a sharp fall that keeps falling, a collapse in indexed pages, or a specific page type dropping out while the rest holds. Those are diagnosable faults rather than settling, and the benchmark data is what turns them from a panic into a list of URLs to check.

Common mistakes and what to do instead

MistakeFix
No crawl of the old site before it is replacedBenchmark everything first, while the data still exists
Redirect map built from the navigationBuild it from crawl, GSC, GA4, sitemaps, logs and backlinks combined
Site launched on www when it was non-wwwAgree the prefix first, redirect in one hop to the final hostname
Redirect chains left in placeReport on hop count, re-point every chain at its destination
Removed pages redirected to the homepageClosest relevant page, or a deliberate 410
302s used throughout301 for anything permanent
Staging URLs left in canonical tagsCrawl live and filter canonicals by hostname on day one
noindex or Disallow: / shipped to productionRemove staging protections as a named launch step
Internal links relying on redirectsUpdate every internal link to its final URL
Metadata regenerated by the new CMSTransfer titles, descriptions, headings, alt text and schema from the old crawl
GA4 conversions not rebuiltRebuild events, annotate the launch, re-link properties
Judged after ten daysGive it eight to twelve weeks, monitor against the benchmark rather than against feel

Where to start

Before anyone writes a line of code, benchmark the current site and agree the URL structure, hostname and protocol. Those two things set up everything else, and both become much harder once the build is underway.

Build the redirect map next, from the merged URL list, and test it against staging rather than against production. Run the old and new crawls side by side and resolve every difference in metadata, canonicals, headings and internal linking before launch rather than after.

Then launch to a sequence, with tracking verified the same day, and monitor daily for a week against the numbers you captured at the start. The migrations that go well are not the ones that avoid problems. They are the ones where the problems are found in week one, with the data to hand to prove what changed.

Frequently asked questions

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

A like-for-like migration with clean one-hop redirects typically settles within two to four weeks. A domain change more commonly takes six to twelve weeks, and longer on large sites. If positions are still falling after that, treat it as a fault to diagnose rather than a process still bedding in.

Will I lose rankings when I migrate?

Some short-term movement is normal. Lasting losses are almost always traceable to a specific cause: missing or chained redirects, canonicals pointing at staging, metadata regenerated by the new platform, internal links stripped out by a new template, or thinner content on key pages. Every one of those is preventable with a proper benchmark and checklist.

Should I change my URL structure at the same time as my platform?

Ideally not. Holding URLs identical through a platform change removes most of the risk and lets you isolate any problem that does appear. Where the timeline forces both at once, it is workable, but the redirect mapping and post-launch monitoring need proper resource.

Do I need to keep the old domain after migrating?

Yes, indefinitely. The redirects only work while the old domain resolves, and the links pointing at it do not get updated by the people who placed them. Renewing a domain is trivially cheap compared with the links it carries.

What is the most common technical mistake in a migration?

The URL prefix. Launching on www when the site was previously non-www, or the reverse, adds an extra redirect hop to every single URL on the site. Nothing appears broken, which is exactly why it survives to production and then sits there for months.

Can I migrate in phases?

Often yes, and it is usually safer. Moving a blog, a section or a subset of templates first gives you a controlled test of the redirects and tracking before the commercially critical pages move.

When is the best time to launch?

Early in the week, in the morning, and outside your peak trading period. Launching on a Friday afternoon means any fault runs unattended for three days, and the first few hours after launch are when the expensive mistakes are cheapest to fix.

How To Do Local SEO for Multiple Locations

Multi-location SEO means ranking one brand across several towns, with a dedicated page and a real local presence behind each one. Google judges every location on its own merits, so reviews in Newcastle do nothing for your Sunderland rankings, and a strong showing in Liverpool will not carry Manchester. The work is repeatable, but it has to be done for each area rather than run centrally and hoped for. Google’s E-E-A-T guidelines are guide you on exactly what they deem to be Experience, Expertise, Authoritativeness, and Trustworthiness.

That is where most multi-location campaigns come unstuck. At ten or twenty locations the temptation is to publish one set of content and send one review request to everybody, and what you end up with is a single strong location surrounded by several that never get going. This guide covers the decisions that avoid that: the model you are actually operating, how to structure the site and what each option costs, which towns deserve a page, and the local signals that decide whether any of it ranks.

Start by Deciding Which Local Model You Are

Google draws a firm line between businesses customers visit and businesses that travel to customers, and nearly every decision after this one depends on which side you sit.

A premises business has an address the public can attend during opening hours, such as a clinic, a showroom, a shop or a solicitor’s office. It shows a full address on its Google Business Profile, and how close each branch sits to the searcher drives a great deal of its map visibility.

A service area business goes to the customer instead: plumbers, electricians, removals firms, mobile groomers, care providers. It hides its street address and lists the areas it covers, which means its map visibility is anchored to wherever its verified base sits rather than to every town on the list.

Plenty of UK businesses are hybrids, with a trade counter in one city and engineers covering the wider region, or two offices serving clients across the North. Hybrids run both approaches at once.

Naming your model matters because it sets a realistic ceiling. Where you have no premises, no staff and no base in a town, you can win organic positions through content and links, but you will rarely appear in the map pack. Anyone promising you both without a verifiable presence is describing a listing that gets suspended, and getting a suspended profile reinstated is considerably harder than earning one properly in the first place.

Useful tip: Google limits how many service areas one profile can cover, so list the areas that produce revenue rather than blanketing the region. Vague, oversized service areas dilute the relevance signal rather than extending it.

The four ways to structure a multi-location website, and what each costs

This is the decision with the biggest cost implications, and it is worth making deliberately rather than inheriting it from whoever built the site. Four structures are available, and they range from a few hundred pounds to an ongoing programme.

StructureExampleSuitsRelative cost
One page covering all areasbrand.co.uk/areas-we-coverTwo or three towns, low competitionLowest
Location pages in subfoldersbrand.co.uk/boiler-repair/locationAlmost everyoneModerate to build, low to extend
Subfolders with topical clustersService hubs, town pages and supporting content, interlinkedCompetitive markets, ambitious growthHighest, and the most durable
Separate sites or subdomainsbrandlocation.co.uk or location.brand.co.ukDistinct brands, franchises, acquisitionsHighest ongoing, weakest per pound

The single coverage page

The cheapest option lists every area you serve on one page. It rarely ranks for anything specific, because a page mentioning eleven towns is not the best answer for any of them, but it works for a business covering two or three towns in a quiet market where nobody else has bothered. Treat it as a starting point rather than a strategy.

Location pages in subfolders

The standard approach, and the right one for most businesses. Each town gets its own page on the main domain, following one consistent URL pattern, so every new page inherits the authority the site already holds. A Sunderland page added next year starts from a much stronger position than a brand new domain would.

The cost sits in the writing rather than the build. A page that genuinely reads as though it was written about that town takes a few hours of research and interview time, and the template itself is built once.

Subfolders with topical clusters

The version we recommend where the market is competitive or the ambition is more than a handful of towns. Rather than treating location pages as a flat set, you build layers that support one another:

  • A service hub covering the work itself in depth, such as /boiler-installation/
  • Service and town pages beneath it, such as /boiler-installation/newcastle/
  • A location hub for each town pulling together everything you do there, such as /locations/newcastle/
  • Supporting content answering the questions around the decision, such as a regional cost guide or a piece on what a particular council requires

Each of those links to the others in a deliberate pattern, so the whole cluster carries more weight than the individual pages would. It is the most expensive route because it needs planning, a content programme rather than a one-off build, and someone maintaining the internal linking as it grows. It is also the only one that reliably wins competitive terms, and the advantage compounds rather than plateauing.

Separate sites or subdomains

The most expensive option by some distance, and the weakest value in almost every case. Splitting your coverage across five domains asks Google to build trust in five separate businesses that share a phone number and a photo library. In practice one ranks, a couple limp along, and the rest sit unindexed while still costing you hosting, certificates, updates and content time.

There are genuine exceptions. A franchise with independent ownership and its own trading name needs its own site. So does an acquisition with fifteen years of local equity, at least until a redirect plan has been thought through. Distinct service lines aimed at completely different buyers can justify separation too, though a subfolder usually serves you better than a new domain. Wanting to appear in one more town is not on the list.

Useful tip: Google’s spam policies treat pages and sites built mainly as near-identical entry points funnelling everyone to one destination as doorway content. A network of town microsites pointing at a single office fits that description closely, which is worth knowing before anyone sells you one.

Choosing which towns are worth a page

Start with the data you already have rather than a keyword tool. Search Console will show you which town names you already collect impressions for without trying, and anything sitting just off the first page is the cheapest win available, because Google has already decided you are plausibly relevant and is waiting for a reason to promote you.

Then size the opportunity by value rather than volume. Search figures for service plus town queries in the UK are small and heavily rounded, so treat them as a rough ordering rather than a forecast. A town producing two enquiries a month at an average job value of £1,800 deserves far more attention than one producing fifteen enquiries worth £45.

Look at the actual results pages next, one town at a time, because they tell you what a page can realistically achieve. If the map results sit at the top and everything organic beneath them is Yell, Bark or Checkatrade, there is room for a good page to take positions while you work on the profile separately. If three established local firms hold those spots with pages full of real local detail, be honest about the work required before committing.

Group the smaller places sensibly. Villages a few miles from a town rarely justify their own page and are better covered inside the town page they orbit, named in the copy and in a coverage list that reflects where you genuinely travel.

Useful tip: Keep a simple keyword map with four columns: the town, the one primary term that page owns, the exact URL, and the supporting variations. No primary term should appear against two URLs. When two of your own pages start swapping positions for the same search, or impressions split across two URLs in Search Console, that map tells you which page to consolidate or re-scope.

Writing location pages that hold up

There is one test worth applying before anything goes live. Swap the town name for a different one and read the page again. If nothing else needs changing, the page has no reason to exist, and Google will usually agree by crawling it once and quietly leaving it out of the index.

Passing that test means writing about the place rather than around it. Name the jobs you have done there, with the customer’s permission and enough detail to be recognisable. Introduce the engineer or consultant who actually covers that patch. Use photographs taken on site rather than stock images. Pull through reviews from customers in that town. Be honest about travel times and where you are slower to reach, which costs you a few unsuitable enquiries and buys credibility with everyone else.

The richest material is usually local regulation and local housing stock. Building control, waste carrier duties, parking permits and conservation area rules genuinely differ by council, and they are checkable facts rather than filler. Victorian terraces in one town and 1970s estates in the next produce different jobs, different costs and different objections, and a page reflecting that reads as though someone has actually been there.

Alongside the writing, each page needs the practical things a local visitor looks for within seconds: the address and a local phone number in text rather than an image, a map for that specific location, the services offered there, and an obvious way to get in touch. Build five of these properly before you build fifty, because a small set that local readers recognise as accurate will outperform forty templated variations and will survive the next quality update.

Useful tip: Most location page projects fail on indexing rather than ranking, so check that before blaming the content. Put your location pages in their own XML sitemap and read the Page Indexing report in Search Console for that group alone. “Crawled, currently not indexed” usually means the pages are too thin or too similar. “Duplicate without user-selected canonical” means Google has decided another of your pages says the same thing better. Also check nobody has pointed a canonical tag from your location pages at a parent service page, which removes them from the index by your own instruction.

Google Business Profiles across several locations

For anyone with premises, the profile is the strongest single influence on map visibility, and each location needs its own verified listing rather than one account with a wide radius drawn around it. Doing one properly is an afternoon. Doing thirty needs a system, and at that point a management platform earns its keep.

The fundamentals repeat each time: accurate details matching the website exactly, the right primary category with sensible secondaries, complete hours including bank holidays, real photographs of that branch refreshed now and then, and a description that names the neighbourhood or a nearby landmark rather than repeating head office boilerplate across every listing.

Category choice deserves more thought than it usually gets, because your primary category influences which searches you appear for far more than the description does. Where two branches handle different mixes of work, their categories should reflect that rather than defaulting to whatever was chosen first.

Useful tip: Where branches sit close together in the same city, set each profile’s service area to the neighbourhoods genuinely nearest to it rather than a radius covering the whole city. A Jesmond branch and a Gosforth branch should not both be claiming the same six suburbs. Two branches three miles apart with matching categories and overlapping areas end up competing with each other, and you get two mid-ranking listings instead of one strong one. Some overlap at the midpoint is normal and is simply proximity working as intended.

Keeping your business details consistent everywhere

Google cross-references your name, address and phone number across the web to satisfy itself that a location is real, and mismatches create doubt that costs visibility. One branch listed as Suite 2 on your site, Ste 2 on a directory and Unit 2 elsewhere is a small gap that compounds across dozens of sources.

Multi-location businesses are far more exposed to this than single-site ones. You open a branch, update the website and the profile, and dozens of directories quietly populate themselves with whatever they can scrape. Old listings from a previous address usually survive too, competing with the current one.

Be careful with advice found online here, because most of it is written for the American market and names data aggregators that carry little weight in the UK. The sources worth your attention are Bing Places, Apple Business Connect, Yell, Thomson Local, FreeIndex, Cylex and 192.com, plus whichever vertical directories matter in your sector: Checkatrade, MyBuilder, Rated People and TrustATrader for trades, or Trustpilot and Feefo more broadly.

Useful tip: Your registered address at Companies House is public and gets scraped into directory listings, so if your trading address differs from your registered one you will generate inconsistencies you never created. Keep a master record of every location’s exact details in one place, treat it as the source of truth, and audit the top twenty directories per location once a quarter for duplicates and outdated entries.

Building reviews for each location separately

Reviews influence both where you appear and whether anyone chooses you once they see you, and the signal does not transfer between listings. A company-wide review request pointing at the flagship branch is the single most common reason a newer location sits on twelve reviews while the original has two hundred.

Steadiness beats totals, so a handful arriving every month reads better than fifty collected in one week two years ago. Ask when the customer is happiest rather than a week later, make it one tap with a location-specific link sent by text, and reply to everything within a day or two in a voice that sounds like the branch rather than head office.

Two rules apply and both have teeth. Google prohibits incentivising reviews and prohibits gating, which means you cannot screen for happy customers before deciding who gets the link. Separately, the Digital Markets, Competition and Consumers Act 2024 brought fake and incentivised reviews within the Competition and Markets Authority’s enforcement powers, which include turnover-based penalties. Buying reviews stopped being merely risky and became a legal exposure, which is worth saying plainly to anyone still tempted.

Content that supports your location pages

Location pages catch people who already know what they want and where they are. Everything else you publish reaches them earlier, and gives you somewhere natural to link from when a town page needs strengthening.

The formats that consistently earn traffic in UK local markets are cost guides with regional figures updated each year, explainers covering what a specific council requires and how long it takes, seasonal pieces tied to local conditions such as hard water or flood risk, comparisons answering the decision a customer is stuck on, and follow-up pieces answering what customers ring you about a week after the job. That last category tends to earn links from community groups and local forums, which are among the few genuinely local links available to most businesses.

Write these once, properly, and revisit them annually. One regional cost guide that ranks will outperform a year of weekly filler and will feed links into every town page you attach it to.

Turning up in AI answers as well as search results

AI Overviews and assistants now answer a fair share of local questions before anyone clicks, and they choose businesses slightly differently from classic search. They lean heavily on corroboration, reconciling your site, your profile, your directory listings and any third-party mentions of you. Where those disagree, you become a weaker candidate than a competitor whose details match everywhere.

That makes the unglamorous consistency work above the foundation of AI visibility rather than a separate exercise. Beyond it, answer questions directly at the start of a section before the supporting detail, keep every location’s profile complete, and earn mentions on sources the models already trust, including local press and trade bodies. A business described consistently by other people is much easier to recommend than one that only describes itself.

Useful tipL Track this manually for now. Ask the main assistants the questions your customers would ask, town by town, and record whether you appear and what they say about you. The tooling in this space is changing fast enough that anything you buy today may be redundant in six months.

Measuring it properly

Portfolio reporting hides the problem. Total organic traffic can rise for a year while three of your eight locations quietly decline, and the first anyone notices is when the phone stops.

Break every number down by location: the main town search in both map and organic results, profile views, calls and direction requests, enquiries from the location page, and review count with average rating. Rank tracking has to be location-specific, because a search made in Newcastle and one made in Sunderland return different map results whatever a national tracker reports.

Roll it up into one report so leadership sees the whole portfolio and your team sees the outliers. For anyone with premises, direction requests deserve particular attention, since they are the closest thing to a measurable visit.

Common mistakes and what to do instead

MistakeFix
A separate website for each townConsolidate onto one domain and redirect carefully
One page targeting several townsOne town per page, one primary term each
Swapped town names in otherwise identical copyRewrite with local detail that cannot be copied
Location pages linked only from the footerLink them from service pages and relevant content
One review link for the whole companyLocation-specific links routed by who served the customer
A profile registered at a virtual officeRemove it before it gets suspended
Following UK citation adviceUse UK sources relevant to your sector
Reporting at portfolio level onlyBreak every metric down by location

Where to start

Spend the first month deciding your model, choosing your structure, pulling existing town queries from Search Console and sizing the opportunity by job value. Use the second month to build five pages properly and to sort the profiles and review routing for those same five locations, so the on-site and off-site work lands together rather than months apart.

New pages in competitive local markets rarely settle inside eight to twelve weeks, and judging them earlier leads to changes that undo work still bedding in.

Check whether those first five pages are indexed before building the next batch. If they are indexed and gaining impressions, scale using the same pattern. If they are sitting unindexed, adding thirty more multiplies the problem rather than diluting it, and the fault will be in the pages rather than the number of them.

Frequently asked questions

How do you rank a business in multiple towns in the UK?

Build one page per town on a single domain, each targeting one primary local search, and support each area with a verified Google Business Profile where you have a genuine presence, consistent business details across directories, and reviews from customers in that town. Google judges each location independently, so every area has to earn its position.

Do I need a separate website for each location?

Almost never. Separate domains split your authority and multiply the maintenance, while pages on one domain mean each new location inherits the trust the site already holds. Separate sites make sense only for genuinely distinct brands, franchises with independent ownership, or acquisitions whose existing local equity would otherwise be lost.

What does multi-location SEO cost?

It depends almost entirely on the structure you choose. A single coverage page is a few hundred pounds of work. Location pages on one domain cost more to write than to build, since the research is what makes them rank. A full cluster structure with service hubs, town pages and supporting content is an ongoing programme rather than a project, and separate sites per town cost the most while delivering the least.

Do I need a Google Business Profile for every location?

Yes, where each location is real premises with staff, or a verifiable base for a service area business. One profile with a wide radius drawn around it is not equivalent to several verified listings, and registering an address you do not occupy risks suspension.

How many reviews does each location need?

There is no number that guarantees anything, since it depends on what competitors in that town already hold. Steady accumulation matters more than the total, so a few arriving every month is a stronger signal than a large batch collected once.

Can I use the same phone number for all locations?

You can, and it will not break anything, but a local number matching the town helps both customer trust and local relevance. Where a central number is necessary, keep it identical everywhere rather than mixing formats across directories.

Will my own locations compete against each other?

They can, when service areas, categories and page content overlap heavily, which leaves you with two mid-ranking listings instead of one strong one. Distinct service areas and genuinely different page content prevent most of it.

How long does multi-location SEO take?

Expect eight to twelve weeks before new location pages settle, and longer in competitive markets or on a newer domain. Profile and review work often moves faster, since map positions can respond within weeks.

AI Chatbot vs Live Chat: Which Is Right for Your Business?

If you’ve been thinking about adding chat to your website, you’ve probably run into two very different options. Live chat, where a real person types back, and AI chatbots, which answer instantly using your own business information. They look similar to a visitor, a little chat box in the corner of the screen, but how they actually work, and what they cost you, are worlds apart.

How live chat actually works

Live chat means a real person, you, a member of staff, or an outsourced agency, is on the other end typing responses in real time. It’s genuinely personal. A tricky, unusual question gets a proper, considered answer from someone who understands the full context.

The catch is coverage. Live chat only works while someone’s actually available to answer it. Outside those hours, it either disappears from your site entirely or sits there showing “we’re offline”, which to a visitor looks much the same as no chat at all.

How an AI chatbot actually works

An AI chatbot is built to answer using your website’s own content, your services, prices, opening hours, FAQs, so a visitor gets a genuine answer instantly, day or night. It’s not a person, and it won’t have a natural conversation about something outside what it knows. What it will do is answer the vast majority of routine questions immediately, and hand anything more complex over to you as a proper lead rather than losing the visitor entirely.

Coverage

This is the biggest practical difference. Live chat is only as good as your team’s availability. An AI chatbot doesn’t take evenings off. For a trade business getting enquiries at 8pm, or a restaurant getting questions about Sunday opening hours on a Saturday night, that gap matters more than it sounds.

Cost

Live chat, if it’s staffed properly rather than just left unattended half the time, means paying someone’s time to sit and answer messages, whether that’s an existing staff member being pulled off other work, or an outsourced live chat service charged by volume or by the hour. An AI chatbot is normally a flat monthly cost regardless of how many conversations it handles, which makes it far easier to budget for and, for most small businesses, considerably cheaper than staffing chat properly.

Consistency

A chatbot gives the same accurate answer every time, based on the same source information, whoever’s asking and whenever they ask. Live chat depends on whoever happens to be answering that day, their mood, their knowledge, how busy they are. Neither is inherently better, but consistency is one place a chatbot has a genuine edge.

What each one is actually good at

Live chat wins for:

  • Complex, unusual, or sensitive questions that need real judgement
  • Building a personal relationship during the conversation itself
  • Businesses with the staff capacity to genuinely monitor it during working hours

An AI chatbot wins for:

  • Answering routine questions instantly, any time of day
  • Capturing leads outside working hours instead of losing them
  • Keeping cost predictable and low
  • Small businesses without spare staff time to sit and answer chat all day

So which one’s right for your business?

For most small businesses, trades, restaurants, and retailers included, the honest answer is that an AI chatbot does more of the job that actually matters, catching enquiries you’d otherwise miss, for a fraction of what proper live chat coverage costs. Live chat makes more sense for businesses handling genuinely complex enquiries all day, with staff who already have capacity to answer it properly.

Some businesses end up using both, an AI chatbot to catch everything and answer the routine stuff instantly, with a clear route through to a real person for anything it can’t handle. That combination tends to give you the coverage of a chatbot without losing the option of a proper human conversation when it’s genuinely needed.

If you’d like to see what this would actually look like for your website, our AI chatbot service is built specifically around this, answering real questions from your own content, catching leads around the clock, fully managed so there’s nothing for you to maintain.

FAQ

For most small businesses, yes, in the sense that it covers the majority of routine questions a live chat agent would otherwise handle, at a fraction of the cost and around the clock. Very complex or sensitive enquiries are still better handled by a real person.

It depends how it’s set up, but a well built chatbot is generally upfront about what it is, which tends to build more trust than pretending otherwise, and most customers are perfectly happy getting an instant, accurate answer either way.

Not compared to staffing live chat properly. Ours is £30 a month, fully managed, with no setup cost for existing clients, considerably less than the ongoing cost of a staffed live chat service.

Yes, some businesses use a chatbot to handle the routine questions and out-of-hours coverage, with a clear option to speak to a real person for anything more complex during working hours.

WordPress 7.1 Broke My Site? Here’s How to Fix It

WordPress 7.1 went live on 19 August 2026, and within days it had knocked a number of sites offline and broken the editing screen for plenty more. If your site suddenly looks wrong, won’t let you edit content, or has vanished altogether since updating, you’re not alone, and it’s very likely fixable in minutes, not days.

What went wrong

Three separate issues have caused most of the problems:

1. Sites going completely offline (WP Rocket users)

A bug between the popular caching plugin WP Rocket and WordPress 7.1 caused sites using its Cloudflare feature to crash with a fatal error the moment they updated. The fix had actually been reported over a month before release but wasn’t patched in time. WP Rocket pushed an emergency fix the day after launch, so if this is you, updating the plugin to the latest version should solve it straight away.

2. The editor becoming unusable (custom blocks)

Anyone using Advanced Custom Fields (ACF) or other custom built content blocks has reported the page editor becoming a mess, with blocks piling up in the sidebar and pages becoming impossible to edit properly. This is a direct result of a change to how WordPress loads the editor in 7.1, and it mainly affects older or custom blocks that haven’t been updated to match.

3. Admin screens behaving oddly

WordPress made some behind the scenes changes to the post list screen in wp-admin, partly to improve accessibility. It’s a good change in principle, but it can clash with plugins or custom admin styling that weren’t built to expect it.

Is your site actually affected?

Not every site will notice a thing. The businesses most at risk are ones using:

  • WP Rocket with the Cloudflare integration
  • Advanced Custom Fields, or any theme or plugin combination with custom content blocks
  • Older or heavily customised admin dashboards
  • Plugins or themes that haven’t been updated in the last few months

If none of that applies and your site’s still running smoothly, there’s nothing you need to do beyond your usual checks.

What to do if your site’s broken right now

  1. Don’t panic, and don’t restore from backup yet. Most of this is a plugin conflict, not lost data.
  2. Update your plugins first, especially WP Rocket if you use it. Several plugin developers have already shipped fixes.
  3. If the editor’s the problem, check whether your theme or key plugins have a newer version that mentions WordPress 7.1 compatibility.
  4. Still stuck? Rolling back to WordPress 7.0.4 temporarily is a safe short-term fix while you wait for a proper plugin update.
  5. Going forward, test major WordPress updates on a staging copy of your site before applying them live.

How we help clients avoid this altogether

This is exactly the kind of thing our website care plans exist for. Rather than updates landing straight on your live site, we test them on a staging copy first, catch conflicts like this before your customers ever see them, and keep your plugins and themes up to date on a proper schedule instead of all at once.

It’s a lot cheaper than a day of lost sales while your site’s down. If today’s update has caught you out, visit our website maintenance page to see how our care plans work and get your site properly protected.

Why this matters for more than just convenience

A broken or offline website doesn’t just cost you sales while it’s down. Google notices too. Site downtime, broken pages, and a poor mobile experience all work against you in search rankings, on top of the immediate loss of customer trust. If your site’s been affected, getting it fixed quickly isn’t just good housekeeping, it protects the position you’ve already earned in Google.

FAQs

No. Unless there’s a specific security reason to update immediately, it’s sensible to wait a week or two while plugin developers catch up with fixes, or update on a staging site first.

No, major breakages like this are the exception, not the rule. This particular release changed some fairly deep technical foundations, which is why the impact has been wider than usual.

If your site is down or broken, deactivating your plugins one at a time, or all at once and then re-enabling one by one, will usually reveal which one is causing the conflict.

Recent Comments

No comments to show.