Referrer Meta Absent
0 Intentional IssuesEvery head tag a page normally carries, except the one this check was written to look for.
Expected result: meta_name_referrer NOT DETECTED
The condition is present — this document declares no <meta name="referrer"> — and the code is still silent, because #22 is isActive: false in the API issue catalogue and htmlHeadTags.js extracts the value without grading it. A finding here would mean the catalogue changed, not that this page did.
referrer_policy_header (#70) must also come back NOT DETECTED. It is live, and it reads three delivery routes; this page uses the http-equiv one, which is exactly the configuration the retirement note describes as having been counted twice.
What this document declares
<meta name="referrer">— absent. The condition under test.<meta http-equiv="Referrer-Policy" content="strict-origin-when-cross-origin">— present, so the referrer policy is genuinely configured and #70 has nothing to report.<meta name="author">— present, so #20's condition lives on /head-tag-gaps and not here.<link rel="sitemap">— present, so #25's condition does the same.
Why a referrer policy still belongs on the page
Nothing about the retirement says the policy itself is optional. It says the policy is a privacy control rather than a search signal, and that HTTP Security Headers is where it is graded. A page shipping strict-origin-when-cross-origin sends the full URL to same-origin destinations, the origin alone to cross-origin HTTPS destinations, and nothing when the destination downgrades to HTTP. That is the token the Referrer Policy specification recommends, and it is what this page ships — through the header-equivalent tag rather than the name-based one.
Counterpart: /fp-meta-referrer declares the tag correctly. Catalogue of every retired code and its condition: /head-tag-gaps.