Build1 publisher3 min readPublished
Pub-trivia.app builds its footer from its content registry so Google's mobile crawl reaches every hub
Pub-trivia.app generates its footer from its content registry after a curl showed four of its six content hubs missing from the header HTML. On the mobile page Google crawls, its developer says, the footer is the only site-wide navigation, so the generator has to link every hub.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction

What happened
- A curl of the homepage returns six header links, the logo, three cluster links and two auth buttons, for a site of around 70 public pages.
- The missing hubs sit in a Radix dropdown whose items mount only when the menu opens, so the server-rendered HTML never contains them.
- The nav holding the three visible header links carries the class hidden md:flex, so none of them display on a narrow viewport.
- About and the three legal pages had been typed into three separate files that drifted apart, leaving /about linked only from the homepage footer.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint A hub reachable only through an open-on-click Radix menu needs another link in the server HTML, and on this site the generated footer is the one place guaranteed to supply it.
- decision Designing for the strict case, where CSS-hidden links do not count, makes the footer responsible for all six hubs; if Google does follow them, only the four dropdown hubs depend on it.
- capability Because footer, breadcrumbs and sitemap read one registry, a new cluster hub gets its footer link in the same change that publishes it, with no separate nav edit to forget.
Only one of those gaps is certain. The dropdown hubs are absent from the response, so a crawler reading that HTML has nothing to follow [3]. The bar links are present. The curl found them [1], and the CSS class hides them without removing them from the markup [4]. The developer counts both sets as gone on the mobile page Google indexes. On that reading, the footer is the only site-wide navigation the crawler gets [5]. The post does not test how the crawler treats a link that is in the HTML but not displayed.
The old footer was four columns typed out in app/page.tsx. That was adequate when the site had eight pages [6]. It now has around seventy, close to nine times as many [1][1]. The new footer is generated from the content registry. The registry is the same single array that produces every page's metadata, breadcrumbs and sitemap entry [7]. The footer follows one rule: every cluster hub has to be in it [7]. The company links now come from one exported array for the same reason [9].
The developer stops short of generating the whole navigation. "Two of the three decisions in this file are not derivable," the developer wrote [10]. Header placement is written out by hand [11]:
```ts const HEADER_CLUSTERS: readonly ClusterKey[] = ['features', 'solutions'] const RESOURCE_CLUSTERS: readonly ClusterKey[] = ['guides', 'quiz-questions', 'tools', 'compare'] ```
The two header entries and the four Resources entries account for all six clusters. The four in Resources are the hubs missing from the header [2]. In my view this is the right split for a site that ships clusters in phases. Which hubs a buyer sees first is an editorial judgement, and no property of a cluster encodes it [11]. The explicit ordered list also means a cluster added later cannot silently push Pricing off the end of the bar [11]. Publication is the derived part. A cluster appears in the nav because its hub page exists, and the Resources menu returns an empty array until one of its clusters is built [12].
The bug the developer missed at first came from a cosmetic rule. The generator only adds a column that holds more than one link [13]. The developer wrote that a Resources heading sitting above a single Guides link looks as if something failed to load [17]. A cluster whose only footer link sat in a suppressed column lost that link. On mobile it then had no site-wide link anywhere [14]. The fix promotes a single leftover cluster to a column of its own spoke pages [14].
The configured spoke cluster is Solutions, capped at five entries: Pubs, Bars, Restaurants, Breweries and taprooms, Sports bars [15]. The developer picked it because "is there a page for my kind of venue" is the question that sends people looking [15]. When there are more spokes than the cap, an "All solutions" link to the hub follows [16]. Features keep a single hub link. The developer's reasoning is that nobody looks for team scoring before looking for quiz software [16].
What to watch
- Search Console data on how Google reaches the four dropdown hubs: through the generated footer, or through sitemap entries written from the same registry.
- A change that puts the Radix menu items into the server-rendered HTML, or drops hidden md:flex from the header bar, would end the footer's role as the only crawled site-wide navigation.