SEO & Speed Audit
Real Core Web Vitals from Google's API, plus live on-page checks against your actual HTML.
English is live now. The rest are being translated and published one at a time.
No language matches your search.
International SEO
hreflang fails silently. One missing return tag and Google discards the whole set, and nothing in your analytics tells you. This tool fetches your page, reads its hreflang set, then fetches each alternate to verify it points back.
Fetching the page and verifying each alternate…
hreflang set for
We read the hreflang annotations from the page's HTML head, validate each language and region code against ISO 639-1 and ISO 3166-1, then fetch up to eight of the alternate URLs and check that each one declares a return annotation pointing back. Reciprocity cannot be verified any other way — a tool that does not fetch the alternates is only checking syntax.
The guide behind this tool International SEO: The hreflang Architecture That Actually Works How to structure a multilingual site so each market ranks in its own language: URL architecture, hreflang rules, and the mistakes that break it. Read the guide · 6 min read →Syntax is the easy half. This tool also fetches your alternate URLs to verify they point back — which is the half that actually breaks.
We fetch up to eight of your alternates and check each one references this page back. Without reciprocity Google discards the entire set.
ISO 639-1 language plus optional ISO 3166-1 region. A region alone is invalid — "at" is not Austria.
Relative paths are unsupported and fail silently.
A set that omits its own page is invalid and gets discarded.
What visitors whose language you do not target are shown.
A canonical pointing at another language silently removes this page from search, whatever hreflang says.
How many language versions are declared, and which.
A canonical conflict is the emergency. If this page's canonical points at a different language, that single line is removing the page from search entirely — hreflang says one thing, canonical says another, and canonical wins. Fix it before anything else on this list.
Broken reciprocity is the common one. It usually means your generation logic is asymmetric, or a page exists in some languages and not others. The durable fix is to generate the whole hreflang set from one source of truth rather than assembling it per page.
If a language is missing entirely, check that it is actually translated. Announcing an English page as your German alternate is worse than announcing nothing: it puts thin duplicate content into a market you are trying to build. Noindex the untranslated version until it is real.
If your English page points to your German page, the German page must point back. If it does not, Google ignores the annotation set entirely — not the one broken link, the whole set. This is the single most common failure and it is invisible without fetching both pages.
Each page's hreflang set has to include an entry for its own URL. A set that lists the alternates but omits the page itself is invalid.
Relative paths are not supported and fail silently. href="/de/" does nothing; href="https://example.com/de/" works.
Language codes are ISO 639-1: de, tr, fr. Region codes are ISO 3166-1 Alpha-2 and only ever appear after a language: de-AT, en-GB, pt-BR.
You cannot target a region alone. hreflang="at" does not mean Austria — at is not a language, so the annotation is invalid and discarded. This mistake is extremely common.
Separate from the four rules, and more destructive than any of them: each language version must be its own canonical.
If /de/ carries <link rel="canonical" href="/en/">, you have told Google the German page is a duplicate that should not be indexed — while your hreflang says the opposite. Canonical wins. The German site quietly disappears.
The instinct is understandable, because translations feel like duplicates. They are not. They are distinct pages serving distinct queries in distinct markets.
It marks the page shown to users whose language you do not target. Point it at your primary-language version or at a language selector. It is optional but worth having — without it, an unmatched visitor gets whichever version Google guesses.
Only if you have separate pages for separate English-speaking markets — a US page and a UK page with different pricing, for example. Then `en-US` and `en-GB` stop them competing with each other. A single English site targeting everyone does not need hreflang at all.
Any of the three work. HTML head tags are easiest to inspect and debug. Sitemap annotations keep your HTML lighter and are better above a few hundred URLs. HTTP headers are for non-HTML files like PDFs. Pick one method and use it consistently — implementing two is how they end up disagreeing.
That is the reciprocity failure. Page A points to page B, but B does not point back at A. Usually the generation logic is asymmetric, or B is a page that only exists in some languages. Fix it by generating the whole set from one source of truth rather than per-page.
No. Leave a page out of the hreflang set until it is genuinely translated, and noindex the untranslated version in the meantime. Announcing an English page as the German alternate is worse than announcing nothing — it puts thin duplicate content into a market you are trying to build.
Real Core Web Vitals from Google's API, plus live on-page checks against your actual HTML.
See your page exactly as Google and every social platform will render it, from your live HTML.
Extract every JSON-LD block on a page, validate it, and see which rich-result types you qualify for.
One team. Three offices. Twenty-six languages. Send us the problem and you get a senior answer — not a sales script.
A written proposal within one business day, in your language.
Talk to a human
İstanbul, Düsseldorf and Dover — one of us is usually awake
Pick the channel that suits you. A person answers — no ticket queue, no bot.