
Field notes / Technical SEO
Ecommerce Site Architecture: A Crawlable Catalog Blueprint
Organize categories, products, menus, and breadcrumbs into a catalog that shoppers and search engines can navigate.
The short answer
Important products need discoverable links and a logical home in the catalog.
Inventory the real structure
Start with a crawl export, your product catalog, and the actual navigation that customers see. A spreadsheet hierarchy alone does not establish that products are discoverable. Compare each active product with the categories linking to it. Identify products found only in the XML sitemap, internal search results, or a temporary promotional landing page.
Group issues by template and cause. An entire subcategory missing from navigation requires a different fix from a single product with an incorrect collection assignment. Record URL, status code, canonical, parent category, and internal-link sources. For large stores, sample representative templates first, then expand the crawl to quantify each confirmed problem.
Build around product relationships
Choose parent and child categories that reflect how people shop and how the catalog is maintained. Use customer questions, product attributes, internal search terms, and search-result inspection to inform the structure. Avoid creating categories simply because a tool lists a phrase. A category needs coherent inventory and an identifiable purpose.
As an illustrative example, a parts catalog might organize by component type while also offering fitment selectors. Those are different navigation systems, and each needs a deliberate URL policy. A fitment combination with no stock and no useful alternatives should not automatically become a permanent search landing page. Agree with the merchandising team on which combinations deserve ongoing maintenance.
Make links accessible
Use ordinary anchor links with valid destinations for important navigation. Confirm that link targets are present in rendered HTML and that they lead to working pages. Google explains that it generally discovers pages through links, so a catalog dependent on search-box submissions can hide important paths.
Review desktop menus, mobile menus, breadcrumbs, product cards, and pagination. A category visible on desktop but absent from mobile navigation can also create a poor customer experience. If JavaScript changes the navigation, inspect the rendered result rather than assuming that the initial response contains every destination. Keep link labels descriptive and avoid a global menu so overloaded that it becomes difficult to use.
Separate discovery from indexation
Discovery asks whether a crawler can find a URL. Indexation asks whether that URL should be eligible to appear in search. A store can deliberately expose product links while preventing low-value filtered states from becoming search results. Do not confuse a sitemap entry with a promise that Google will index the page.
Review canonical tags, noindex directives, robots rules, and redirects together. They perform different jobs and can conflict when deployed without a shared policy. For example, a crawler blocked from fetching a URL may not see a noindex tag on that URL. Document the intended behavior before implementing rules across a complete template.
Maintain the hierarchy as inventory changes
Add architecture checks to product launches and collection changes. A new collection should have a clear parent, relevant products, a working canonical, and links from suitable navigation or content. Retiring a collection requires reviewing internal links and deciding whether a genuinely equivalent replacement exists.
Track orphaned active products, broken category links, and important products accessible only through deep pagination. Use these as maintenance signals, not invented ranking scores. Measure results through crawl observations, Search Console, and customer navigation data. The objective is a catalog that remains understandable as it grows, not an arbitrary maximum number of clicks for every possible product.
Sources & further reading
Examples are illustrative, not client case studies. Platform features and search requirements can change; consult the linked primary documentation before implementation.