Same-Language Regional Pages: Duplicate Content Rules

When two country pages share a language, keep them separate only if each one shows the visitor something the other cannot: a local price, local delivery terms, local units, a local return address. If the only difference is a currency symbol, one page is the cleaner answer. If you keep both, give each page its own canonical and connect the pair with reciprocal region annotations, because Google treats the two jobs differently and a conflict between them leaves the choice of URL to Google.

This is written for exporters, store teams and agencies running one English (or Spanish, or German) site for several countries. Tax and compliance wording is outside this topic; the focus is what the page shows and how search engines read the relationship between near-identical URLs.

Checking the syntax of the tags themselves is a separate task, covered in the hreflang audit checklist. The question here comes earlier: should the second page exist at all, and if it does, how do you keep the two from collapsing into one?

What Google's documentation says about regional pages in one language

The small-variation case the documentation names

Google's guide to localized versions describes this exact situation. It recommends alternate-page annotations when you have content with small regional variations in a single language, and its example is English aimed at the US, Great Britain and Ireland. It also asks you to provide a generic catchall page for users of that language whose region you do not know, and says that catchall can be one of the regional pages (Google: Localized versions of your pages (Opens in a new tab)). The wording accepts that regional pages may be close to each other. Closeness is not forbidden; unlabelled closeness is the risk.

The same page defines when localized versions count as duplicates: when the main content of the page remains untranslated. For two English pages, the main content is already in the same language, so that sentence does not tell you the pair is safe. What it does tell you is that the documented remedy for same-language variants is the annotation, and that the template-versus-main-content distinction matters for translated sites more than for regional ones.

How Google guesses the audience of a page

Google's guidance on multi-regional sites lists the signals that help it work out which country a page serves: the use of local language and currency, local addresses and phone numbers, links from local sites and Business Profile data. Server location is weaker because of content delivery networks, and locational meta tags and geotargeting HTML attributes are ignored (Google: Managing multi-regional and multilingual sites (Opens in a new tab)). Two lessons follow. A page that shows no local signal gives Google little to work with, and an annotation cannot add signals that the page itself lacks.

The same documentation also warns about a trade-off. Geotargeting can improve rankings in the target country, but at the expense of results in other locales or languages. If you want the US page to stay visible to Canadian searchers who have no Canadian page, you need to decide on purpose whether that is acceptable. Users who land on the wrong version should be able to pick their region or language through links available on every page.

How Google picks between look-alike pages

Canonicalization is optional, according to the canonical documentation. If you do not state a preference, Google identifies the version it considers objectively best to show users, and it decides which pages are duplicates by comparing content similarity (Google: How to specify a canonical URL (Opens in a new tab)). For a regional pair, this means a pair of very similar pages can be clustered whether or not you intended it. The annotation tells Google the pages are regional counterparts; the similarity of the text still feeds the clustering.

Signals and their documented strength

The documentation adds that these methods can stack and become more effective together, and it recommends linking internally to the canonical URL rather than to duplicates. Two practices it advises against are mixing canonical signals that point to different URLs and using robots.txt to manage canonicalization.

When the canonical Google chose differs from yours

The URL Inspection tool in Search Console shows which canonical Google selected for a page. A difference between your declared canonical and Google's choice is not necessarily a fault, because Google bases the decision on similarity and several signals together. The documentation does not state a threshold at which a difference must be fixed. Practical suggestion: treat the difference as evidence. If the US page keeps being chosen for British queries, compare the two pages and ask what a British visitor would see on the British page that justifies it.

Annotations and canonicals do different jobs

Region annotations (hreflang) declare that pages are counterparts for different audiences. A canonical states which URL you prefer among duplicates or near-duplicates. A regional page participates in both relationships, but the two must agree. The localized-versions guide says each version should list itself and all the others, and that if two pages do not point to each other the tags are ignored. URLs must be fully qualified, including the protocol.

Reciprocity, codes and the catchall

Language uses ISO 639-1 and region uses ISO 3166-1 Alpha 2; a region on its own is invalid. Codes such as UK are reserved or invalid in the sense that Google ignores that part of the annotation. The guide also notes that Google does not detect language from the annotation or from the lang attribute, and that a subdomain called en-gb does not tell Google who the audience is; you declare the audience explicitly. Google's wording also allows leaving a language out of some pages, but new pages should link bidirectionally with the dominant versions.

Practical suggestion: build the set once, generate it from a single list of country URLs, and write the same list into every page or into the sitemap. Hand-edited sets drift, and a drifted set is a set with missing return links.

Contradictions to remove before launch

When you are deciding how the country part of the address should look, the localized URL and slug guide covers naming and path choices for the pair of languages used on this site.

Price, units and spelling: what is worth localizing

Fields that justify separation

The practical test is whether a field changes a buying decision. The list below is a working checklist, not a documented threshold.

• Availability: is the product shipped to this country, and from where?
• Price and currency: shown in the local currency and the format shoppers expect there.
• Tax display: whether prices include or exclude tax, as the local market expects.
• Units and sizing: metric or imperial, local size charts, plug types or voltage.
• Support and returns: a local phone number, opening hours and a return address.
• Spelling and vocabulary: colour and color, trousers and pants, trainers and sneakers.
• Notices and policy wording that differs by country; the legal substance sits with your advisers, while the search question is only that the page shows the right text.

Not every field has to differ. The core product description, specifications and the shared images can stay identical across pages. The risk is a pair where nothing except one price line differs.

Example scenario: an outdoor gear shop selling in three countries

Example scenario: a shop sells tents, stoves and rain jackets to customers in the United States, the United Kingdom and Australia, all in English. The product descriptions are identical. Prices, delivery times and return addresses differ, and the jackets use different size labelling in each market.

The team first lists what actually changes per country: price and currency, delivery estimate, return address, size chart, and a few words such as boot versus wellington or rain jacket versus waterproof. It then asks whether those differences can live on one product page behind a country selector or whether each market deserves its own URL. Two of the markets have local sizing and local terms that shoppers search for, so the team decides to open separate pages for them and to keep a catchall English page for everyone else.

For the separate pages, each one declares its own canonical, the set of regional annotations is generated from one list, and the catchall page is part of the set. Each page carries a visible link to switch country. The team writes a local opening paragraph and a local FAQ for each page, because those are the places where a British or Australian shopper's questions differ. The shared specification block comes from one source, so a fix to a tent's weight figure lands on every page at once.

The shop does not open a fourth page for a market where it only changes the currency symbol. That market is served by the catchall page with a price shown through the visitor's chosen country. This keeps the cluster small enough to maintain, and it matches the documented preference for annotation where there are real regional variants.

Writing the local layer so it is more than a label

A local layer is the part of a regional page that a visitor from that country finds useful and cannot find on the sibling page. Google's guidance on helpful content asks whether a page offers substantial value compared with other pages, and whether you are mainly repeating what is already there. That page is about content quality in general, not about regional pages, so use it as a mindset rather than as a rule for this case.

Practical suggestion: for each regional page, write four short items by hand. First, a delivery and returns paragraph that names the real carrier options and handling times for that country. Second, a size or unit note that matches local habits. Third, two or three questions that actual customers from that market have asked support. Fourth, a plain statement of who the page is for, such as "shipping to Australia". None of these needs to be long, and none can be copied from the sibling page, which is exactly why they work as evidence that the second URL has a purpose.

Getting visitors to the right version without trapping them

Once the pages exist, the next problem is routing. The multi-regional documentation advises against automatically redirecting users based on an assumed language, because it can prevent users and search engines from seeing every version. Its alternative is a visible link to other language versions. For regional English pages, that means a country switch in the header or footer that stays on the equivalent page rather than dumping the visitor on a home page.

Google also explains that it does not vary its crawler location to find regional variants. Every regional version has to be declared through annotations, country-specific domains or explicit links. A page that is reachable only after a cookie-based country choice is, from a crawler's point of view, a page that may not be reachable at all.

A country picker page, if you have one, can carry the x-default value. According to the localized-versions guide, x-default is the reserved value used when no other language or region matches the user's browser setting, and the page lists a country selector or an auto-redirecting home page as examples. It needs no language code.

A merge-or-split rule for same-language pages

Decision rule

1. List the fields that differ between the two pages. If none affects a buying decision, merge.
2. If some do, ask whether one page can show them reliably once the visitor chooses a country. If yes and nothing else argues for two URLs, keep one page.
3. Check whether local vocabulary or local intent gives each page its own search purpose. If it does, a separate page has a reason to exist.
4. Check capacity: can you maintain each local layer (price, delivery, support, local questions)? If not, publish fewer, richer pages.
5. If you split: self-referencing canonicals, reciprocal annotations with a catchall, matching sitemap entries and a visible country switch.
6. If you merge: permanent redirects from the retired country URLs, updated internal links and a refreshed sitemap.

The documentation gives no number for how different two pages must be. Everything above is practical suggestion built on the documented behaviour: Google clusters similar pages, picks a canonical itself when you do not, prefers reciprocal clusters, and treats redirects and rel=canonical as strong signals.

Walking through a merge

Suppose the shop above decides that its Canadian page adds nothing beyond a different price line. The merge has four steps. Choose the surviving page, which should be the one with the stronger local layer or the one already chosen by Google. Redirect the retired URL to it permanently, since the canonical documentation calls redirects a strong signal and says to use them when you deprecate a duplicate. Update internal links, menus and the sitemap so they point at the surviving URL, because the same documentation advises linking to the canonical rather than to duplicates. Finally, remove the retired page from every annotation set so that no remaining page references an address that now redirects.

Do not leave the retired page live with a canonical pointing at the survivor and also keep it in the annotation set. That combines two contradictory messages: the page says it is a duplicate and the set says it is a regional counterpart. Pick one relationship per pair of URLs.

The Canadian visitor still needs a good experience after the merge. Practical suggestion: show the delivery and price information relevant to their selected country on the surviving page, and keep a visible way to switch country. The merge is a decision about URLs, not about ignoring those shoppers.

Pre-publish checklist

• Does each country page show price, currency and delivery for that country?
• Is there a visible link on every page to change country or language?
• Does each page declare its own canonical?
• Is the annotation set reciprocal, fully qualified and equipped with a catchall?
• Do sitemap URLs match page canonicals exactly?
• Are visitors left free to choose, instead of being redirected by browser language? Google's multi-regional guidance warns that automatic redirects can stop users and search engines from seeing all versions; see the notes on automatic language redirects.
• Is shared product text maintained in one place?
• Is each local layer (delivery, support, local questions) actually filled in?

If the country pages attract links from different markets, plan where those links should point after you decide. The international link strategy guide covers that side; the page decision should come first.

After the decision

Watch Search Console for the canonical Google selects for each country page and for the queries that show each URL. A page appearing in the wrong country can indicate an incomplete set or pages that are too similar. When you add a market later, add it to every existing page; the localized-versions guide says a new language page should link bidirectionally with the dominant versions. When you drop a market, redirect its URLs permanently and remove it from the set so no page keeps pointing at a retired address.

Frequently Asked Questions

Do two English pages for different countries count as duplicate content?

Google's localized-versions page defines localized versions as duplicates when the main content stays untranslated, and it recommends region annotations for same-language pages with small regional variations. Google still decides which similar pages to cluster by comparing content, so the annotation does not replace real regional differences.

Should each country page use its own canonical?

If you keep the pages separate, yes. This is a practical suggestion drawn from the canonical documentation, which warns against mixed canonical signals, and from the annotation guidance. A canonical pointing at another country page works against the regional relationship you declared.

Is a currency change enough to justify a separate page?

The documentation gives no threshold. Practical suggestion: if price is the only difference, one page that shows the right price for the chosen country is simpler than two near-identical URLs.

Do I need a catchall page such as plain English?

Google recommends a generic catchall for users of that language whose region does not match any of your regional pages. The catchall can be one of the regional pages.

Can I write GB or UK as the region code?

The documentation says the language code uses ISO 639-1 and the region uses ISO 3166-1 Alpha 2, and that a region alone is invalid. It lists UK among reserved codes that Google ignores, so the Great Britain code is the one to use alongside the language.

Is redirecting visitors by their browser language a good idea?

Google's multi-regional guidance says automatic redirects could prevent users and search engines from viewing all versions and recommends visible links to other versions instead.

Conclusion

Same-language country pages earn their separate URLs through differences the visitor can see and use: local price, delivery, units, support and vocabulary. Where those differences are thin, merge and redirect permanently. Where they are real, give each page its own canonical, a complete reciprocal annotation set with a catchall, matching sitemap entries and a visible way to switch country. Google's documentation offers no ranking guarantee and its details can change, so check the current pages before you roll anything out.

If you need locally written product and category copy for each market, the content writing service page on Akua Adforce explains scope and terms.