Understand SEO header and hreflang checks

TechDash tracks index directives delivered in HTTP response headers and hreflang alternates found on monitored pages. The checks separate simple change intelligence from structural problems that can make an alternate unusable. A pass can mean unchanged, baseline stored, reciprocal within the monitored set, or currently reachable. It does not prove that Google selected the intended language version or that every public locale is annotated.

SEO headers changed

SEO headers changed is Advisory. It fingerprints:

• X-Robots-Tag
• Link header values with canonical or hreflang relationships

Cache-Control, Content-Type, CSP, API links, shortlinks, JSON alternates, and unrelated Link relationships are excluded. Why it matters: those headers can change indexability or which URL Google treats as the canonical or language alternate without any HTML template edit.

A fail means a previously non-empty SEO-header fingerprint differs from the current fingerprint. A pass means the SEO-header fingerprint is unchanged, or the first non-empty observation is still being stored as the useful baseline. A move from no SEO headers to a first value is not treated as a change. Later additions, removals, or edits can open an incident.

Evidence shows previous and current SEO-header values after formatting. Header evidence is distinct from tags in rendered HTML. For example, an X-Robots-Tag can add noindex even when the page has no robots meta tag.

Likely repercussions include unexpected noindex through a CDN or reverse proxy, loss of a header canonical, injection of contradictory hreflang headers, and hard-to-spot release drift when the application template did not change. Intentional CDN rule updates and planned international header rollouts are common benign cases.

Review CDN, reverse-proxy, and origin rules when the application template did not change. Compare the header values with robots meta and HTML canonical or hreflang annotations. After correcting the rule, use Check & Verify. Recovery means the Advisory clears or the accepted new header fingerprint remains stable on the next run.

Hreflang set changed

Hreflang set changed is Advisory. TechDash normalizes and sorts the page's extracted language-to-URL pairs, then compares them with the prior successful baseline. Why it matters: wrong language or region targeting can send searchers to the wrong market version even when the page itself is healthy.

A fail means the sorted serialized set differs from the previous non-empty baseline. A pass means the set is unchanged or the first observation is storing the baseline. Evidence shows previous and current serialized pairs.

Likely repercussions include lost locale alternates after a template edit, incorrect x-default fallbacks, and market URLs that no longer appear together in search. Locale launches, migrations, and corrected regional targeting are expected benign reasons.

Confirm that each language or language-region code points at the preferred URL and that x-default, when used, still reflects the intended fallback. After publishing, use Check & Verify. Recovery means the Advisory clears or the intentional new set is accepted and remains stable. A pass after acceptance means the monitored set is unchanged, not that every public locale is complete.

Duplicate hreflang language code

Duplicate hreflang language code is Warning because Google can only use one URL per language or region code. Why it matters: duplicate codes can cause search engines to ignore extras or choose the wrong locale.

A fail means one page maps the same normalized code to more than one distinct URL. Repeating the same code and same normalized destination does not create a duplicate group. A pass means every code on the page maps to at most one distinct URL, including pages with no hreflang annotations. Evidence lists every conflicting URL for each code.

Likely repercussions include unstable locale selection, ignored annotations, and market pages competing with each other. Benign cases are uncommon; repeated identical destinations are usually template noise rather than useful signals, while distinct destinations for one code need an intentional policy review.

Keep one destination per language or region code. Remove duplicate emitters from templates, plugins, and header rules. Use Check & Verify after publishing. Recovery means the Warning no longer lists duplicate codes on the page.

Missing reciprocal hreflang

Missing reciprocal hreflang is Warning and runs after all enabled monitored pages for the website have current results. Why it matters: incomplete return links weaken international targeting among the pages TechDash can currently compare.

A fail means one monitored page points to another monitored page, and the destination does not include a return alternate to the source. A pass means every monitored alternate that points to another monitored page also receives a return annotation, or no such monitored pairs exist. Pairs outside the monitored set are not tested for reciprocity. Evidence lists the source URL, hreflang code, and alternate that does not link back.

Likely repercussions include one-way language clusters, unreliable market selection, and silent breakage when only one locale template was updated. Benign cases include intentional one-way fallbacks, but those should be deliberate and documented. The check looks for a return URL, not whether the two pages use semantically matching language codes.

Add all relevant locale alternates to Monitored Pages when you want this relationship checked. Add matching return annotations across each monitored alternate. After the next complete monitored-page cycle, confirm the Warning clears. Recovery means reciprocity passes for the monitored cluster, not that Google validated the complete public set.

Hreflang target not indexable

Hreflang target not indexable is Warning. After all enabled monitored pages for the website have current results, TechDash uses current monitored snapshots where available and probes other unique targets. Why it matters: pointing alternates at erroring or noindex URLs wastes international signals and can prevent the right market page from being chosen.

A fail means a unique hreflang target returns a concrete error response (for example 404 or 500), a redirect, or a noindex state known from a monitored target. Rate limits (429), auth or WAF blocks, timeouts, and soft overload (503) are treated as inconclusive crawl results and do not count as an unusable target. A pass means every unique declared target responds successfully and is not known to be noindex, no hreflang targets are declared, or remaining probes were inconclusive. Evidence lists the source path, target, and reason such as an HTTP status or noindex.

For a target outside the monitored portfolio, the lightweight probe supplies HTTP status but does not render the target or detect its HTML noindex. A successful external probe therefore proves reachability only. Add important alternates to Monitored Pages if you need richer current evidence, including noindex detection.

Likely repercussions include ignored annotations, soft 404 or redirect destinations in the locale set, and market pages that never become eligible. Staging, login, or retired URLs left in the cluster are common accidental failures. Intentional noindex on a true duplicate can be benign only when that URL should never be the chosen alternate.

Point hreflang only at live, indexable URLs. Remove redirects and noindex directives from intended targets, or update the annotation to the final preferred URL. After correction, wait for finalization or use Check & Verify on the affected pages. Recovery means target health passes for the current monitored set and probes.

What to do and how to verify

Multi-value incidents use separate evidence cards so the source page, language code, destination, status, and missing return path remain readable. Start with the listed source and target, then inspect both pages' rendered head and HTTP headers.

For an unexpected change or structural failure:

1. Confirm that the locale URLs are absolute, live, and canonical.
2. Keep one destination per language or region code.
3. Add matching return annotations across each monitored alternate.
4. Remove redirects and noindex directives from intended targets.
5. Check whether an HTTP Link header duplicates or contradicts HTML markup.
6. Review CDN or origin header rules when HTML did not change.

After publishing a fix, use Check & Verify. If a migration intentionally changed the complete set, verify all destinations, reciprocity, and target health before marking the Advisory or Warning resolved. A connected Search Console property can provide separate Google-selected canonical evidence, but Google does not report a complete hreflang validation through these TechDash checks.

If the same cluster keeps failing after template and CDN corrections, collect the source URL, evidence cards, header samples, and the list of monitored locale pages, then open Help & Support.

Related articles

• Understand indexability and canonical checks
• Review incidents that affect multiple URLs
• Recheck with Check & Verify