Hreflang and international search set-up

What hreflang set-up is, and what it is not

Hreflang annotations exist so that search results can offer each reader the version in their language or region ¹. Setting them up correctly means search results are more likely to offer a reader in Lausanne the French page rather than the German one. It does not make any page rank higher, it does not translate anything, and it cannot fix a page whose content mixes languages, because Google detects language from visible content, not from code ².

Our work is to make the signals complete and consistent. What search engines then do with them is up to them.

What we check

Return links on every template

Google requires each language version to list itself and every other version; one-sided pairs are ignored ¹. We sample pages from every template type, not only the home page, and compare their annotation sets.

Codes

Language codes in ISO 639-1 format and optional region codes in ISO 3166-1 alpha-2 format ¹. We look for regions without a language, UK instead of GB, and regional codes used where a language-only code would do, following the W3C advice to keep tags as short as the context allows ³.

Canonical tags

Each version should declare itself as canonical. A French page that declares the German page as its canonical is telling search engines it is a duplicate, which conflicts with its hreflang annotations.

Targets that answer

Every annotated address should load directly, without a redirect and without an error. We check status codes for a sample of annotated addresses across languages.

Sitemaps

Whether XML sitemaps list every language version, and whether any annotations in them agree with those in the page heads.

Language tags and content

Whether each page's lang attribute matches its content, which matters for accessibility under WCAG 2.2 criterion 3.1.1 ⁴ even though search engines read the visible text instead. We also note pages whose body mixes languages, where only rewriting helps.

Automatic redirects

Whether visitors or crawlers are redirected by location or browser language, which Google advises against because it can prevent users and search engines from viewing all versions ².

What you receive

1. A written report with each issue, where it occurs, why it matters and how to fix it, ordered by impact on the language signals.
2. Implementation of the fixes on your site, or exact instructions for your developer.
3. A complete hreflang set per template type, generated from the site's record of which pages belong together rather than typed by hand.
4. Updated XML sitemaps.
5. If you want the sampled pages checked again after the fixes, that re-check can be quoted separately.

Where the data comes from

Hreflang only stays correct if it is generated from one record of which pages are translations of each other. On WordPress, that record lives in the multilingual plugin; on other systems it may be a field per page or a separate mapping. If no such record exists, creating one is part of the work, and it is the same record the language switcher needs. That is why this service and language navigation design pair naturally.

What we need from you

• Access to view the site's source and, for implementation, editor or developer access.
• A list of the languages and regions the site serves.
• Access to Google Search Console, if you use it, so we can see how pages are reported. This is optional.

Do it yourself first

If you prefer to try first, our hreflang planner builds a complete annotation set from your versions and catches several of the errors listed above. The hreflang guide explains the rules behind it.

Price

From CHF 2,600 for a check and fixes on an existing site in up to four languages with a standard content system, plus VAT where applicable. Large sites, several domains or custom platforms are quoted after a first look. The pricing page has the other starting points.