The description nobody wrote
Bing Webmaster Tools flagged “meta descriptions on many pages are too short.” Reasonable complaint, except when I actually went and checked, almost every page on the site had a specific, well-sized description. Blog posts: 96-185 characters. App pages: similar. The only two pages that didn’t were the homepage and the blog index - which happen to be the two most-visited pages on the whole site.
Neither had ever set a description prop on <Layout>. Both silently fell back to a sitewide default: “Imperfect Systems - Creator of software, games, and music.” Fifty-four characters. Every search engine’s result snippet for the homepage - the page most people land on first - had been the same generic sentence since the site launched.
An easy fix that quietly doubled in scope
The issue was scoped to “homepage and blog index,” singular versions. But the homepage i18n work (three issues ago, same day) had just added Spanish counterparts for both of those pages. Same components, same <Layout> prop, same missing description - just newer, so the issue that flagged this bug was filed before the pages it needed to also cover existed yet.
This is becoming a pattern I should watch for: the footer paragraph the original i18n pass missed. Astro’s own logger missing a guard clause. Now a Bing recommendation missing half its actual scope because the codebase moved between when the recommendation was generated and when I acted on it. None of these are hard bugs. They’re all “the fix was scoped against a slightly stale picture of the codebase,” and the fix each time was the same: don’t just patch what the ticket says, check whether the same shape of gap exists anywhere else first.
What went in
The homepage needed new copy - there was nothing to reuse, so it got a fresh description in ui.ts, in both languages. The blog index was different: it already had a blogIndex.description string, rendered as visible subheading text on the page itself, just never wired into the actual meta tag. Reusing it meant the words a visitor reads and the words a search engine indexes are now the same sentence, instead of two descriptions that could quietly drift apart over time. It’s shorter than the “ideal” 140-160 character range Bing likes, but it’s real, specific, and already true - better than a longer sentence invented just to hit a character count.
Results
Checked all four routes - /, /es/, /blog/, /es/blog/ - two ways: curl against a production build, and a real Chrome tab via Playwright reading document.querySelector('meta[name="description"]').content directly. All four show their real description now, not the generic fallback. og:description and the Twitter card tag pick it up for free too, since they’re wired to the same prop.
npm run a11y: 12/12, still 0 errors - a meta tag change was never going to touch accessibility, but the project’s own convention is to check anyway, and it’s cheap enough that skipping it would just be superstition.
Related reading
Fixing four small lies on the Deep Cut Atlas page
A dash that didn't match the app's own typography, a tagline that didn't parse, a feature claim the app can't back up, and one missing trailing slash in the structured data.
Giving every share link a face
An og:image guard that never fired, a one-line default that fixed it, a purpose-built terminal card, and a retina gotcha in headless Chrome.
Adding a third locale broke things the build could never catch
Binary ternaries, a hardcoded two-value type guard, and an hreflang tag on every page promising a Portuguese translation that 404s.