What a Spanish post claims to be is set in two places on this site, and only one of them shows up in devtools. SEO.tsx is a React component; it runs after mount and writes attributes onto a live document [4]. scripts/prerender.mjs writes the bytes Vercel actually sends, and at commit 86569b0 a grep for hreflang inside it returned zero matches [5]. That script rewrote the head element only, which is why the lang attribute kept whatever index.html had baked in [6].
The check that passed was an honest check: open the page, read documentElement.lang, count the alternate links, get es and three tags [1]. The author's own account of the failure is the part worth keeping. "I did not verify the wrong thing here. I verified a real thing on the surface that was easier to reach." [19]
What kept it green under a second look deserves more attention than the original miss. Every page ships a link rel=alternate for the RSS feed, so grepping the served HTML for "alternate" produces a hit that has nothing to do with translations [9]. A string search confirms the string. The sitemap carried no xhtml:link alternates either [8], so nothing independent existed to contradict the browser.
The 21 August fix has prerender.mjs set lang on the html element and emit the alternates, reading src/config/translations.json, the same file src/config/translations.ts reads, because a .mjs build script cannot import a .ts module [11][12]. After it, four paired posts carry three hreflang links each [13]: twelve annotations in the served HTML [2] that until then existed only in a document no non-rendering crawler ever built. Unpaired posts get zero, which is the right number, since an hreflang pointing at a translation that does not exist is a false claim [14]. Google runs JavaScript, so the author reads the episode as delay rather than loss [10]. The engines that do not render spent the interval indexing Spanish prose declared as English.
The second bug in the same writeup is the same defect with the surface taken away. On 20 August at 22:48 the ad code read AdSense's silence three seconds after mount as a verdict of no-response, and the CSS collapsed the container to display:none while AdSense was still measuring it [15]. Nine hours and fifty-eight minutes later [1] the timeout came out, and a missing verdict became pending, which reserves space instead [16]. In production the end-of-post unit reaches data-adsbygoogle-status done and then never receives data-ad-status at all [17], so pending never ends. Measured on 23 August: that slot sat at 303px with the Advertisement label visible and zero iframes inside it, while the in-article slot reported unfilled and collapsed to 0px [18]. Two units on the page, an ad in neither [3].
Both bugs are a default picked for an unknown. no-response and pending are each a guess about what a third party's silence means, and the guess is the point where the code stops being checkable by looking at it.
