ECOMMERCE

Restructure a category tree

Use when the category tree has grown by accretion and shoppers cannot find things you definitely stock.

catalog-taxonomy-restructure.md

Download .md

You are a merchandising lead restructuring a category tree. You are not writing page copy and you are not choosing which products go where.

Current tree, one node per line with depth shown by indentation:
{{CURRENT_CATEGORY_TREE}}
Live product count per node: {{PRODUCT_COUNTS}}
What shoppers type into on-site search: {{SEARCH_TERMS}}
Platform constraints on depth, naming and node limits: {{PLATFORM_LIMITS}}

Produce:
1. PROBLEM LIST - nodes that are empty, near duplicates of a sibling, deeper than {{PLATFORM_LIMITS}} allows, or named in wording that never appears in {{SEARCH_TERMS}}. One line each with the figure from {{PRODUCT_COUNTS}}.
2. PROPOSED TREE - the full tree rewritten, depth shown by indentation.
3. MAPPING TABLE - Old node | New node | Action (keep, rename, merge, split, remove) | Redirect needed | Reason in under 15 words.
4. LEFT ALONE - nodes you did not touch and why.

Rules:
- Every node in the proposed tree must exist in {{CURRENT_CATEGORY_TREE}} or be a merge of nodes that do. Do not invent range you were not shown.
- Do not create a node holding fewer products than the minimum you state at the top of the output. Propose it as a filter instead.
- Name nodes in shopper wording, not buying team wording.
- Every merge must name both source nodes. No em dashes.

Fill in before running

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

{{CURRENT_CATEGORY_TREE}}
{{PRODUCT_COUNTS}}
{{SEARCH_TERMS}}
{{PLATFORM_LIMITS}}

Getting a better result

Get the product counts from live inventory, not the catalog, or you will build nodes that are empty on launch day.
The mapping table is the redirect spec. Hand it to development as it stands rather than rewriting it into a ticket.
Restructure once a year at most. Each pass costs you rankings and internal links you will spend months rebuilding.

Questions about this prompt

When should I restructure rather than add another category?

When shoppers cannot find things you definitely stock, and adding a node is how the tree got this way. Restructure once a year at most, as the tips say, because each pass costs rankings and internal links you spend months rebuilding. Adding one category to solve one complaint is not this job.

What do I need in front of me before proposing a new tree?

The current tree with depth shown by indentation, live product counts per node, what shoppers type into site search, and your platform limits on depth and naming. Take counts from live inventory rather than the catalogue, or you will launch nodes that are empty on the day they go live.

What comes back, and what do I hand to development?

A problem list with the figure behind each entry, the rewritten tree, a mapping table giving action and redirect per node, and the nodes left alone with reasons. The mapping table is the redirect specification. Hand it to development as it stands rather than rewriting it into tickets and losing rows.

What gets forgotten at launch?

Shipping the tree and treating redirects as a follow up ticket. Every renamed or merged node is a URL change and the mapping table is the only record of what pointed where. Read the left alone list too: a node you expected to see there and do not is a change nobody asked for.