Internal Link Architecture for Marketplace Templates

Internal linking is a distribution problem before it is a search problem, and on the marketplaces we work with the template does most of the linking while the conversation stays on editorial links inside body copy. The first artefact we produce is a crawl depth and inlink count for every indexable URL, and the first finding is usually that pages carrying revenue sit four or five clicks from the homepage while a tag archive nobody reads sits at two. What we start from: A full crawl, joined to Search Console impressions and to revenue per URL from your analytics. Three numbers per page: clicks from the homepage, how many internal links point at it and from where, and what it earns. Pages that earn and are buried are the shortlist. Everything else is noise, including the tidy orphan report most audits open with, which typically lists pages that were orphaned for good reason. Template links versus editorial links: Contextual links inside body copy are what clients want to discuss, and they are a rounding error next to navigation, footers, related-item modules and pagination. Most of the engagement goes on the modules. What does the related-products block select, and on what rule. Is the footer repeating four hundred links on every page. Is pagination crawlable at all, or does it sit behind a click handler. Does the breadcrumb reflect the taxonomy you actually want indexed, or the one the database happens to have. Changing one module rule redistributes more in a single deploy than a year of adding contextual links by hand. Faceted navigation: On a marketplace this is where the work lives. We decide which facet combinations get a crawlable, linkable, indexable URL and which stay as parameters nobody links to. The rule we apply is demand plus inventory: a facet earns a real URL when there is query evidence for it in your own data and enough listings behind it that the page will not be empty in a slow month. Everything else is a filter, not a page. This normally cuts the linkable facet surface hard, and it is the change your engineers will push back on, so we write the rule as a condition that can live in the template rather than a list someone has to maintain by hand forever. What you receive: An architecture document specifying the rules in the language your developers work in, a change list per module with the reasoning attached to each one, a priority order, and the before figures so the effect is measurable at the next crawl. We will work alongside your engineers through implementation if you want that. We do not commit code to your repository. Not included: Anchor text spreadsheets listing every desired link, one row per pair. That artefact is out of date the day after delivery and we stopped producing it years ago. External link acquisition. Redirect mapping for retiring pages, unless the conflict or decay work is running in parallel and the maps can be merged. Skip this if: Your site is under a few hundred URLs. The architecture is already legible at that size and your constraint is content, not distribution. Skip it too if navigation is owned by a design team that treats link count as a purely visual decision and will not entertain a rule that adds or removes links for machine-readable reasons. We have lost that argument before at other companies, and we would rather not bill you to lose it again here.