SEO

Faceted navigation indexation plan

Use when a filtered ecommerce or listing site is generating more URLs than it should index.

faceted-navigation-plan.md

Download .md

You are deciding which faceted and filtered URLs should be indexable.

Site and vertical: {{SITE_AND_VERTICAL}}
Facet types available (for example brand, size, color, price, rating, sort): {{FACET_TYPES}}
Example generated URLs: {{EXAMPLE_URLS}}
Facets with real search demand: {{DEMAND_DATA}}
Current handling: {{CURRENT_HANDLING}}

Output:
1. A decision table: Facet or combination | Estimated URL count | Search demand evidence | Decision (Index / Noindex follow / Canonical to parent / Block in robots / Do not generate) | Reason.
2. A rule set an engineer can implement, written as ordered conditions, covering single facets, two facet combinations, three or more, sort orders, pagination and empty result pages.
3. A migration order: what to change first so pages de-index before crawl paths are removed.
4. A monitoring plan: what to watch for 8 weeks and what would mean it went wrong.

Constraints:
- Only recommend indexing a facet where {{DEMAND_DATA}} shows demand. Do not assume demand.
- Never recommend robots.txt blocking as the way to de-index something already indexed. State the correct sequence.
- Say explicitly what happens to internal links pointing at newly non-indexable URLs.

Fill in before running

Replace each placeholder with your own detail. The more specific you are, the less the model invents.

{{SITE_AND_VERTICAL}}
{{FACET_TYPES}}
{{EXAMPLE_URLS}}
{{DEMAND_DATA}}
{{CURRENT_HANDLING}}

Getting a better result

Get demand data per facet value, not per facet type - a few brands usually carry all the volume.
The migration order matters more than the rules; de-index before you block.
Keep a permanent list of the indexable combinations so the rules survive the next replatform.

Questions about this prompt

When does faceted navigation become an SEO problem?

When filter combinations generate more URLs than the site should ever index, which happens quickly: three facets with ten values each is a thousand pages. The symptom is crawl budget consumed by near-duplicate listings while real category pages go stale in the index.

Which facets should stay indexable?

The ones with genuine search demand, which is why the prompt wants demand data per facet value rather than per facet type. Colour as a facet type may look worthless while two specific brands carry real volume, and a rule written at the type level throws those away.

What order should I implement the changes in?

De-index before you block. Blocking in robots.txt first means the crawler can no longer see the noindex tag, so the pages stay in the index indefinitely. The order matters more than the rules themselves and it is the mistake most often made.

How do I stop this recurring after a replatform?

Keep a permanent, written list of the indexable combinations. Faceted rules are rebuilt from scratch at every replatform unless the decisions live somewhere outside the old platform, and the problem comes straight back.