Why Google Couldn't See 12 of My 14 Pages

The symptom

Chepatapa Apps has 14 pages: the homepage, a build log, and three app landing pages (Flare, Kin Compass, Bloomelle) each with support, privacy, and terms subpages. The sitemap listed all 14. Search Console had accepted it with zero warnings and zero errors. By any normal check, everything was fine.

Except URL Inspection told a different story: the homepage and /flare/ were "Submitted and indexed." Every other page — including /kincompass/ and /bloomelle/, the two newer apps — came back "URL is unknown to Google." Not "crawled, not indexed." Unknown. Google had never even tried.

What I ruled out first

The obvious suspects were all clean: sitemap XML validated, lastmod dates were current, robots.txt allowed everything (including the usual AI crawlers), no noindex anywhere, no redirect chains, every URL returned a plain 200. The last full crawl of the homepage was over three weeks stale, which pointed at a crawl budget problem rather than a straightforward block — a small, brand-new domain just doesn't get revisited often. That was a real factor, but not the actual cause.

The actual bug

The homepage's three app cards were <div> elements with a JavaScript onclick handler that ran window.location = '/flare/' and so on. The only real <a href> tags inside each card pointed to the support/privacy/terms subpages — the primary link to the app page itself didn't exist as an actual link.

It worked perfectly for a human: click the card, the JS fires, you land on the app page. It looked completely normal in the browser. But Googlebot doesn't execute arbitrary onclick handlers to discover new URLs — it follows href attributes. As far as a crawler reading the homepage's HTML was concerned, /kincompass/ and /bloomelle/ simply weren't linked from anywhere on the one page Google already knew about. Sitemap presence alone doesn't make up for that on a low-authority domain with almost no other signal pointing at those URLs.

The fix, and what else got cleaned up

Wrapped each card's icon and title in a real <a href="/flare/">, left the onclick in place as a progressive enhancement for the click-anywhere behavior instead of the only path in. Same pattern for all three cards.

While in there: swapped the 500–600KB homepage app icons for the 15–19KB versions that already existed for the web manifest, added explicit width/height so the layout doesn't shift while they load, self-hosted the one Google Font the homepage used instead of a render-blocking request, and added an IndexNow key so Bing and Yandex get pinged directly on changes instead of waiting to notice.

What happened next

/kincompass/, /bloomelle/, and /build-log/ all got crawled and indexed the same day the fix shipped — a domain that had gone three-plus weeks without a single crawl got visited within hours of becoming reachable again. The nine support/privacy/terms subpages are still catching up; they're a second hop deeper in the link graph, discoverable only through the app pages that were themselves just unlocked, so they're following on the next crawl pass rather than instantly.

The takeaway

A navigation pattern can be functionally invisible to a crawler while looking completely normal to every person who tests it by clicking around. Sitemap validity and a clean robots.txt tell you the site isn't blocking anything — they don't tell you the site is actually linked together. The only way to catch this kind of thing is to look at what's literally in the HTML, not what renders after a click.