Catalog customization guide
Adapt the catalog from example entries to products, tools, locations, people, or project units.
The catalog can represent many entity types. A software site might use it for integrations. A marketplace might use it for products. A documentation site might use it for APIs. A project site might use it for units or items. Keep the route generic unless the niche demands a specific noun.
The default route is /catalog/. Cards link to individual records, and taxonomy pages link back into the catalog. Rename labels in configuration before renaming files. If the underlying entity fields differ substantially, add new schema fields rather than overloading existing ones.
For best results, keep each record compact but complete: name, short description, categories, stats or attributes, related records, and source facts.
Adaptation Notes
Use this guide as a working pattern, not as fixed product copy. Replace the example nouns with your project’s real terminology, then verify that each internal link still points to a generated page. If a claim depends on external evidence, attach the source in the relevant content record instead of burying it only in prose. This keeps the guide readable for users and maintainable for editors.
Before publishing, inspect the rendered page on mobile and desktop. The template is intentionally dense, so headings, cards, tables, and callouts should be checked with real text rather than short placeholders. When a section no longer applies to your niche, remove it cleanly or replace it with a more useful workflow; do not leave empty headings behind.