Index pages are the connective tissue of any large site. A good index turns a sprawl of individual pages into a navigable surface: alphabetical lists of glossary terms, categorised directories of contractors, ordered libraries of recipes. The format is rigid: title, intro, optional filters, an ordered or alphabetical list of links to entries, FAQ, footer. Every variation in chrome between index pages hurts readability and internal linking.

SleekRank reads index rows from Google Sheets, CSV, JSON file or a REST endpoint. The entries column carries a JSON array of objects with slug, label and optional category fields. A list mapping renders them into a real ul on the base page, sorted by the configured order column. Tag mappings handle title and intro, meta mappings handle description and og:image, and CollectionPage JSON-LD is populated from the same array.

The /index/{slug}/ pattern stays clean as the site adds new indexes for new content types. Adding a row about all-recipes-by-cuisine or all-contractors-by-region takes a sheet edit and a cache flush, not an editor session per index. Adding a new entry to an existing index is appending it to the JSON array in the row. Deleted entries vanish from every index that referenced them on the next cache cycle.

Indexes are the part of a site readers and search engines use to understand what is actually there. A site with strong indexes feels comprehensive even when the underlying content is modest; a site with weak indexes feels chaotic even when the content is rich. Hand-built index posts cannot keep pace with a growing library.

Editors add new content but forget to wire it into the right indexes, indexes drift apart in styling and structure, internal-link maintenance falls behind, and the navigation surface gradually decays into a heap of stale, half-updated lists. The structured approach makes indexes a property of the data. Adding a new entry to an index is a JSON array append, retiring one is an array remove, and the rendered page always matches the source.

The chrome stays uniform because every index passes through the same template, and the CollectionPage schema stays consistent because it reads from the same selectors as the visible list. The audit story is the other half. Editors can sort the source by last_updated to find stale indexes, filter by category to spot coverage gaps, or join with traffic data to identify which navigation surfaces earn the most traffic per entry.

The library becomes inspectable in ways that scattered WordPress posts never are.