Search Console reports ~157k soft 404s and the drilldown is 88% /tag/*. The
cause is not thin tags -- it is the default filter. modelFilterSchema defaults
to period: Month with periodMode: 'published', so the grid only shows models
whose lastVersionAt falls inside a 30-day window. A tag whose models all
shipped earlier renders nothing while the meta description and CollectionPage
schema on the same page advertise the full all-time count.
Measured on the prod replica: 224,624 of the 243,469 tags that have published
models -- 92% -- render an empty grid under the default, and 22,931 of those
have five models or more. /tag/badik has four models, all published Feb-Apr
2026, and shows none of them under a promise of four.
Adds `periodFallback`, an opt-in flag on getAllModelsSchema. When set, and the
FIRST page of a period-filtered query returns nothing, getModelsInfiniteHandler
retries once at AllTime. Only /tag/:name passes it: an empty result is the
correct answer on a browse feed, so this must not become ambient behaviour.
Three guards, each mutation-tested:
- first page only -- the paging loop advances input.cursor, so the original is
captured before it runs; without this, paging to the end of a tag would throw
the reader back to page one of a different result set
- opt-in only -- otherwise the browse feed silently stops honouring its filter
- the retry resets the cursor -- an empty page that still reports a nextCursor
leaves a stale one behind, and the retry would resume mid-list
The flag lives on the server schema and reaches ModelsInfinite as its own prop
rather than a ModelFilterSchema field, because that schema is what gets
serialized into the `model-filters` localStorage key -- a per-page concern must
not be persisted into every user's stored preferences.
🔴 THIS IS A STOP-GAP. It fires on exactly zero results, and the bad experience
does not start at zero: a tag with 255 models where 3 shipped last month shows
3 of 255, the fallback does not fire, and the page is still wrong in the way
that matters. The real fix is for the tag page to derive its default period
from tag volume server-side -- getTagPageSeoData already returns the count and
is already cached for a day -- held as page-local state so the filter control
stops displaying a value the query is not using. When that lands, delete
periodFallback, periodFallbackApplied and the retry block. docs/seo-improvements.md
carries the reasoning and the closing condition.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015mc2rXbJwfbTzhwcGAocMF
briant
e60d745f97