The listing had nothing to crawl
wordsaresnake.no's Google search result showed as a bare text link. The title, description, and social tags were already solid; the actual gap was robots.txt, a sitemap, and structured data.
wordsaresnake.no’s Google search result was a bare text link, no icon, no rich preview, nothing to distinguish it from any other line of blue text. The obvious suspect, weak title and description tags, turned out to be wrong: every route already carried solid title, description, Open Graph, and Twitter tags. The actual gap was more basic than metadata quality. There was no robots.txt, no sitemap, and no structured data at all, so a crawler had nothing beyond the raw HTML to build a richer result from.
All three landed together. robots.txt disallows the API routes, the internal stats dashboard, and PvP’s dynamic game URLs, then points at a sitemap. That sitemap is a server route rather than a static file, built from an explicit list of the eight real, crawlable pages, so it can’t silently drift out of sync with whatever routes the app actually has. VideoGame structured data went on the main menu only, not site-wide, since that’s the one page representing the whole game rather than a specific mode.
// Guard against a value ever prematurely closing the enclosing tag.
return json.replace(/</g, '\u003c');A narrower question rode along: the site’s favicon is SVG-only, and SVG’s support in Google’s search-results icon feature specifically is murkier than its formal spec status suggests. Google’s own documentation accepts SVG as a valid favicon format outright, but several independent sources describing the real-world behavior of that one feature consistently flag SVG as weaker and less reliable there than PNG or ICO, and recommend a raster fallback even though nothing forces one. That gap between formally accepted and reliably rendered was reason enough to add a 48x48 PNG alongside the existing SVG rather than argue from the spec alone.
Building that PNG needed rendering an SVG to a raster image, and this devcontainer keeps no SVG-to-PNG tool installed, no rsvg-convert, no ImageMagick, no Inkscape. The fix reused a tool that was already there for an unrelated reason: the headless Chromium bundled for the end-to-end test suite opened the SVG as a page and screenshotted it, producing the PNG without adding a single new dependency to the project. The SVG link tag stayed in place alongside the new PNG one; nothing was removed, only added.
Verifying the domain in Google Search Console and submitting the new sitemap is next, a step nobody but the site’s owner can take since it requires signing into an account this project has no API access to. Whether any of this actually changes what the search result looks like won’t be visible until Google’s crawler gets around to it.