An unclosed parenthesis renders as "(stack order." in the DIY skip-box

The bullet opens a parenthesis before the stack-order link and never closes it, so the visitor sees "(stack order." mid-list.

(<a href="/guides/security-stack-order.html">stack order</a>.</li>

One stray paren in a cornerstone guide is exactly the kind of small sloppiness a skeptical first-time reader uses to gauge how carefully the numbers elsewhere were checked.

fix — On data-removal-diy-vs-paid.html line 88, change 'stack order</a>.</li>' to 'stack order</a>).</li>' to close the parenthesis opened before the link.

The disclosure carries Amazon Associates boilerplate for a program the site has zero links to.

A dedicated section discloses Amazon affiliate participation while stating there are no such links, which reads as pre-emptive template text rather than a description of the actual site.

Where Amazon Associates links appear (none at present), we also use this disclosure:

It signals the disclosure was partly assembled from boilerplate, slightly diluting the impression that every line describes something real.

fix — Delete the 'Amazon' section (lines 77-81) from apex/disclosure.html until Amazon Associates links actually exist on the site.

The Jump column's "+232%/mo" reads as a monthly compounding increase, not a one-time step-up

jumpPct computes the one-time percentage difference between the intro-term effective monthly rate and the renewal monthly rate (e.g., NordVPN 2yr: $3.49 → $11.59 = +232%), but the "/mo" suffix makes it look like the price rises 232% every month. The unit is never explained on the page.

: `<span class="up">+${jump}%/mo</span>`;

<th scope="col">Jump</th>

The calculator's headline metric is momentarily unbelievable — "+232%/mo" looks like a bug or scare tactic — which is a bad flinch to trigger in a tool whose pitch is sober, honest math.

fix — In apex/vpn/true-cost/cost.js line 237, change the template from `+${jump}%/mo` to `+${jump}%` (or `+${jump}% at renewal`) so the one-time jump does not read as a monthly rate.

The README ships a live TODO admitting the analytics site does not exist yet.

'when the Umami site exists' is an unfinished-setup note left in the public-facing repo documentation for a tool described as a completed v1 rebuild.

No PII, no answer text. Wire the website id in `index.html` when the Umami site exists.

Anyone evaluating the project from its repo reads this as 'still half-wired', which slightly undercuts the polished, verified-catalog framing two sections above.

fix — Delete or update the sentence "Wire the website id in `index.html` when the Umami site exists." at README line 48, since index.html line 40 already ships the wired data-website-id.

Choosing the built-in-password-manager option bounces through an external-style redirect to the site's own guide.

An internal guide page is served through the same /go/ interstitial used for external vendors, complete with a 'not a partner link' disclaimer that makes no sense for the site's own content.

Redirecting to <a href="https://hexento.com/guides/password-manager-vs-built-in.html" rel="noopener">https://hexento.com/guides/password-manager-vs-built-in.html</a> (not a partner link)…

A visitor sees a 'Redirecting…' flash and a disclaimer about partner status just to read another page on the same site — a small 'huh?' moment that makes the plumbing feel bolted together.

fix — Link the builtin option's recommendation directly to /guides/password-manager-vs-built-in.html (special-case internal targets in build_go.py/app.js) instead of generating a /go/builtin/ interstitial with a "(not a partner link)" label.

The disclosure page labels itself 'Trust surface,' exposing builder jargon that frames trust as a design artifact.

The rendered eyebrow above the Disclosure heading reads 'Trust surface' — internal growth/design vocabulary shipped to visitors, implying trust is a UI element being engineered rather than earned.

<p class="eyebrow">Trust surface</p>

A skeptical reader who catches the phrase gets a peek behind the curtain: the page is self-consciously performing trustworthiness, which is exactly the vibe a disclosure page must avoid.

fix — Change the eyebrow text at line 37 from 'Trust surface' to reader-facing wording such as 'Transparency'.

Antivirus prices are given to the cent with no date or source, unlike the dated VPN prices

The VPN pages carefully stamp every dollar figure with a snapshot date and describe how each number was corroborated. The antivirus guide drops equally precise renewal figures with no date, source, or hedge — just "Last updated 2026-08-01" at the top of the page.

Norton 360 Deluxe: $49.99 first year, renews $119.99. Malwarebytes Ultimate: $139.99, renews $279.99. If a tier doesn’t publish its renewal rate (some don’t), treat that as your answer.

prices from snapshot <time datetime="2026-08-01">2026-08-01</time>

A visitor who reads both pages notices the double standard: one category gets receipts discipline, the other gets bare assertions. It quietly undercuts the methodology brand the site leans on everywhere else.

fix — Add a dated source note to the antivirus renewal-price bullet on do-you-need-antivirus.html line 111, e.g. '(vendor pricing pages, checked 2026-08-01)', matching the dating discipline of the VPN guides.

A heading name-drops EFF but the section never cites or links EFF

The heading invokes 'EFF-style ordering' for authority; the body immediately retreats to the anonymous 'independent consumer-security education' and never links EFF material. The reader can’t tell whether EFF actually endorses this ordering.

<h2>What EFF-style ordering is really saying</h2>

Independent consumer-security education has repeated the same hierarchy for years:

Borrowing a trusted org’s name in a heading without a citation looks like authority-laundering to a skeptical reader — the exact move the page criticizes in vendors.

fix — Either link an actual EFF resource (e.g. Surveillance Self-Defense) in the section body on security-stack-order.html lines 144-150, or remove 'EFF-style' from the heading.

Homepage badge says 'partners pending' (plural) for a hub that discloses exactly one pending application

The data-removal hub's disclosure says the site has applied to a single program in the category (Incogni), but the homepage badge pluralizes it as "partners pending".

<span class="badge badge-pending">partners pending</span>

We’ve applied to one program in this category (Incogni — pending, unlinked)

Trivial, yet on a site whose brand is precise partner accounting, plural-vs-one is the sort of drift attentive readers use to gauge how carefully everything else was checked.

fix — In apex/index.html line 130, change the badge text "partners pending" to "partner pending".

Quiz claims every answer changes the verdict, but only two answers actually decide it

The verdict card (dedicated vs built-in) is determined solely by needsDedicated = eco === "mixed" || share === "often" (line 405). The other four answers only add or remove "fix first" advice items; toggling them never flips the verdict.

<strong>Answer all six</strong> — each one changes the verdict.

var needsDedicated = answers.eco === "mixed" || answers.share === "often";

A visitor who replays the quiz with different hygiene answers sees the same verdict and concludes the "each one changes the verdict" line is filler — a small crack in a site that stakes everything on saying only what's true.

fix — Change 'each one changes the verdict' at line 396 to 'each one shapes the advice' (matching the privacy hub's 'changes the plan' phrasing), since only the eco and share answers flip the verdict card.

Top-of-page affiliate disclosure omits the Proton Pass pending application that the FAQ discloses.

The page's main disclosure block enumerates partner statuses but skips Proton Pass, which appears below as 'partner pending' (line 267) and is correctly listed alongside 1Password in the FAQ.

1Password is a pending application (no link).

1Password and Proton Pass are pending applications

Minor on its own, but on a site selling disclosure completeness, an enumeration that misses one of its own pending programs chips at the claim that the disclosure block is the authoritative surface.

fix — Change line 59 of the top disclosure to '1Password and Proton Pass are pending applications (no links).' so it matches the slot badge and FAQ.

The README's first link-like reference points to an internal path a repo visitor cannot follow.

Both the brief (earn/docs/tools/pickguard.md) and the affiliate source-of-truth (earn/docs/research/cj-active-links.md, line 36) are bare paths outside this tool's directory, unusable as links and referencing internal revenue-ops docs.

- **Brief:** `earn/docs/tools/pickguard.md`

A curious stranger's first click target in the README is a dead reference, and the visible mention of private affiliate-ops files makes the doc feel like internal notes accidentally published rather than a project front door.

fix — Search tools/pickguard/README.md for the pattern "earn/docs/" and remove or replace both internal path references (lines 6 and 35-36) with public equivalents or delete them.

The footer's catalog-verified date is earlier than a 'checked' date shown inside a result card.

The footer (and LAST_VERIFIED, echoed in the chooser's catalog note) says 2026-08-01, but the HideMy.Name price note visitors see says its pricing was checked 2026-08-02.

Catalog last verified 2026-08-01.

no intro/renewal gap documented (checked 2026-08-02)

For a site whose differentiator is verified freshness, mismatched verification dates on the same screen make a careful reader wonder which date — if either — is real.

fix — Bump LAST_VERIFIED in catalog.js line 7 and the footer at index.html line 141 to 2026-08-02 so no visible per-option check date postdates the catalog-verified date.

The streaming toggle's helper text 'if it's genuinely your job' is baffling on first read.

It presumably means 'only weight streaming if that's genuinely the job you're hiring the VPN for,' but as written it sounds like the toggle is reserved for professional streamers.

Only score this if it's genuinely your job

A first-time visitor pauses at a form control they don't understand; every 'huh?' in a two-step tool that promised 'under a minute' costs momentum and finishes.

fix — Rewrite the sub-label at catalog.js line 178 to plain language, e.g. 'Turn this on only if streaming is a main reason you're getting a VPN.'

'Tracker-corroborated' cites unnamed trackers with no link, so the corroboration cannot be checked.

Two price notes lean on '(tracker-corroborated)' as evidence, but no tracker is ever named or linked from the rendered card; the reader is asked to trust an anonymous source. The header comment defers sourcing to 'hexento.com hubs' off-page.

Starter: $67.23 first 27 months, then renews ~$79/yr (tracker-corroborated).

// Facts snapshot: 2026-08-01 (vendor pages + corroborating trackers; see hexento.com hubs for sources).

Citation-shaped words without a checkable citation are trust theater; a skeptic reads 'tracker-corroborated' the same way they read 'studies show'.

fix — Search catalog.js for '(tracker-corroborated)' (lines 58 and 69) and either name and link the price tracker or delete the parenthetical.

The share-card description leads with denials of fraud nobody had yet accused the site of.

'No fake lab, no invented masthead' as the social preview means the very first thing a stranger reads is fraud vocabulary. The About body carries the same tic ('no twelve-person research lab,' 'no stock-photo team page'). Honesty is better demonstrated than announced.

<meta property="og:description" content="A small honest brand for decision utilities. No fake lab, no invented masthead." />

Preemptive 'we're not scamming you' framing primes a first-time visitor to think about scams, and self-applied 'honest' labels are a pattern strangers have learned to discount.

fix — Rewrite the og:description at line 13 (and the matching twitter:description at line 20) to lead with visitor value, e.g. 'Small tools and guides that help you pick consumer security software — or skip the purchase.'

The 'What we won't do' list mixes noun-phrase and verb-phrase items, so half the bullets don't follow the heading.

Items one and two are noun phrases ('Fake testimonials…', 'Scareware patterns…') that read as things-we-won't-do, but items three and four are bare verb phrases — 'What we won't do: Guarantee illegal outcomes' parses as a broken sentence.

Guarantee illegal outcomes, total anonymity, or permanent deletion from the internet.

Fake testimonials, fake lab counts, or “we tested 47 products” without a real method.

It's the page's ethics manifesto; uneven parallelism makes the most quotable list on the About page read as hastily assembled rather than carefully considered.

fix — Rewrite bullets one and two of the 'What we won't do' list (lines 95-96) to start with verbs — e.g. 'Publish fake testimonials…' and 'Use scareware patterns…' — so every item completes the heading.

The search-result description leads with internal positioning jargon: "one-operator brand for decision utilities".

"Decision utilities" and "one-operator brand" are strategy-memo vocabulary; this string is what a stranger sees in a Google result or link preview. The plain second half ("help you pick... or confidently skip the purchase") is the actual visitor-facing pitch buried behind it.

Hexento is a small, one-operator brand for decision utilities — tools and guides that help you pick consumer security software, or confidently skip the purchase.

In a SERP full of competitors, the site introduces itself in words no consumer uses, and the term "decision utilities" recurs on-page (line 52), so the visitor hits the jargon twice before learning what the site does for them.

fix — Reorder the meta description at line 7 to open with the plain pitch — 'Tools and guides that help you pick consumer security software, or confidently skip the purchase' — and drop 'one-operator brand for decision utilities'.

"The honest options are on the same pages as the partner ones" implies the partner options are dishonest.

The sentence (completed on line 90: "are on the same pages as the partner ones.") means to say free/non-partner picks aren't hidden, but its wording sets "honest" and "partner" as opposites — undercutting the page's own claim that partner links don't corrupt recommendations.

you can check us against it on any hub: the honest options

A careful reader catches the site accidentally conceding that its monetized recommendations sit outside the "honest" set.

fix — Replace 'the honest options' at line 89 with 'the free and non-partner options'.

The click-attribution fallback knows NordVPN, Surfshark, and NordPass but not HideMy.Name, a declared live partner.

Disclosure lists four live partners; the analytics href-sniffing fallback maps only three CJ ad IDs. HideMy.Name's ID (15618467, visible in apex/go/hidemy/index.html) is absent, so any HideMy.Name partner click without an explicit data-offer attribute is logged as offer 'unknown'.

if (href.indexOf("15545954") !== -1) offer = "nordvpn";

<strong>NordVPN</strong>, <strong>Surfshark</strong>, and <strong>HideMy.Name</strong>

Invisible to visitors, but it shows the partner roster and the tracking code drifted apart — the same drift pattern that produced the visitor-facing disclosure mismatches.

fix — Add 'else if (href.indexOf("15618467") !== -1) offer = "hidemy";' to the href fallback chain in bindOutboundClicks (after line 142).

If the Umami script fails to load, every subsequent event is queued forever and never flushed or capped.

onerror sets ready = true but umami.track never exists, so track()'s condition stays truthy and every later call pushes into a queue nothing will ever drain. The 'queue-until-ready' design has no failure branch that stops queueing or bounds the array.

if (!ready || !(global.umami && typeof global.umami.track === "function")) {

s.onerror = function () {
      ready = true;
    };

No visible breakage, but on an ad-blocked visit (common for this privacy-minded audience) the page slowly accumulates dead event objects for the whole session — sloppy for a file whose header banner promises 'never break page' discipline.

fix — Change track() to queue only while the script may still arrive — push only when !ready, and once ready is true without umami.track drop the event (or cap the queue, e.g. if (queue.length < 50)).

The lede's key superlative is both ungrammatical and unverifiable.

Regulators fine companies, not records, so the sentence doesn't parse, and 'worst ... ever' is exactly the kind of sweeping claim the page elsewhere refuses to make. The rap-sheet section below supports a strong claim; this phrasing overshoots it in the very first paragraph.

this category has the worst renewal-pricing record regulators have ever fined.

The lede is the 30-second read. A garbled hyperbole there makes a careful reader stumble before reaching the genuinely well-sourced material.

fix — Rewrite the lede clause to a grammatical, verifiable claim, e.g. '— and this category has a renewal-pricing record regulators keep fining', removing 'worst … ever'.

'Pickguard' sits unexplained in the primary nav on every page.

Four nav items are self-explanatory categories; 'Pickguard' is a coined product name (also literally a guitar part) with zero context in the nav. Only the About page explains it, and About isn't in the primary nav.

<a href="/pickguard/">Pickguard</a>

A first-time visitor scanning the nav can't guess what Pickguard is, and the flagship tool — the thing the site most wants clicked — is the one label that communicates nothing.

fix — Search every page for the primary-nav entry '<a href="/pickguard/">Pickguard</a>' and add context — a visible descriptor like 'Pickguard chooser' or a title attribute explaining it is the software-picking tool.

The breadcrumb names a 'Decision hubs' level that is not a link and has no index page anywhere.

The breadcrumb implies a hubs directory exists between Home and Antivirus, but 'Decision hubs' is plain text and no such listing is linked from nav or footer. Meanwhile About — the who-are-you page — is absent from the primary nav entirely, reachable only via some footers.

<p class="crumbs"><a href="/">Home</a> · Decision hubs · Antivirus</p>

Minor friction: the visitor who wants 'show me all the hubs' or 'who runs this' finds the obvious click paths missing and has to guess at footer links instead.

fix — Search for '· Decision hubs ·' in the crumbs of every hub page and either link that level to a real hubs index page or remove it, leaving 'Home · Antivirus'.

The Norton row in the evidence table hand-waves its lab scores while every other row gets precise numbers.

Defender and Malwarebytes get exact scores and dates; Norton — the product the page most criticizes on renewals — gets 'scores competitively in both labs' and 'top cluster historically' with no figures or dates. An evidence table that goes vague exactly where the criticism is sharpest weakens its own standard.

<td class="muted">scores competitively in both labs</td>

A skeptic notices the asymmetry and wonders whether the vague cells are unchecked filler, which taints the credibility of the precise cells too.

fix — Replace the Norton row's 'scores competitively in both labs' and 'top cluster historically' cells (lines 99-100) with dated numeric lab scores matching the precision of the other rows.

'Older laptops feel heavyweight suites the most' is a clipped construction that stumbles on first read.

'Feel' is used transitively with the suite as its object — the reader expects 'feel the weight of heavyweight suites' or 'feel it the most'. As written it momentarily parses as laptops touching software.

Older laptops feel heavyweight suites the most.

Minor, but it sits inside the constraint checklist that is the page's most practical section; each stumble accumulates against the crisp-editor persona the copy is selling.

fix — Rewrite to 'Older laptops feel the weight of heavyweight suites the most.'

The regulatory-actions intro volunteers the denial "not allegations we invented".

No reader was wondering whether the site fabricates regulatory allegations until the sentence raised it. It belongs to the same protesting-too-much register as the About page's fake-lab denials.

not allegations we invented:

Unprompted denials of dishonesty make a neutral reader briefly consider the dishonesty; a citation list with sources needs no such caveat.

fix — Delete ', not allegations we invented' from lines 145-146 so the intro ends 'All documented public actions:'.

Disclosure promises rel="sponsored noopener noreferrer" but shipped partner links omit noreferrer.

The disclosure states tracked outbound links carry noreferrer, but the live partner redirects for HideMy.Name and NordPass ship rel="sponsored noopener" only. Tiny, but it's a testable promise on the trust page that the shipped code fails.

Tracked outbound links use <code>rel="sponsored noopener noreferrer"</code>.

rel="sponsored noopener"

Invisible to most visitors, but the exact kind of reader this disclosure courts — one who inspects link attributes — will find the site's most checkable promise is inaccurate.

fix — Search all pages for rel="sponsored noopener" and replace with rel="sponsored noopener noreferrer" on tracked partner anchors (or relax the disclosure bullet at line 66 to match what actually ships).

Every page ships a different footer link set: disclosure drops Pickguard, antivirus drops Methodology.

The About footer offers Home/Pickguard/Methodology/Disclosure/Privacy, the antivirus footer swaps Methodology for About, and the disclosure footer drops both Pickguard and Disclosure. The variation goes beyond omitting the current page — each footer is a different hand-rolled list.

<nav aria-label="Footer">
        <a href="/">Home</a>
        <a href="/about/">About</a>
        <a href="/methodology/">Methodology</a>
        <a href="/privacy.html">Privacy</a>
      </nav>

<nav aria-label="Footer">
        <a href="/">Home</a>
        <a href="/pickguard/">Pickguard</a>
        <a href="/methodology/">Methodology</a>
        <a href="/disclosure.html">Disclosure</a>
        <a href="/privacy.html">Privacy</a>
      </nav>

Visitors learn footer geography quickly; links that appear and vanish between pages make the site feel stitched from copies rather than templated, a classic fast-built tell.

fix — Search for aria-label="Footer" across all pages and standardize every footer nav to one link set (Home, About, Methodology, Disclosure, Privacy), at most omitting the current page.

disclosure.html is the only reviewed page with no Open Graph or Twitter card metadata.

About and antivirus each carry a full og:/twitter: block with image dimensions; disclosure's head jumps straight from canonical to favicons. A share of the disclosure page renders a bare link card.

<link rel="canonical" href="https://hexento.com/disclosure.html" />

<meta property="og:type" content="website" />

Small, but disclosure is exactly the page skeptical people share when vetting a review site; a naked link preview makes it look like the afterthought page.

fix — Insert a standard og:/twitter: metadata block (og:type, og:site_name, og:title, og:description, og:url, og:image with dimensions, twitter:card set) into apex/disclosure.html's head after the canonical link, matching the pattern used in apex/about/index.html lines 10-21.

The page head omits og:title.

<head> contains no og:title

Search results and link previews render this page worse than pages that ship complete metadata.

fix — Add the missing head elements: og:title.

The page head omits meta description, canonical, og:title, viewport.

<head> contains no meta description, no canonical, no og:title, no viewport

Search results and link previews render this page worse than pages that ship complete metadata.

fix — Add the missing head elements: meta description, canonical, og:title, viewport.

24 pages share the identical title.

<title>Redirecting…</title>

Identical tab titles make the pages indistinguishable in history, tabs, and search results.

fix — Give each page a distinct title; the duplicate is "Redirecting…".

The page head omits meta description, canonical, og:title, viewport.

<head> contains no meta description, no canonical, no og:title, no viewport

Search results and link previews render this page worse than pages that ship complete metadata.

fix — Add the missing head elements: meta description, canonical, og:title, viewport.

The page head omits meta description, canonical, og:title, viewport.

<head> contains no meta description, no canonical, no og:title, no viewport

Search results and link previews render this page worse than pages that ship complete metadata.

fix — Add the missing head elements: meta description, canonical, og:title, viewport.

The page head omits meta description, canonical, og:title, viewport.

<head> contains no meta description, no canonical, no og:title, no viewport

Search results and link previews render this page worse than pages that ship complete metadata.

fix — Add the missing head elements: meta description, canonical, og:title, viewport.

Clicking a partner link flashes a raw gibberish tracking URL (dpbolvw.net/click-101847653-...).

The interstitial honestly labels the commission, but what the visitor actually sees mid-redirect is an unexplained numeric URL on dpbolvw.net — a domain indistinguishable from malware redirectors to a normal person. Nothing on the page says 'this is the CJ affiliate network.'

Redirecting to <a href="https://www.dpbolvw.net/click-101847653-15618467" rel="sponsored noopener">https://www.dpbolvw.net/click-101847653-15618467</a> (partner link — may earn commission)…

A cautious user who clicked 'HideMy.Name' and lands on dpbolvw.net for a beat may abort the click or conclude the site is shady, despite the label doing the right thing.

fix — In every apex/go/*/index.html, search for 'Redirecting to <a href' and rewrite the visible body text to name the destination brand — e.g. 'Taking you to HideMy.Name (partner link — may earn commission)…' — keeping the raw URL in the href only.

The page head omits meta description, canonical, og:title, viewport.

<head> contains no meta description, no canonical, no og:title, no viewport

Search results and link previews render this page worse than pages that ship complete metadata.

fix — Add the missing head elements: meta description, canonical, og:title, viewport.

The page head omits meta description, canonical, og:title, viewport.

<head> contains no meta description, no canonical, no og:title, no viewport

Search results and link previews render this page worse than pages that ship complete metadata.

fix — Add the missing head elements: meta description, canonical, og:title, viewport.

The page head omits meta description, canonical, og:title, viewport.

<head> contains no meta description, no canonical, no og:title, no viewport

Search results and link previews render this page worse than pages that ship complete metadata.

fix — Add the missing head elements: meta description, canonical, og:title, viewport.

The page head omits meta description, canonical, og:title, viewport.

<head> contains no meta description, no canonical, no og:title, no viewport

Search results and link previews render this page worse than pages that ship complete metadata.

fix — Add the missing head elements: meta description, canonical, og:title, viewport.

The page head omits meta description, canonical, og:title, viewport.

<head> contains no meta description, no canonical, no og:title, no viewport

Search results and link previews render this page worse than pages that ship complete metadata.

fix — Add the missing head elements: meta description, canonical, og:title, viewport.

The page head omits meta description, canonical, og:title, viewport.

<head> contains no meta description, no canonical, no og:title, no viewport

Search results and link previews render this page worse than pages that ship complete metadata.

fix — Add the missing head elements: meta description, canonical, og:title, viewport.

Non-partner Proton links use the same noindex instant-redirect cloaking as the affiliate links

Links declared 'not a partner link' are routed through the identical /go/ noindex, zero-second-redirect infrastructure used for commissionable CJ links. A user hovering a /go/ URL cannot distinguish paid from unpaid, and the indirection means a target could later be swapped to an affiliate URL without any visible change at the click site.

<p>Redirecting to <a href="https://protonvpn.com/" rel="noopener">https://protonvpn.com/</a> (not a partner link)…</p>

<meta http-equiv="refresh" content="0;url=https://www.anrdoezrs.net/click-101847653-15545954" />

Affiliate-style link cloaking on allegedly non-commercial links is a pattern skeptical users specifically check for. Linking Proton directly would cost nothing and remove the smell.

fix — Link non-partner destinations (Proton VPN) directly from content pages instead of through /go/ redirects, reserving the /go/ infrastructure for tracked partner links; then delete apex/go/proton_vpn/.

The page head omits meta description, canonical, og:title, viewport.

<head> contains no meta description, no canonical, no og:title, no viewport

Search results and link previews render this page worse than pages that ship complete metadata.

fix — Add the missing head elements: meta description, canonical, og:title, viewport.

The page head omits meta description, canonical, og:title, viewport.

<head> contains no meta description, no canonical, no og:title, no viewport

Search results and link previews render this page worse than pages that ship complete metadata.

fix — Add the missing head elements: meta description, canonical, og:title, viewport.

The /privacy/ hub is called 'privacy hub', 'Data-removal hub', and nav’s 'Data removal' interchangeably

The same URL is named three different ways across pages, while the footer’s 'Privacy' link goes to a different destination (/privacy.html, the policy). 'Privacy hub' next to a footer 'Privacy' link invites the wrong click.

On the <a href="/privacy/">privacy hub</a> we keep DIY and “skip paid” as first-class outcomes.

<a href="/privacy/">Data-removal hub</a>

A visitor told to visit the 'privacy hub' may reasonably click the footer 'Privacy' link and land on a privacy policy instead of the data-removal hub — small navigation friction that reads as sloppiness.

fix — Search for 'href="/privacy/"' across all pages and standardize the link text to 'Data-removal hub' (matching the nav's 'Data removal'), replacing 'privacy hub' at data-removal-diy-vs-paid.html line 153 and 'Privacy hub' at line 182.

A consumer guide dedicates a full section to the site's own future editorial policy.

The section is a promise memo about how the site will label links and treat commissions ('When partner links are live, they stay labeled') — governance narration, future tense, about Hexento rather than for the reader's decision.

<h2>How Hexento will treat this category</h2>

One paragraph of incentive transparency builds trust; a standing section about 'how we will behave' reads as the site performing its own integrity instead of finishing the reader's job.

fix — Fold the promises in the 'How Hexento will treat this category' section (data-removal-diy-vs-paid.html lines 151-157) into the existing affiliate-disclosure block at lines 57-61 or the methodology page, and delete the standalone section.

"Privacy" in the footer and "Data removal" in the nav point to two different /privacy destinations

On every page, footer "Privacy" goes to /privacy.html (presumably the privacy policy) while the nav's "Data removal" goes to /privacy/ (the product hub). Two near-identical URLs carry two unrelated meanings, and the word "Privacy" is used for the policy while the privacy product hub is labeled something else.

<a href="/privacy.html">Privacy</a>

<a href="/privacy/">Data removal</a>

A visitor hunting for the data-removal content who clicks footer "Privacy" lands on a legal policy page instead; a visitor pasting /privacy/ expecting a policy gets a product hub. It is a small maze on a site selling clarity.

fix — Search for 'href="/privacy.html">Privacy<' across all pages and rename the footer link text to 'Privacy policy' to disambiguate it from the /privacy/ data-removal hub.

"Every expert roundup we cite" names Wirecutter and PCWorld but links to neither

The sentence claims citations, but neither source is linked or dated beyond "2025 assessment," while the same page tells readers in its FAQ to "Check our sources yourself." The lab sources get URLs (av-test.org); the editorial ones get name-drops.

Every expert roundup we cite (Wirecutter’s security-expert consultations, PCWorld’s 2025 assessment)

A reader invited to verify sources will notice that half the sources cannot be followed, which weakens the page's strongest trust play.

fix — Add links to the specific Wirecutter and PCWorld pieces on do-you-need-antivirus.html line 133, or change 'we cite' to 'we consulted'.

'Worst renewal record regulators have ever put on paper' is unverifiable superlative rhetoric

The superlative can't be checked, and the supporting list mixes cases that are not renewal cases (the FTC Avast action was about selling browsing data; the $35M 'PC health checks' settlement was a retail tech-support scheme). Lumping them under 'renewal record' overstates the specific claim.

This category has the worst renewal record regulators have ever put on paper — an $80M McAfee settlement

The underlying enforcement history is genuinely damning and doesn't need inflation; a reader who knows any one of these cases spots the category-stretching and starts discounting the page's other claims.

fix — Replace the superlative on do-you-need-antivirus.html line 105 with a verifiable claim (e.g. 'a long regulator paper trail on billing and renewal practices') and reframe the Avast and $35M cases as general trust actions rather than renewal cases.

Antivirus guide sells the VPN true-cost calculator as built 'for exactly' suite-vs-pieces pricing

Everywhere else the /vpn/true-cost/ tool is described strictly as a VPN intro-vs-renewal calculator. Claiming it exists 'for exactly' pricing a security-suite bundle (VPN + password manager + identity monitoring + backup) against separate purchases oversells what the tool does.

price it against buying the pieces on their own merits (we have a <a href="/vpn/true-cost/">calculator</a> and <a href="/password-managers/">hub</a> for exactly this)

<a href="/vpn/true-cost/">VPN true-cost calculator</a> — intro vs renewal over 1 / 2 / 3 years,

A reader who clicks through expecting a bundle-vs-pieces comparison finds a VPN-only price tool — a small broken promise on a site whose brand is not overselling.

fix — Change 'for exactly this' on do-you-need-antivirus.html line 87 to accurate scope, e.g. 'a calculator for the VPN piece and a hub for comparing manager plans'.

'The only rigorous independent test' is an unverifiable absolute claim

Declaring one study the only rigorous test in an entire category is a universal negative the site cannot prove, and it quietly disqualifies all other evidence in advance. The DIY guide's own gentler framing ('one study isn't eternal law') handles the same fact honestly.

in Consumer Reports’ 2024 study — the only rigorous independent test — this manual

Absolutes are the tell of advocacy. A careful reader discounts a site that anoints its single supporting study as uniquely rigorous.

fix — Change 'the only rigorous independent test' on how-data-brokers-get-your-data.html line 102 to 'the most rigorous independent test we know of'.

A consumer skip-list bullet resolves in three unglossed enterprise acronyms and calls itself 'a consumer page'.

SSO/SCIM/IAM in one breath is IT-procurement register; and 'not a consumer page' is the page describing itself to the reader rather than addressing them.

You need enterprise SSO / SCIM / compliance — that’s a business IAM buy, not a consumer page.</li>

Mild — the readers who need this bullet mostly know the terms — but the self-referential 'consumer page' aside is the site talking about its own information architecture mid-sentence.

fix — Rewrite password-manager-vs-built-in.html line 163 in plain language, e.g. 'Your company needs centralized business logins and compliance — that's an IT purchase; ask your employer.'

security-stack-order’s breadcrumb drops the hub crumb every other guide carries

All seven other guides show Home · <Hub> · Guide; this one shows Home · Guide. If the omission is deliberate (cross-category guide), nothing signals that; it just looks like a missing crumb.

<p class="crumbs"><a href="/">Home</a> · Guide</p>

<p class="crumbs"><a href="/">Home</a> · <a href="/vpn/">VPN</a> · Guide</p>

Minor: a reader loses the one-click path back to a category hub that every sibling page offers, and the pattern break is noticeable to anyone reading more than one guide.

fix — Add a middle crumb to security-stack-order.html line 48 to match the Home · Hub · Guide pattern — either the most relevant hub or a neutral 'Guides' label.

An obscure brand, HideMy.Name, appears in the FAQ with no prior mention on the page

The page discusses Nord, Surfshark, Incogni, Express/Kape, and Mullvad, then the FAQ suddenly fields a question about HideMy.Name — a brand a mainstream visitor has never heard of and that appears nowhere else in these files.

<summary>What about HideMy.Name / smaller brands?</summary>

The out-of-nowhere name makes the FAQ feel generated or scraped from someone else's comment section rather than answering questions this page's readers would actually have.

fix — Generalize the FAQ question on sibling-vpn-brands.html line 161 to 'What about smaller brands?' or introduce HideMy.Name earlier in the body with context (and note its partner status per disclosure.html).

Live partners are disclosed as NordVPN and Surfshark '(among others)' without naming the others

On the page whose entire subject is hidden commercial relationships, the site's own disclosure names two partners and waves at an unnamed remainder. The reader must click through to disclosure.html to learn who else pays.

(among others). This page is not a crown ceremony for either brand. See

'Among others' is exactly the phrasing this page teaches readers to distrust in comparison charts; naming the full live-partner list inline would cost one sentence and match the site's stated standard.

fix — Replace '(among others)' on sibling-vpn-brands.html line 59 with the actual remaining live partners per disclosure.html: '(plus HideMy.Name and NordPass)'.

The logo checkmark on sibling-vpn-brands.html is missing stroke-linecap="round"

Every other page’s brand SVG draws the checkmark with round line caps; this page’s copy dropped the stroke-linecap attribute, so the checkmark ends render as flat butt caps. The logo is subtly different on exactly one page.

<path d="M23 32.5 29.5 39 42 25.5" fill="none" stroke="#5eead4" stroke-width="5.5" stroke-linejoin="round"/>

<path d="M23 32.5 29.5 39 42 25.5" fill="none" stroke="#5eead4" stroke-width="5.5" stroke-linecap="round" stroke-linejoin="round"/>

Nearly invisible, but it means the header logo is not pixel-identical across pages — the kind of drift that betrays copy-paste templating when someone does notice.

fix — Search for 'stroke-width="5.5" stroke-linejoin="round"' (the variant without stroke-linecap) and add stroke-linecap="round" — affected: sibling-vpn-brands.html, data-removal-diy-vs-paid.html, and password-manager-vs-built-in.html, each at line 33.

Unnamed 'auto-renewal class actions involving major consumer VPN brands' is insinuation without a citation

No brands, no case names, no links — just 'public reporting' about unspecified litigation. On a page that names exact renewal dollar figures, refusing to name the defendants reads as either fear of partners or a claim that can't survive specificity.

As of the 2026-08 snapshot, there was public reporting on auto-renewal class actions involving major consumer VPN brands.

A skeptical reader can't check it, so it carries zero evidentiary weight while still smearing the category — the same move fear-based VPN ads make in the other direction.

fix — Either name at least one specific case and brand with a link to the reporting, or delete the litigation sentence and keep the practical advice about reading the cancel flow.

The page invents a dangling '±' price notation that then needs its own legend to decode.

'~$79/yr ±' and '~$69.72 / 28 mo ±' (line 91) stack a tilde and a bare plus-minus with no range, and line 106 has to explain what '±' means. Consumer prose that requires a notation key has drifted into the researcher's private shorthand.

renews near <strong>~$79/yr ±</strong>

A shopper scanning for one number meets ambiguous math symbols and a footnote about corroboration; the precision theater reads as hedging rather than rigor.

fix — Search for the '±' character in guide prose and replace each dangling '±' with words (e.g. 'about $79/yr — not confirmed at checkout'), then delete the now-unneeded legend paragraph at vpn-renewal-trap.html lines 105-107.

Every single guide is labeled "Cornerstone guide," making the label meaningless

All eight guide pages under review carry the identical "Cornerstone guide" eyebrow. If everything is a cornerstone, the badge conveys nothing, and a visitor who opens a second guide immediately sees the template.

<p class="eyebrow">Cornerstone guide</p>

Repeated self-applied importance labels read as SEO-content-farm styling to an experienced web reader — the opposite of the handcrafted, evidence-first identity the copy works hard to build.

fix — Search for '<p class="eyebrow">Cornerstone guide</p>' across all guide pages and replace each with a page-specific eyebrow (e.g. the category name: 'VPN guide', 'Data removal guide') or remove it.

A recommended "prepaid access-code VPN" is teased but deliberately left unnamed

The page describes a specific, unusual product category and says the hub "covers one" without naming it, forcing a click to learn which product is meant.

you can keep a code in a drawer until the trip actually happens (the <a href="/vpn/">VPN hub</a> covers one)

On a site that criticizes coy vendor pricing, withholding a product name to farm a click reads as the same move in miniature; naming it costs nothing and the hub link could stay.

fix — Name the specific prepaid access-code VPN in the parenthetical on when-you-dont-need-a-vpn.html line 130 instead of 'covers one', keeping the hub link.

Category OG images are assigned inconsistently across same-category guides

Two VPN guides (vpn-renewal-trap, sibling-vpn-brands) use og-vpn.png but the third VPN guide (when-you-dont-need-a-vpn) falls back to generic og.png. Same pattern in the privacy category: data-removal-diy-vs-paid uses og-privacy.png while how-data-brokers-get-your-data uses og.png.

<meta property="og:image" content="https://hexento.com/og.png" />

<meta property="og:image" content="https://hexento.com/og-vpn.png" />

When these pages are shared side by side on social, siblings from the same category show mismatched card art, making the site look assembled rather than curated.

fix — Search for 'content="https://hexento.com/og.png"' in category guides and set og:image and twitter:image to og-vpn.png on when-you-dont-need-a-vpn.html and og-privacy.png on how-data-brokers-get-your-data.html.

"Pickguard" sits unexplained in the primary nav on every page

The nav item is an invented brand word with no descriptor. The homepage explains it two screens down, but a stranger landing directly on any hub page sees "Pickguard" between "Antivirus" and "Methodology" with zero context.

<a href="/pickguard/">Pickguard</a>

Minor friction: first-time visitors either ignore an unlabeled nav item or click it blind. A two-word descriptor ("Pickguard chooser") would remove the guesswork.

fix — Search every page for the exact string `<a href="/pickguard/">Pickguard</a>` and add a descriptor (e.g. rename the nav label to "Pickguard chooser" or add title="Constraint-based chooser for VPNs and password managers").

A consumer pricing footnote explains the vendor's JavaScript rendering to justify data sourcing

The footnote under the price table justifies tracker-sourced NordPass figures by describing how the vendor's web page is built ('renders prices via JS') — scraper-methodology detail in a shopping context. 'NordPass doesn't publish its renewal rate' is the visitor-relevant fact.

(vendor page renders prices via JS and hides renewal rates)

Non-technical shoppers hit dev jargon mid-table; the sourcing honesty survives without narrating the scraping obstacle.

fix — Replace "(vendor page renders prices via JS and hides renewal rates)" at apex/password-managers/index.html line 132 with "(NordPass doesn’t publish its renewal rate on its pricing page)".

Two different "privacy" pages (/privacy/ and /privacy.html) require an apology box to disambiguate

The nav's "Data removal" points to /privacy/ while the footer's "Privacy" points to /privacy.html, and the policy page opens with a note-box redirecting confused visitors. The URL collision is baked into the information architecture.

Looking for <em>data-broker removal</em> advice? That’s a different page:

A visitor who lands on the wrong privacy page gets a mild "huh?" moment; the site clearly knows it's confusing (hence the box) but shipped the collision anyway.

fix — Move the data-removal hub off /privacy/ (e.g. to /data-removal/) with a redirect, updating nav, footer, canonical, and sitemap links sitewide so /privacy.html is the only privacy-named URL.

The page head omits og:title.

<head> contains no og:title

Search results and link previews render this page worse than pages that ship complete metadata.

fix — Add the missing head elements: og:title.

Users who answered 'Looked — found nothing' can still be told they are probably listed and to file opt-outs

The clean answer only subtracts 2 from the score, so e.g. US + 15+ years + property owner (7 − 2 = 5) lands in the moderate band: the verdict asserts "Probably listed on at least the major aggregators" and, because band !== "low", the step logic tells this user to run the full opt-out first pass and save confirmations — for listings they just said they verified don't exist.

moderate: "Probably listed on at least the major aggregators",

if (answers.seen === "clean") score -= 2;

The tool contradicts the user's own reported observation, making the 'each one changes the plan' quiz feel like it isn't actually listening.

fix — When answers.seen === 'clean', route users to the spot-check/re-check step instead of the full opt-out first pass (change the condition at line 378 to exclude seen === 'clean', or cap the band at 'low' for clean answers).

A personalized exposure plan pauses to report the site's pending Incogni affiliate application

Inside the quiz's tailored advice — for someone who may have selected 'harassment or safety concern' — a step interrupts itself to narrate the site's affiliate-program status. The same pipeline narration recurs in the 'Partner status' note box (line 238: 'we’ve applied to Incogni’s affiliate program (pending — the name above is not a link)').

and our partner application there is pending, so that name is not a link today

The reader asked what to do about being listed on people-search sites; the site answers partly with its own business-development diary. Labeling links that exist serves visitors — explaining links that don't exist serves the operator's conscience.

fix — In apex/privacy/index.html line 387, delete the clause "— and our partner application there is pending, so that name is not a link today" from the quiz step; the Partner status note-box at line 238 already discloses this.

Sitemap lastmod for /vpn/ predates the page's own 'Last updated: 2026-08-02' stamp

The VPN hub displays Last updated 2026-08-02 (and cites prices "checked 2026-08-02"), but the sitemap still says 2026-08-01 for /vpn/ — and for /vpn/true-cost/, whose visible verification date is also 2026-08-01/02.

<url><loc>https://hexento.com/vpn/</loc><lastmod>2026-08-01</lastmod></url>

<time datetime="2026-08-02">2026-08-02</time>

Minor, but a date-obsessed site whose machine-readable dates lag its visible ones hands skeptics an easy 'they don't actually maintain this' gotcha.

fix — In apex/sitemap.xml update the <lastmod> for https://hexento.com/vpn/ (line 5) and https://hexento.com/vpn/true-cost/ (line 6) to 2026-08-04, and audit every remaining `<lastmod>2026-08-01` entry against its page's visible Last-updated <time> stamp.

HideMy.Name is 'running since 2006' but the audit gap is stated as 19 years in a 2026 snapshot

The fit paragraph dates the service to 2006 while the comparison table cell says "None — ever (19 yrs)" and the watch paragraph repeats "no independent audit in 19 years"; 2006 to the page's 2026-08 snapshot is 20 years by ordinary reckoning, so the two figures only reconcile if the service launched after August 2006 — which the page never says.

a no-account design that’s been running since 2006

<td class="bad">None — ever (19 yrs)</td>

A reader doing the subtraction gets a different number than the page's, which chips at the credibility of the site's signature 'we date everything' precision.

fix — Reconcile the age math: search apex/vpn/index.html for '19 yrs' (line 116) and '19 years' (line 290) and change both to 20, or replace 'since 2006' with the actual launch month that makes 19 correct.

A pricing-table cell cites 'Proton's payments API' as a source in consumer-facing copy

The 'Renews at' cell annotates the figure with how the builder verified it (an API query), repeated at line 276 and in cost.js line 75. The parallel Nord cell's 'vendor-disclosed' is the right register; 'payments API' is developer sourcing-jargon in a consumer comparison table.

<span class="muted">via Proton’s payments API</span>

Small, but the table momentarily addresses someone who audits data pipelines rather than someone buying a VPN.

fix — Search for the string "payments API" (apex/vpn/index.html lines 129 and 276, plus any occurrence in cost.js) and replace with reader-facing sourcing such as "vendor-disclosed renewal price".

Calculator shows HideMy.Name renewing at $36/yr, a rate the vendor never bills

For the 2-year term the "Renews at" cell renders usd(renewYr) = "$36/yr", but HideMy.Name's actual repeat purchase is $72 per 2 years; $36/yr is a silent annualization. The VPN hub's own table refuses to print a renewal number for this vendor ("No gap documented"), so the two surfaces present the same fact differently.

"2yr": { introTotal: 72, introMonths: 24, renewYr: 36 },

<td class="num">No gap documented<br /><span class="muted">card buys auto-renew; crypto is one-time</span></td>

A visitor cross-checking against hide.mn finds no $36/yr price anywhere, on a site that promises it will not present pricing it can't verify.

fix — In apex/vpn/true-cost/cost.js, stop rendering '$36/yr' for HideMy.Name: mark the row flat (flat: true) or add a per-plan renewNote so the Renews-at cell prints '$72/2yr — no gap documented' instead of usd(renewYr), keeping renewYr:36 only for the internal pro-ration math.

Machine-readable datetime claims a single day while the visible text claims a two-day range

The 'Prices last verified' time element carries datetime="2026-08-02" but displays "2026-08-01/02"; the attribute and the human-readable value disagree, and "2026-08-01/02" is itself a nonstandard range rendering.

<time datetime="2026-08-02">2026-08-01/02</time>

const CHECKED = "2026-08-01/02";

Tiny, but it is a dated-snapshot site getting its own date markup wrong on the page whose headline feature is verification dates.

fix — Make the time element's datetime match its text — either display the single date 2026-08-02 or split the range into two <time> elements with datetime="2026-08-01" and datetime="2026-08-02".

The true-cost page marks the /vpn/ nav link aria-current="page" though it is a different page

On /vpn/true-cost/ the primary nav flags the /vpn/ hub link as the current page. aria-current="page" tells assistive tech the link target is the page being viewed; a screen-reader user hears "current page" on a link that navigates away (aria-current="true" or section semantics would be correct).

<a href="/vpn/" aria-current="page">VPN</a>

<link rel="canonical" href="https://hexento.com/vpn/true-cost/" />

Screen-reader users get told they are on the VPN hub while using the calculator — a small accessibility inaccuracy on an otherwise carefully ARIA-annotated site.

fix — In apex/vpn/true-cost/index.html line 49, change aria-current="page" to aria-current="true" (or remove the attribute) on the /vpn/ nav link, since /vpn/ is the section, not the current page.

The README says non-partner redirects go to plain vendor URLs, but go/builtin targets a hexento guide page.

"Everything else redirects to plain vendor URLs" is contradicted by the shipped builtin redirect, whose target is hexento.com's own guide, not a vendor. Small, but it means the outbound documentation is already drifting from what ships.

`earn/docs/research/cj-active-links.md`); everything else redirects to plain vendor URLs.

<meta http-equiv="refresh" content="0;url=https://hexento.com/guides/password-manager-vs-built-in.html" />

Each place the docs and the shipped pages disagree teaches a careful reader that the written claims are approximate — costly for a tool whose differentiator is a "transparent scoreboard".

fix — Amend README line 36 to note the builtin option redirects to the site's own guide page while all other non-partner options redirect to plain vendor URLs (or make it true by fixing 121).

The page head omits meta description, canonical, og:title, viewport.

<head> contains no meta description, no canonical, no og:title, no viewport

Search results and link previews render this page worse than pages that ship complete metadata.

fix — Add the missing head elements: meta description, canonical, og:title, viewport.

The page head omits meta description, canonical, og:title, viewport.

<head> contains no meta description, no canonical, no og:title, no viewport

Search results and link previews render this page worse than pages that ship complete metadata.

fix — Add the missing head elements: meta description, canonical, og:title, viewport.

The page head omits meta description, canonical, og:title, viewport.

<head> contains no meta description, no canonical, no og:title, no viewport

Search results and link previews render this page worse than pages that ship complete metadata.

fix — Add the missing head elements: meta description, canonical, og:title, viewport.

The page head omits meta description, canonical, og:title, viewport.

<head> contains no meta description, no canonical, no og:title, no viewport

Search results and link previews render this page worse than pages that ship complete metadata.

fix — Add the missing head elements: meta description, canonical, og:title, viewport.

The page head omits meta description, canonical, og:title, viewport.

<head> contains no meta description, no canonical, no og:title, no viewport

Search results and link previews render this page worse than pages that ship complete metadata.

fix — Add the missing head elements: meta description, canonical, og:title, viewport.

The page head omits meta description, canonical, og:title, viewport.

<head> contains no meta description, no canonical, no og:title, no viewport

Search results and link previews render this page worse than pages that ship complete metadata.

fix — Add the missing head elements: meta description, canonical, og:title, viewport.

The page head omits meta description, canonical, og:title, viewport.

<head> contains no meta description, no canonical, no og:title, no viewport

Search results and link previews render this page worse than pages that ship complete metadata.

fix — Add the missing head elements: meta description, canonical, og:title, viewport.

The page head omits meta description, canonical, og:title, viewport.

<head> contains no meta description, no canonical, no og:title, no viewport

Search results and link previews render this page worse than pages that ship complete metadata.

fix — Add the missing head elements: meta description, canonical, og:title, viewport.

The page head omits meta description, canonical, og:title, viewport.

<head> contains no meta description, no canonical, no og:title, no viewport

Search results and link previews render this page worse than pages that ship complete metadata.

fix — Add the missing head elements: meta description, canonical, og:title, viewport.

The page head omits meta description, canonical, og:title, viewport.

<head> contains no meta description, no canonical, no og:title, no viewport

Search results and link previews render this page worse than pages that ship complete metadata.

fix — Add the missing head elements: meta description, canonical, og:title, viewport.

The page head omits meta description, canonical, og:title, viewport.

<head> contains no meta description, no canonical, no og:title, no viewport

Search results and link previews render this page worse than pages that ship complete metadata.

fix — Add the missing head elements: meta description, canonical, og:title, viewport.

The affiliate redirect page displays a raw jdoqocy.com tracking URL as its visible text.

If the instant redirect ever stalls, the visitor sees a bare page whose only content is 'Redirecting to https://www.jdoqocy.com/click-101847653-15438560' — an opaque tracking-network URL with no mention of Surfshark by name.

Redirecting to <a href="https://www.jdoqocy.com/click-101847653-15438560"

Random-looking click-tracker domains are the visual signature of malware redirects. A visitor who catches this page mid-hop gets a jolt of 'is this site safe?' right at the moment of conversion.

fix — In build_go.py's redirect template (and every generated go/*/index.html), replace the anchor's visible text — currently the repeated raw tracking URL — with the vendor name, e.g. 'Redirecting to Surfshark'.

The page head omits meta description, canonical, og:title, viewport.

<head> contains no meta description, no canonical, no og:title, no viewport

Search results and link previews render this page worse than pages that ship complete metadata.

fix — Add the missing head elements: meta description, canonical, og:title, viewport.

The page badges itself "honest" four times — in the meta, the JSON-LD, the hero, and the how-it-works panel.

"honest no-fit path" (line 7), "an honest no-fit path" (line 35), "an honest 'don't buy yet'" (line 66), and this heading. Honesty asserted this often reads as protesting too much; the no-fit behavior itself is the proof and doesn't need the adjective.

<div class="n">Honest no-fit</div>

Strangers discount self-applied virtue words, and repetition compounds the discount — by the fourth "honest" the visitor starts wondering why the site needs to keep saying it.

fix — Search index.html for 'honest' (lines 7, 35, 65-66, 113) and keep at most one instance, e.g. rename the panel heading to 'No-fit is an answer' and drop the adjective elsewhere.

The page leans on a repeating aphorism template and repeats "black box" twice in adjacent sections.

"Transparency beats a black box" (line 100), "no black-box 'AI ranking'" (line 110), "Shared vaults beat texted passwords" (catalog.js line 222), plus the hero's "Not another 'Best VPN 2026' listicle" sneer — the X-beats-Y / not-like-the-others tic stacks up until the voice sounds like it's performing itself.

Transparency beats a black box.

One aphorism lands; three in one scroll read as house filler, and the defensive 'we're not them' framing spends visitor attention on competitors instead of the visitor's decision.

fix — Search index.html and catalog.js for 'beats' and 'black box' (index.html lines 100 and 110, catalog.js line 222) and rewrite all but one instance to break the repeated X-beats-Y template.

"Deterministic" is an engineering term used as a consumer-facing panel heading.

The body copy beneath it ("Same inputs, same answer") already says the idea in plain language; the CS-vocabulary heading serves the builder's self-image, not the shopper.

<div class="n">Deterministic</div>

A non-technical VPN shopper skims headings first; a word from a programming textbook signals the page was written by and for developers.

fix — Rename the panel heading at index.html line 109 from 'Deterministic' to plain language such as 'Same inputs, same answer' and adjust the body copy to avoid repeating it.

"Click out" is affiliate-industry metric vocabulary surfacing in visitor-facing copy.

Clickout is what the operator's revenue dashboard counts; the visitor just "visits a site" or "follows a link". The sentence's reassurance is good — the word choice reveals which side of the transaction wrote it.

Useful even if you never click out.

Readers who know the term recognize they're being measured; readers who don't find the phrase slightly off. Either way the monetization register pokes through the editorial one.

fix — Replace 'click out' at index.html line 86 with visitor phrasing, e.g. 'Useful even if you never follow a link.'

Shipped JS opens with self-referential build narration about a lesson learned on another product.

"(Playkeg lesson)" is a note from the operator to themselves about a different project, delivered to every visitor's browser alongside the second playkeg.com leak (the analytics domain).

// Queue-until-ready Umami helper (Playkeg lesson). Shared Hexento website id.

View-source readers — the audience this site explicitly courts — get diary entries instead of product code, reinforcing that hexento.com is one person's side-project lattice rather than the sober review outfit the copy performs.

fix — Delete '(Playkeg lesson)' from the analytics.js line 1 header comment.

The runner-up is always labeled 'different tradeoff' but is simply whatever scored second.

rank() picks scored[1] with no check that it differs from the winner on any axis; the 'different tradeoff' framing is unconditional decoration that can be false (e.g. two near-identical mainstream picks).

cardFor(result.runner, "runner", "Runner-up · different tradeoff", result)

runner: runner && runner.score >= MIN - 8 ? runner.opt : null,

When the 'different tradeoff' turns out to be a near-clone of the winner, the label reads as canned copy and chips at the tool's claim of being smarter than a listicle.

fix — Search for 'different tradeoff' (app.js line 159, index.html line 65) and either drop the qualifier to plain 'Runner-up' or derive the label from an actual attribute delta between winner and runner-up.

The VPN step claims the pool includes 'free / built-in picks' but no free or built-in VPN option is scored.

The catalog note renders the same parenthetical for every category, yet the six scored VPN entries are all paid products (Proton's free tier exists only as a price-note aside on its paid listing, and there is no built-in VPN at all).

Scoring ${pool.length} options (including free / built-in picks)

If nothing clears the bar, we say so. Free tiers and built-ins are in the catalog and allowed to win.

A budget-minded user told the scoreboard includes free picks scans it, finds none, and files the promise with every other listicle's 'we considered everything' boilerplate.

fix — Make the catalog note in app.js line 55 category-aware: omit '(including free / built-in picks)' for VPN or render per-category text that matches what the pool actually contains.

The Copy result button fails silently without clipboard access, yet still logs share_clicked.

If navigator.clipboard is absent (insecure context, older browsers) the optional chain short-circuits and nothing happens — no 'Copied ✓', no fallback, no error handling on rejection either — while track('share_clicked') at line 237 fires unconditionally.

navigator.clipboard?.writeText(text).then(() => {

A user clicks Copy, sees no feedback, pastes nothing, and quietly loses faith in the tool's polish; meanwhile the analytics count a share that never happened.

fix — In onCopy (app.js lines 224-238), guard for missing navigator.clipboard with a fallback, add a .catch that shows a failure state, and move track('share_clicked') inside the success handler.

Recommendations are "options" in the UI but "offers" in the shipped analytics payload.

The outbound-click event names the recommended product an offer_code — sales-funnel vocabulary observable in the network tab of a page that insists commission never moves a score.

offer_code: opt.id,

A curious visitor watching requests sees their 'best fit' logged as an offer with a placement — the internal register quietly contradicts the editorial one the page works hard to project.

fix — Rename the analytics property 'offer_code' to 'option_id' in app.js line 208.

Form labels use reviewer jargon like 'Budget posture' and 'Privacy / audit posture'.

'Posture' (used twice — line 162's 'Privacy / audit posture' and here) is security-industry insider vocabulary; normal shoppers say 'budget' and 'privacy'.

label: "Budget posture",

Insider phrasing in a consumer-facing form makes a first-timer feel the tool was written for the author's peers, not for them — a small but real friction on a page selling accessibility.

fix — Search catalog.js for 'posture' (lines 162, 191, 235, 347) and replace with plain labels: 'Budget posture' → 'Budget', 'Privacy / audit posture' → 'Privacy & audits'.

NordPass's price note renders a dangling '(±)' with no value attached.

'(±)' with no number after it is meaningless notation that will render verbatim on the result card; every other price note uses complete phrasing.

Premium ~$23.88 first year, renews ~$35.88/yr (±). Free tier: unlimited items, one active session.

Broken shorthand in a price line — on the one partner-linked password manager, no less — reads like an unfinished editing pass exactly where readers scrutinize hardest.

fix — Delete the dangling '(±)' in catalog.js line 104 or replace it with an explicit qualifier such as '(varies by promo)'.

HideMy.Name is 'since 2006' but the caveat says 'No independent audit in 19 years' — off by one in 2026.

As of the page's own 2026-08 verification stamp, a service operating since 2006 has run roughly 20 years, not 19, unless it launched after August 2006. Blurb and caveat on the same card imply different ages.

No-account access codes since 2006:

caveat: "No independent audit in 19 years; streaming unreliable in recent tests;

Number-checkers — the exact audience this tool courts — will catch the mismatch on one card and start double-checking everything else.

fix — Replace 'No independent audit in 19 years' in catalog.js line 81 with age-proof phrasing such as 'never independently audited' so it cannot drift out of sync with 'since 2006'.

Rating chips are raw dot characters with no accessible text alternative.

The chips render as literal ●/○ glyphs inside a span (app.js line 187) with no aria-label or visually-hidden score, so screen readers announce a string of 'black circle' / 'white circle' instead of e.g. 'Privacy 4 out of 5'.

return "●".repeat(v) + "○".repeat(5 - v);

Screen-reader users get the rubric — the site's core trust artifact — as unintelligible symbol soup, on a results section that is otherwise carefully aria-labeled.

fix — In app.js line 187's chip template, add aria-label="{k} {n} of 5" to each .bar span and aria-hidden="true" on the .dots span, passing the numeric value through alongside the dot string.