Make curated-resource browsing incremental and crawlable

[LukasWallrich]

Context and corrected finding

The audit claimed that /curated_resources/page/2/ through /page/136/ form a 136-click sequence. That exact claim does not reproduce against the current deployment: /resources/ is the canonical landing page, /resources/page/2/ returns 404, and the current landing page is a roughly 3.8 MB headless page that renders the full resource collection with client-side filtering.

The underlying concern is still valid: visitors receive a very large initial document, and the resource collection does not have a server-rendered, crawlable browse structure by type, education level, subject, or language.

Requested change

• Replace the all-resources client-rendered monolith with an incremental, server-rendered browse experience.
• Provide crawlable links to stable subsets (for example, numbered pages or carefully selected taxonomy landing pages).
• Keep individual resource URLs stable.
• Do not create indexable combinations for every arbitrary filter; use canonical/noindex rules for filter variants where appropriate.
• Ensure each subset has useful title/description metadata and ordinary links to its resource pages.

Acceptance criteria

• Initial HTML is materially smaller than the current /resources/ response.
• A crawler without executing filter JavaScript can discover all resource pages through links and/or the sitemap.
• Keyboard users can browse and filter the collection without losing access to results.
• Representative subsets have unique canonical URLs and no duplicate-content explosion.

Reference: https://developers.google.com/search/docs/specialty/ecommerce/pagination-and-incremental-page-loading