Playbook + practice template · Free to use
Ecommerce architecture & internal linking
Map important shopping routes and turn orphan-page findings into reviewed link changes.
Practice datasets are fictional and labeled as such. Real store captures are dated observations with their own sources and evidence limits.
Choose a bounded part of the catalog
Start with one department and its products, categories and buying guides. The aim is a route a shopper and crawler can follow, not a target number of links per page. Bring a catalog export, a crawl export with source and destination links, XML sitemaps and current navigation. Record crawl limits; a page missed by a capped crawl is not automatically orphaned.
Separate the commercial hierarchy from the URL path. A product may belong in several useful collections without needing a different canonical address for every path. Keep product identity stable while allowing multiple discovery routes. The workbook records one row per proposed source-to-destination link, its purpose and its owner.
Reconcile catalog, crawl and sitemap
Match records using stable product IDs where available. Preserve the original URL and source before normalization. Lowercasing a case-sensitive path or dropping a meaningful variant parameter can merge different resources. Identify products present in the catalog but absent from the crawl, then inspect whether any public page links to them.
Classify findings as confirmed orphan, excluded from this crawl or unresolved. A sitemap entry can help discovery but does not show how a customer reaches the page. Conversely, a product intentionally withheld from sale should not be promoted simply to make a crawl report look complete.
| Product | Catalog | Crawl | Decision |
|---|---|---|---|
| Trail shoe A | Active | Reached through Running | Keep route |
| Trail shoe B | Active | Not found; linked only from internal search | Add a suitable category link after verification |
| Prototype C | Unreleased | Absent | Do not expose it to satisfy a coverage target |
Design routes around decisions
For each important product group, write the route from department to category to product and the return route. Add a guide only where it resolves a real selection question. A waterproofing guide can link to compatible footwear; linking every article to every shoe creates noise rather than useful context.
Use link text that identifies the destination. “Compare trail shoe grip” tells a reader more than “read more.” Keep menus manageable by exposing major groups and letting category pages provide finer choices. Do not hide essential product discovery behind a site-search form or an interaction that has no navigable destination.
- Pick five important products, including one deep in the range.
- Trace each route from the public department page on mobile.
- Record broken, misleading or missing steps.
- Choose the smallest useful link addition or category repair.
- Inspect the rendered anchor and final destination, then repeat the crawl.
Worked repair: a product available only through search
In the fictional example, shoe B is purchasable and listed in the XML sitemap but can only be found by typing its exact model into store search. The solution is to include it in the maintained Trail Running category, not to put a link in the footer of every page. A grip guide also links to B because it is one of the compared models.
The ticket names two source pages, one final product URL and descriptive anchor text. Acceptance requires that the product appears in the correct category after stock refresh, that the link is present in rendered output and that a fresh crawl reaches the product without using search. It does not promise that Google will index the page immediately.
Keep filters and retired products out of automatic rules
Avoid generating links to every possible filter combination. Use an explicit list of maintained destinations for editorial and category links. Changing price, sort order and session parameters should not accidentally multiply sitewide navigation.
When retiring a product, review links that still name its model. Redirecting to a successor without changing the surrounding explanation can mislead shoppers about compatibility. Keep a support route if manuals or replacement parts remain useful; remove buying links when a purchase is no longer possible.
Measure discovery and usefulness separately
Save before and after crawl settings, counts and representative routes. Confirm the repaired destination with the same crawl scope. Track clicks on the added links where consented analytics exists, but avoid interpreting every added internal click as incremental revenue.
Practice: a buying guide links to three retired products and one active model. Write an update plan. Worked answer: verify whether the recommendations remain accurate, preserve support links where needed, replace purchasing recommendations with tested current options and disclose meaningful differences. Pass when every recommendation lands on the product it actually describes.
Sources and maintenance
Check current platform documentation before implementation. Review these instructions when your platform, catalog behavior or source guidance changes.