Canonical Tags for Multi-Location Clinic Chains: Self, Cross-Location or Neither

This post is for the SEO or web lead of a clinic or hospital chain with several branches that all offer the same services. The question it answers is specific: when the "knee replacement" page exists once for each of twelve branches and the text is largely the same, what should each page's canonical tag say?

Our earlier posts on branding consistency across locations, SEO and branding for hospital chains and scaling multi-location marketing cover the strategy and brand side. This one does not repeat them. It deals only with the canonical decision and the page architecture that makes the decision easy.

The wrong answers are common in both directions. Point every branch page at one central page and none of them can rank for "near me" searches in its own city. Leave every branch page self-canonical with the same paragraphs and you hand Google the job of choosing which near-identical copy to keep, usually not the one you would pick. The right answer depends on what is genuinely different about each branch.

What a canonical tag can and cannot do

Google's documentation on consolidating duplicate URLs lists redirects and rel="canonical" as strong signals for choosing the canonical, and sitemap inclusion as a weak one. It also says Google still decides which pages are actually duplicates, based on content similarity. If you specify nothing, Google picks the version it considers best.

Three consequences follow.

1. A canonical is a statement that two pages are duplicates. If the pages are materially different, Google may ignore your canonical.
2. Signals stack. A canonical, an internal link pattern and a sitemap listing that all agree make the outcome more predictable. If they disagree, expect surprises.
3. Some tools are wrong for the job. Google warns against using robots.txt to select a canonical and against using noindex to choose a canonical within one site.

Google's spam policies on doorway pages are also relevant. Pages created in bulk that differ only by place name, and that funnel users to the same destination, are the pattern the policy describes. A location template filled in by swapping a city name risks that classification.

The three options

Self-canonical. The page names itself as canonical. It is saying: this is the page that should be indexed and ranked for its own query. Use it where the page has its own substance.

Cross-location (or cross-page) canonical. The page names another URL, such as a central treatment page, as the preferred version. It is saying: this page is a duplicate of that one. Use it only where the content really is the same and you do not need this URL to rank.

Neither. The page should not exist as a separate URL. Merge it: redirect it permanently to the page that serves the visitor, and remove it from navigation and the sitemap. This is often the most honest answer for a branch-treatment page with no local content.

A test for "is this page really different?"

Before choosing a tag, read the page body without the header, footer and navigation. Then ask three questions.

• The swap test. If you replace the city and branch name with another branch's, does the page still read correctly and truthfully? If so, the content is local in name only.
• The fact test. Does the page contain a fact only this branch can state: its doctors and their consultation days, the equipment installed there, the parking and access instructions, local pricing or package terms, the accepted insurers, the languages the team speaks, or a local FAQ drawn from real enquiries at that branch? Each should be confirmed by the branch.
• The intent test. Do people search for this treatment in this city, so that a result for this branch would answer something the central page cannot?

Two or three "yes" answers justify a self-canonical page. Zero or one points to a cross-canonical or a merge.

A working architecture for twelve branches

The cleanest structure splits the page types so each has a different job.

In this layout the central treatment page carries the general explanation, which the clinical team reviews once. Each branch page lists the treatments available there and links to the central page for detail. A branch + treatment page is built only when the branch has something local to say about that treatment.

That avoids twelve copies of the same medical text, and one place to update when clinical guidance changes. It also keeps branch pages strong because they are not diluted by dozens of almost-identical children.

Worked example with hypothetical figures

Suppose a chain has 12 branches and offers 20 treatments across them, but not every branch offers every treatment. A template-based approach could generate 240 branch + treatment URLs. Now audit them using the three tests.

• Suppose 70 of those combinations have a named doctor, a local contact route, and a real local search query. These become self-canonical pages with unique local sections.
• Suppose 110 combinations exist because the template produced them, with no resident specialist and no local demand. These are merged by 301 into the central treatment page, and the branch page links to the central one.
• Suppose 60 combinations are services the branch refers out. They should not appear on the branch's website as offered services at all.

These figures are invented to show the process. The point is that a canonical decision at this scale is an inventory exercise, and the output is a list of URLs with an action against each: keep, merge or remove.

How to check what Google actually chose

Use the URL Inspection tool in Search Console on a sample of branch pages. It shows the user-declared canonical and the Google-selected canonical. When they differ, Google is telling you that it considers the page a duplicate of another URL, or that your signals conflict.

In the Page indexing report, look at the groups "Duplicate, Google chose different canonical than user" and "Alternate page with proper canonical tag". The first means your declarations are not being followed. The second is expected for correctly canonicalised variants, but it should only contain URLs you intended to be non-canonical.

Then check each branch name in a search: the query "[treatment] in [city]" with the site name, and the plain "[treatment] [city]". If the central page appears instead of the branch page for a local query, either the branch page is too thin, it is canonicalised away, or internal links point to the central page and not the branch.

Common mistakes

Canonical to the homepage. A branch page that canonicalises to the homepage tells Google it is a duplicate of the home page. It can drop out of the index.

Canonical chains. A points to B and B points to C. Each hop weakens the signal. Point every duplicate directly at the final URL.

Canonical and noindex together. Mixed signals. Choose one purpose per page.

Canonical that disagrees with the sitemap. List only canonical URLs in the sitemap.

Canonical that disagrees with hreflang. Google prefers URLs that belong to reciprocal hreflang clusters; keep canonical and language annotations consistent.

Canonicalising away the Google Business Profile landing page. If the profile links to a branch URL that declares another page as canonical, the profile's destination is not the page you meant to rank for local searches. Keep the profile landing page self-canonical.

Using relative URLs, mixed protocols or trailing-slash variants. Use absolute URLs in the canonical tag, with one consistent protocol and format.

Template defaults. The tag is often generated by a template that uses the request URL. Computing it from the stored path avoids parameter variants becoming canonical.

Clinical content and compliance

Treatment text shared across branches should be reviewed by the provider's clinicians once and reused deliberately, with a named reviewer and review date. If a branch writes its own version of clinical text to look different, it creates extra review work and risk of inconsistent medical statements. Differentiate with local facts, not rewritten medicine.

Where to start

1. Export all location and branch + treatment URLs, with their declared canonical, from a crawl.
2. Add columns for the swap test, the fact test and the intent test.
3. Decide keep, merge or remove for each URL.
4. Make the central treatment pages the home of shared clinical content.
5. Implement redirects for merged pages and update internal links, sitemap entries and Google Business Profile links.
6. Re-inspect a sample in Search Console after Google recrawls, and compare declared and selected canonicals.

For a review of this structure on a live chain, our multi-location SEO service and the multi-location clinics page describe how we approach it, and the geo pages page covers building location content with real local substance.