Related Products & Internal Linking

TL;DR — Those “You May Also Like” and “Frequently Bought Together” boxes on product pages aren’t just there to sell more stuff. Each product in the box is a link — and links are how Google finds and connects your pages. So the same widget your store built to boost sales is quietly doing SEO work too. The trick is making sure it does that work well: the links have to be real clickable links (not fancy JavaScript buttons Google can’t read), and they should say what they point to (the product’s name), not just “View.”

What these modules actually are

Almost every online store shows you extra products while you shop: “You May Also Like,” “Related Products,” “Frequently Bought Together,” “Customers Also Viewed.” Your merchandising or marketing team builds these to sell more — cross-sell a phone case with a phone, upsell a nicer model.

Here’s the part most people miss: each of those recommended products is a link. And links are the roads Google travels to find your pages. So a “related products” box is doing two jobs at once — nudging shoppers and connecting your catalog together for search engines.

Why that matters for SEO

Google finds your products by following links. Your main menu and category pages link to a lot of them — but not always all of them. Big catalogs have products buried deep, or ones that fall off the end of a long category listing. Google says so itself: if your category pages don’t link to every product, Googlebot might not find them all just by crawling.

A good related-products box is a second set of roads into those buried products. It links product-to-product, so a deep item that nothing else points to can still get discovered.

The two things to get right

1. Real links, not JavaScript-only buttons. If the “related products” carousel is built so clicking it runs a script (instead of being a normal clickable link), Google may never see those products through it. The links need to be real HTML links — the kind you could right-click and “open in new tab.”

2. Say what you’re linking to. If the link’s text (or the image’s alt text) is just “View” or “Shop now,” Google learns nothing about the page it points to. Use the product’s actual name. That helps Google understand what the linked product is.

The simple version

• Related-product boxes are a real SEO channel, not just a sales gimmick — they help Google find and connect your products.
• Make sure they’re built as real, clickable links.
• Use the product name as the link, not “View” or “Learn more.”
• Point them at products that are actually related, not eight random items from the same category.

Want the technical version — how to reconcile “sell more” with “rescue orphaned pages,” how many links is too many, and what to do when a linked product sells out? Switch to the Advanced tab.

TL;DR — Related-product modules are internal links first and merchandising second, so treat them as a crawl-path and anchor-text asset. The accuracy spine: they only pass value if they’re real crawlable <a href> links — “Google can’t reliably extract URLs from <a> elements that don’t have an href attribute” — and if the anchor text is descriptive (the product name, not “View”). Two goals fight inside one widget: a rules engine optimizes for order value, not for rescuing orphaned/thin pages, so deliberately steer some links toward deep, high-margin, and best-selling products. Dense cross-linking on ecommerce sites is not inherently a problem (Mueller) — the real failure mode is letting cross-links replace a recognizable category hierarchy. A sitemap gets pages indexed, not well-contextualized — it’s a supplement to on-page links, not a substitute.

The two purposes hiding in one widget

Every “You May Also Like” module is doing two jobs that don’t automatically align:

• Commerce-driven linking — a merchandiser or a rules engine picks the items (complementary products, “frequently bought together,” basket-affinity data). It’s optimized for conversion and average order value.
• SEO-driven linking — deliberately linking to orphaned, deep, or thin-authority product pages, with descriptive anchor text, so they get crawled, indexed, and passed relevance signal.

Most stores only do the first and get the second by accident. The whole point of this piece is to make them overlap — or at least coexist without one degrading the other. Because a rules engine tuned for order value has no reason to link to your low-margin, low-conversion product that badly needs the internal-link signal. If SEO value is going to happen, someone has to steer it there.

The candidates themselves come from different places, and it’s worth knowing which: manual merchandiser curation, behavioral/co-purchase data, and rules-based similarity (shared category or attributes) are distinct recommendation sources with different inputs — platform docs from Shopify and Adobe both document these as separate recommendation types, not one interchangeable “related products” pool. That provenance matters because a candidate that’s a good conversion pick isn’t automatically a good SEO pick, and vice versa.

The crawl-path case: category pages and sitemaps aren’t enough

Google reaches your product pages mostly by following the links on your category pages — but category listings can’t always link to everything. Pagination cuts a long catalog into pages; filters and merchandising exclusions hide items; best-sellers hog the top slots. Google states the gap plainly: “If category pages don’t include direct links to all products in a category, Googlebot might not find all of your products by crawling alone.”

Related-product modules are a second, product-page-level path into those pages. They matter because Google’s own guidance is that “every page you care about should have a link from at least one other page on your site” — and a related-products module is one of the few on-page mechanisms that can be that link for a deep SKU.

Two myths die here:

• “A sitemap covers it.” No. Google frames sitemaps and Merchant Center feeds as a supplement — “these sources can include links to pages a crawler would not otherwise find” — not a replacement for crawlable on-page links. Sitemaps get pages indexed; they don’t give Google the on-page context that decides how a page is understood and ranked. A page reachable only via sitemap is a page Google sees with almost no relevance context.
• “Best-sellers don’t need extra links.” They benefit most. Google’s ecommerce guidance: “if you have a best selling product, consider linking to it from the home page or in other content, such as blog posts or newsletters.” The same logic applies to steering related-product links toward your revenue-critical items.

Getting the technical implementation right

This is the load-bearing requirement, and it’s where JS-heavy recommendation apps fail silently.

Real <a href> links, not JS-only click handlers. Google is explicit: “Google can’t reliably extract URLs from <a> elements that don’t have an href attribute.” If your carousel renders each item as a <div onclick> or a button wired to a router event, Google may never discover those products through the module — no matter how good “Google renders JavaScript now” sounds. Rendering is a second wave that can lag, and it doesn’t manufacture an href that was never in the markup.

Practical implementation rules (these echo the widget guidance vendors like Bloomreach publish for their recommendation products):

• Render the module’s links in HTML, server-side, not injected by a client-side AJAX call after load.
• Make the module visible on page load — not hidden behind a tab, an accordion, or a “load more” click, and not styled invisible.
• Keep desktop and mobile URL structure matching — with mobile-first indexing, Google predominantly uses the mobile rendering of your page, so a module that only exists (or only links) on desktop is a module Google largely doesn’t see.

Anchor text for recommendation widgets

Anchor text is a relevance signal Google reads, and for image-based product tiles the image’s alt text functions as the anchor text. So the rule is the same as anywhere: describe the destination.

• Use the product name or a short descriptive phrase, not “View,” “Shop now,” or “Learn more.” Google’s link guidance tells writers to avoid generic anchors like “click here” and to make anchor text that makes sense on its own. Jon Clark’s ecommerce internal-linking guide critiques a real West Elm implementation on exactly this point — arguing “a better anchor text implementation could be done here” about generic “Learn more” links.
• Vary the phrasing naturally across the same product’s inbound related-links rather than repeating one exact-match phrase in every module that points to it. Ramming the identical keyword-stuffed anchor into hundreds of tiles is an over-optimization signal, not a ranking hack.

Relevance beats volume — the thin/irrelevant link block

A “related products” grid that’s really just “here are eight random SKUs from the same category” reads as low-value to users and, by Google’s own framing, as poorly integrated content. Mueller’s advice for making deep pages count is to “make sure that those pages are well-integrated with your website so that we have a clear context of how those pages should belong” — an arbitrary category-fill grid does the opposite of that.

The relevance ranking, roughly:

• Co-purchase / “Frequently Bought Together” — driven by actual basket-affinity data, so items tend to be genuinely related (a phone and its case), which gives you better anchor-text context and avoids the thin-block problem.
• Complementary products — a merchandiser or rules engine pairing categories (a blazer → shirts and trousers). Relevant when the rules are sane.
• “Related”/“same category” fill — the weakest, because “also in this category” isn’t the same as “actually related to this item.”

None of these is a distinct ranking factor. “Frequently Bought Together” isn’t magically better SEO than “Related Products” — its only edge is relevance quality, which is exactly the thing that makes the anchors and crawl paths worth having.

How many related-product links is too many?

Less of a problem than people fear. Google has no ideal internal-link count, and Mueller has said he doesn’t see an issue with dense internal linking specifically on ecommerce sites. The real constraint isn’t a link-count ceiling — it’s keeping the category hierarchy recognizable when Google crawls. His framing on flat vs. pyramid structure is the caveat: “Whereas if it’s very flat, then we think, oh all of these are equally important and we don’t really know which of these are connected to each other.”

So the failure mode isn’t “too many related-product links.” It’s related-product links that replace or obscure the pyramid — a product discoverable only via other products’ widgets, never via its own category page. Related links are a supplement to category → subcategory → product, not a substitute for it. On this site, ecommerce site architecture treats related products as one of the four link types (nav, category pages, breadcrumbs, related products) that tie the hierarchy together — they work with the pyramid, not instead of it.

There’s a long-running community retort — “I’ll stop doing it when it stops working” — aimed at tactics SEOs keep using despite Google’s guidance because they still seem to move rankings. My take is the same as it is for keyword-stuffed footer text: betting against a documented spam signal is fragile. Build the module for genuine relevance and you never have to make that bet.

Reconciling cross-sell (commerce) and SEO-driven linking

The practical reconciliation:

1. Let the rules engine drive the primary carousel for conversion — that’s what it’s good at, and AOV pays the bills.
2. Add a deliberate SEO layer. Either configure the rules engine to include, or add a separate curated set of links to: (a) orphaned/deep/thin-authority products that need the crawl path and signal, and (b) your highest-margin and best-selling items (Google explicitly recommends linking best-sellers from high-authority pages). Before adding a rescue link, check the destination’s response status, canonical, and index eligibility — a related-products link to a 404, a redirect chain, or a noindexed page doesn’t rescue anything, it just moves the problem one hop deeper into the catalog.
3. Global vs. contextual placement. For a handful of revenue- or traffic-critical SKUs, a global header/footer link earns its place. For the long tail, page-specific contextual related-product modules are the right tool — that’s where the crawl-path value for deep pages actually lives.

Maintenance: stale links, out-of-stock swaps, redirects

Related-product links are a quiet source of technical debt. When a linked item goes out of stock, is discontinued, or gets redirected, the module keeps pointing at it.

• Out of stock ≠ delete the link. The general guidance covered under out-of-stock products applies: keep the page live and linked with an OutOfStock availability rather than reflexively stripping internal links, since removing internal links can weaken the pages you still care about.
• Discontinued products — Google’s guidance favors keeping the URL live with alternatives, or redirecting to a relevant category or replacement product, over a blanket 404; a wave of related-product links suddenly pointing at soft-404s is the kind of mess that accumulates unnoticed.
• Audit for it. Stale related-product links pointing to 404s and redirect chains are easy to miss because the widget still looks fine on the page.

Measuring whether it worked

• Internal-link reports. Ahrefs Site Explorer’s “Pages by internal links” and “Internal link opportunities,” plus Google Search Console’s internal-links report, show which products are under-linked and which the related modules are actually feeding.
• A lightweight before/after test. Pick comparable product cohorts, add or expand the related-links module on one cohort, and compare indexing speed, impressions, and pageviews against the held-back cohort. Treat any single-store case study — including the vendor case studies floating around claiming large conversion lifts from added internal links — as directional, not proof.

Where this sits

Related products are one piece of ecommerce site structure. For the pages on either end of these links, see product page SEO (the PDP the module lives on — it shouldn’t be a dead end) and category page SEO (the listing whose crawl-path gaps these modules backfill). Faceted navigation is the adjacent crawl-budget concern when the same products appear across dozens of parameterized “related” URLs. And the general mechanics — internal links, internal linking strategy, and anchor text — live in the technical-SEO website-structure cluster; this piece is their ecommerce-specific application.

AI summary

A condensed take on the Advanced version:

• Related-product modules are internal links first, merchandising second. “You May Also Like,” “Frequently Bought Together,” and “Customers Also Viewed” open crawl paths into deep catalog pages and pass relevance/PageRank between products.
• Two purposes fight inside one widget: commerce-driven (rules engine → order value) vs. SEO-driven (rescue orphaned/deep pages with descriptive anchors). A rules engine won’t link your low-margin page that needs the signal — someone has to steer it there.
• Crawl-path case: category listings can’t always link to every product (pagination, filters, exclusions), and Google says Googlebot may not find them by crawling alone. A sitemap gets pages indexed, not well-contextualized — it’s a supplement, not a substitute for on-page links.
• Technical requirement: real crawlable <a href> links, not JS-only click handlers — “Google can’t reliably extract URLs from <a> elements that don’t have an href attribute.” Render in HTML, visible on load, desktop/mobile parity.
• Anchor text: the product name (or descriptive alt text on image tiles), not “View”/“Learn more”; vary it naturally, don’t stuff one exact-match phrase.
• Relevance beats volume: co-purchase data > complementary rules > arbitrary “same category” fill. “Frequently Bought Together” isn’t a distinct ranking factor — its edge is relevance quality.
• Volume isn’t the risk — Mueller sees no issue with dense ecommerce internal linking; the risk is cross-links replacing a recognizable category hierarchy.
• Maintenance: don’t strip links when items go out of stock; redirect discontinued targets to alternatives/categories rather than mass-404ing.

Official documentation

Primary-source documentation from the search engines.

Google

• SEO Link Best Practices for Google — crawlable <a href> requirement, descriptive anchor text, and “every page you care about should have a link from at least one other page.”
• Help Google understand your ecommerce site structure — category pages must link to all products; linking best-sellers from high-authority pages; sitemaps/feeds as a supplement to crawlable links.
• Managing crawling of faceted navigation URLs — the crawl-cost problem when the same products sprawl across many parameterized URLs.
• Designing a URL structure for ecommerce sites — keeping internal links (including related-product links) off temporary/tracking parameters.

Bing / Microsoft

• Bing Webmaster Tools — Link Building — Bing’s general internal-linking and anchor-text guidance. The live help page renders via JavaScript and resisted automated verification — treat as directionally aligned with Google (crawlable HTML links, descriptive anchors) rather than quoted verbatim.
• IndexNow Enables Faster and More Reliable Updates for Shopping and Ads (May 2025) — relevant tangentially: pinging IndexNow when a linked SKU is swapped out helps Bing pick up the changed link graph faster.

Quotes from the source

On-the-record statements from Google, plus practitioner coverage. Each link jumps to the source; deep links jump to the quoted passage where the page allows it.

Google docs — crawlable links & anchor text

• “Google can’t reliably extract URLs from <a> elements that don’t have an href attribute.” — Google Search Central, SEO Link Best Practices. This is the load-bearing requirement for related-product carousels. Jump to quote
• “Every page you care about should have a link from at least one other page on your site.” Jump to quote

Google docs — ecommerce site structure

• “If category pages don’t include direct links to all products in a category, Googlebot might not find all of your products by crawling alone.” Jump to quote
• “if you have a best selling product, consider linking to it from the home page or in other content, such as blog posts or newsletters.” Jump to quote

John Mueller, Google — integration & structure

• “make sure that those pages are well-integrated with your website so that we have a clear context of how those pages should belong” — on making deep pages count. Relayed via Search Engine Land coverage (Barry Schwartz); the original hangout is the primary source. Coverage
• “Whereas if it’s very flat, then we think, oh all of these are equally important and we don’t really know which of these are connected to each other.” — on flat vs. pyramid site structure. Reported by Search Engine Journal. Coverage
• Mueller has also said, paraphrased from a Search Central hangout, that on large ecommerce sites the important thing is that Google can still recognize a structure — home page, top-level and second-level categories — and that he doesn’t see an issue with heavy internal linking on ecommerce sites specifically, as long as that hierarchy stays legible. Paraphrase of a Google hangout via secondary coverage; verify against the original video before treating as a direct quote. Secondary source

Jon Clark, Search Engine Land — internal linking for ecommerce

• “These links are invaluable for cross-selling, upselling, and flattening the overall website architecture.” — on related-product widgets across live sites (People Also Viewed, Pairs Well With, etc.). Substring not re-verified against the live page — confirm before deep-linking. Article
• “I would argue that a better anchor text implementation could be done here” — critiquing generic “Learn more” links on a real West Elm implementation. Substring not re-verified against the live page — confirm before deep-linking. Article

Related-products SEO checklist

A pass to confirm your recommendation modules actually pull SEO weight:

Crawlable and visible

• Each recommended item is a real <a href> link, not a <div onclick> or a JS router event.
• Links are rendered in HTML (server-side), not injected only after a client-side AJAX call.
• The module is visible on page load — not hidden behind a tab, accordion, or “load more,” and not styled invisible.
• Desktop and mobile show the same module and the same link targets (mobile-first indexing).

Anchor text

• Anchor text is the product name / a descriptive phrase, not “View,” “Shop now,” or “Learn more.”
• For image-only tiles, the image alt text is descriptive (it acts as the anchor text).
• The same product’s inbound anchors vary naturally — no single exact-match phrase stuffed everywhere.

Relevance

• Recommendations are genuinely related (co-purchase or sensible complementary pairing), not eight random SKUs from the same category.
• The module deliberately includes some orphaned/deep/thin-authority products that need the crawl path.
• Best-selling and high-margin products are among the link targets.

Structure & maintenance

• The category hierarchy is still recognizable when crawled — no product reachable only via related-product widgets.
• Out-of-stock linked items keep their link (with OutOfStock availability), not stripped reflexively.
• Discontinued targets redirect to a relevant alternative/category rather than mass-404ing.
• Audited for related-product links pointing to 404s or redirect chains.

Measure

• Internal-link reports (Ahrefs “Pages by internal links,” GSC internal links) checked for under-linked products.

The mental models

1. It’s a link, not a widget. Every tile in a “You May Also Like” module is an internal link. Judge it the way you judge any internal link: is it crawlable, is the anchor descriptive, is the target worth linking to? The merchandising label on the box is beside the point.

2. Two purposes, one UI — score both. Commerce (rules engine → order value) and SEO (rescue orphaned/deep pages) share the same widget but don’t share the same goals. Every module should be checked against both: is it converting and is it feeding the pages that need crawl signal? If only one, you’re leaving value on the table.

3. Supplement the pyramid, never replace it. Related links work with category → subcategory → product, not instead of it. The test: could Google still recognize your category hierarchy if it ignored every related-product link? If a page is reachable only via cross-links, that’s a structural red flag even though it’s technically linked.

4. Relevance is the whole SEO value. Co-purchase data > sensible complementary pairing > arbitrary “same category” fill. The reason “Frequently Bought Together” is worth more isn’t a ranking bonus — it’s that genuinely related items give you honest anchor context and a crawl path that actually makes sense.

5. Steer, don’t just install. A recommendation app installed and left alone optimizes for AOV only. SEO value requires deliberately steering some links toward the deep, thin, high-margin, and best-selling pages the rules engine would never prioritize on its own.

Related products & internal linking — cheat sheet

Implementation: do / don’t

Which data source, and what it’s good for

Maintenance rules

Fast facts

• Sitemaps get pages indexed, not well-contextualized — not a substitute for on-page links.
• Dense ecommerce internal linking: no inherent problem (Mueller) — keep the hierarchy recognizable.
• “Frequently Bought Together” is not a distinct ranking factor — its edge is relevance quality.
• No nofollow on internal related-product links — nofollow is for untrusted/paid/UGC external links.

What goes wrong

The failure modes that quietly cost you the SEO value of these modules:

The JavaScript-only carousel. The recommendation app renders each tile as a <div onclick> or a button wired to a client-side router. It looks and clicks fine for users, but there’s no href for Google to extract — so the deep products the module is supposed to surface stay undiscovered through it. “Google renders JS now” doesn’t save you: rendering is a lagging second wave, and it can’t invent an href that was never in the markup.

The AJAX-injected, hidden, or desktop-only module. Loaded after the fact by a client-side call, tucked behind a tab, or only present on the desktop template. Mobile-first indexing means Google mostly sees your mobile page — a module that isn’t there, isn’t visible on load, or isn’t crawlable is a module that isn’t helping.

“Learn more” / “View” anchors everywhere. The tiles link out with generic anchor text (or empty image alt), so every related-product link tells Google nothing about its destination. This is the exact thing Clark critiques in West Elm’s implementation.

The thin/irrelevant grid. “Related products” that’s really eight random SKUs from the same category. Low value to users, and it fails Mueller’s “well-integrated…clear context” bar. Arbitrary category fill is the opposite of a relevance signal.

Exact-match anchor stuffing. Overcorrecting from generic anchors into ramming the identical keyword-rich phrase into every tile that points at a product. That’s an over-optimization signal, not a shortcut.

Cross-links that scramble the hierarchy. A product reachable only through other products’ widgets, never via its own category page. Technically linked, structurally orphaned — and it erodes the category-hierarchy signal Google relies on.

Set-and-forget staleness. Related-product links left pointing at out-of-stock, discontinued, or redirected items. The widget still looks fine on the page, so the 404s and redirect chains accumulate unnoticed.

Treating the sitemap as the fix. Assuming that because a deep product is in the XML sitemap, it doesn’t need on-page links. It gets indexed with almost no context — which is not the same as being crawlable, contextualized, and rankable.

Real-world module names and how to read them

Practitioners have catalogued the widget labels live ecommerce sites use — and every one of them is an internal-linking channel underneath the marketing copy:

• “People Also Viewed,” “People Also Bought” (Pottery Barn Kids)
• “Also in This Collection” (Pottery Barn)
• “Pairs Well With” (West Elm)
• “Frequently Bought Together” (Amazon’s well-known co-purchase module)

Reading them as an SEO auditor:

• A “Frequently Bought Together” block is your best-case module — it’s driven by co-purchase data, so the items are genuinely related and the anchor context is honest. Sam Underwood’s ecommerce product-page walkthrough describes exactly this: when viewing a product you “often see a ‘Frequently Bought Together’ section that shows you common products that others typically buy with the one you’re viewing.”
• A “Pairs Well With” or complementary block is the merchandiser/rules pairing — good if the rules are sane. Underwood’s fashion example: for a retailer like Reiss, “when viewing a blazer product, a complementary product would be recommending shirts and trousers.”
• A generic “Learn more”-style link on a collaboration or related page is the anti-pattern — Clark flags precisely this on West Elm as a spot where “a better anchor text implementation could be done.”

A steering example (commerce vs. SEO)

Say your rules engine, tuned for AOV, keeps recommending your three best-converting, high-margin bestsellers on every product page. Commercially sound — but those pages already have plenty of inbound links, and a low-margin, low-conversion product two levels deep in the catalog (the one nothing else links to) never appears in any module. That deep page is exactly the one that needs the crawl path and relevance signal. The fix isn’t to fight the rules engine on conversion — it’s to add a deliberate, smaller curated slot (or a rule) that seeds orphaned/deep products into the module so they get discovered, while the AOV-optimized picks keep doing their job.

Resources worth your time

My related writing

• Ecommerce SEO: A Beginner’s Guide — where product-to-product linking fits in the bigger ecommerce picture.
• Internal Links for SEO: An Actionable Guide — the general internal-linking framework, anchor-text variety, and the PageRank explainer that related-product modules apply.
• Product Page SEO: The Anatomy of a Well-Optimized Page — the PDP these modules live on; section 14 covers related products directly (“Displaying related products improves user experience and encourages clicks on other related products”).
• 14 Ways to Improve Ecommerce Product Pages for SEO — the most on-topic walkthrough of complementary vs. related vs. frequently-bought-together, and the case for linking revenue-critical products globally.
• Faceted Navigation: A Complete Guide — the adjacent crawl-budget concern when related URLs sprawl across parameters.

My speaking

• How Search Works (SlideShare) — my walkthrough of crawling, rendering, indexing, and ranking, which is the pipeline every internal link feeds. (My standing disclaimer applies: “This is my understanding of systems… not going to be 100% complete or accurate.”)

From around the industry

• Internal linking for ecommerce: The ultimate guide (Jon Clark, Search Engine Land) — the most directly on-topic top-ranking piece: real widget-name examples across live sites, the “flattening architecture” framing, and an anchor-text critique of a real “Learn more” implementation.
• SEOs on Google e-commerce category recommendation: ‘I’ll stop doing it when it stops working’ (Barry Schwartz, Search Engine Land) — Mueller on integration and the “keyword stuffing” line, plus the practitioner-pushback framing.
• John Mueller Recommends Pyramid Site Structure (Search Engine Journal) — the flat vs. pyramid quote that anchors the “supplement the hierarchy” argument.
• John Mueller Explains How Many Internal Links Is Best (iloveseo.com) — secondary paraphrase of the hangout where Mueller says dense ecommerce internal linking isn’t an issue as long as the structure stays recognizable (verify against the original video before quoting directly).
• SEO strategies for related categories, related items and related products widgets (Bloomreach Documentation) — the best concrete widget-implementation checklist: HTML not AJAX, server-rendered, visible on load, not hidden behind tabs, mobile URL parity (vendor docs, but the technical rules are sound).

Test yourself: Related Products & Internal Linking

Five quick questions on turning recommendation modules into an SEO asset. Pick an answer for each, then check.

Diagnose related-product linking failures

The module is visible but the crawler finds no links

Likely cause: product tiles use buttons, click handlers, or anchor elements without href, or the module appears only after an interaction. Fix: render descriptive <a href> links in the page output and confirm they remain present on mobile and after JavaScript runs.

Recommendations point through redirects or to errors

Likely cause: discontinued products remain in recommendation data, or the engine stores legacy URLs. Fix: crawl the extracted targets, update the product-ID-to-canonical-URL mapping, and remove chains rather than merely hiding broken tiles.

Related links reinforce only already-popular products

Likely cause: the recommendation engine optimizes solely for orders or clicks. Fix: preserve the commerce module, then add controlled eligibility or a separate curated layer for relevant deep and orphaned products without sacrificing shopper relevance.

Mobile pages expose fewer related links than desktop

Likely cause: the responsive template removes the module or requires a swipe/click before creating links. Fix: compare rendered link sets by viewport and make the crawlable destinations available in the mobile output used for indexing.

Extract and inspect recommendation links

Chrome DevTools Console: list links inside common modules

Run this in the Console on a product page. Adjust the selectors to match the site’s module; the snippet reports link text and resolved destinations.

const moduleSelectors = [
  '[data-related-products]',
  '[aria-label*="Related"]',
  '[aria-label*="You may also like"]',
  '.related-products'
];
const root = document.querySelector(moduleSelectors.join(','));
console.table(root ? [...root.querySelectorAll('a[href]')].map(a => ({
  text: (a.textContent || a.querySelector('img')?.alt || '').trim(),
  href: a.href
})) : []);

An empty result when the module is visibly populated is a reason to inspect click handlers, delayed rendering, and selector accuracy—not proof by itself that no crawlable links exist.

Screaming Frog XPath: extract product destinations

Use this as a Custom Extraction XPath after replacing the class with the store’s stable module selector:

//section[contains(concat(' ', normalize-space(@class), ' '), ' related-products ')]//a[@href]/@href

The expression selects href attributes from real anchors inside the related-products section. Prefer stable data attributes when the platform generates class names.

Regex: classify known recommendation-module labels

Use this case-insensitive expression against module headings or analytics labels:

(?i)\b(related products|you may also like|frequently bought together|customers also viewed)\b

The single capture group returns the recognized label so exports can be grouped by module type. This classifies supplied text; it does not discover links on its own.

Tools for related-product link QA

• Link Analyzer inspects a supplied page’s links and anchor text, which helps verify whether recommendation tiles are real descriptive anchors.
• Internal Link Cluster Visualizer analyzes a bounded supplied link graph to surface orphans, PageRank concentration, and possible missing links without pretending to crawl an unlimited site.
• HTTP Status Checker verifies the current response of extracted recommendation targets.
• Redirect Chain Mapper follows stale product destinations to reveal chains and final targets before recommendation data is updated.

Prove a related-products change works

Crawlable-link test

Test to run: extract module links from raw and rendered HTML with the Console/XPath methods above or the Link Analyzer. Expected result: intended product tiles expose real href destinations with descriptive product text or image alt text. Failure interpretation: JavaScript or markup creates an interaction without a crawlable link. Monitoring window: immediate on the released template. Rollback trigger: the release removes crawlable links from a previously working module or makes primary product interaction inaccessible.

Destination-health test

Test to run: check every extracted destination’s final status and canonical URL with the Redirect Chain Mapper. Expected result: links resolve directly to live, relevant product URLs under the documented stock policy. Failure interpretation: recommendation data contains retired IDs, legacy paths, or inconsistent canonical mappings. Monitoring window: immediate, then repeat after catalog retirement batches. Rollback trigger: a meaningful share of the released module routes shoppers to errors, loops, or irrelevant replacements.

Mobile parity test

Test to run: compare the rendered recommendation destinations and anchor text at representative mobile and desktop viewports. Expected result: both expose the intended crawlable set even if presentation differs. Failure interpretation: responsive logic suppresses or delays the mobile link graph. Monitoring window: immediate per template release. Rollback trigger: mobile loses important destinations or requires interaction before links exist.

Measure related-product linking over time

Healthy recommendation destinations

Metric: share of recommendation links that resolve directly to a live, canonical product URL under the store’s lifecycle policy. What it tells you: whether widgets accumulate broken links, chains, or retired targets. How to pull it: extract module links in a scheduled crawl and classify final response, canonical, and stock state. Benchmark / realistic range: use the first complete module crawl as a baseline and investigate any new errors or loops; acceptable unavailable-page handling follows the store’s documented policy. Cadence: weekly for volatile inventories and after retirement batches.

Catalog reach through related modules

Metric: products receiving at least one crawlable related-product link, segmented by category, depth, revenue priority, and orphan status. What it tells you: whether the module broadens discovery or repeatedly reinforces the same small set. How to pull it: build a source-target edge export and join it to the product catalog. Benchmark / realistic range: compare coverage with the intended eligible catalog; universal link counts would ignore category size and relevance. Cadence: monthly.

Recommendation-link engagement and organic discovery

Metric: module click-through and downstream conversion alongside Search Console impressions/clicks for products newly added to the internal-link graph. What it tells you: whether the linking layer remains useful to shoppers while improving product discovery. How to pull it: join module analytics events with a dated source-target change log and page-query data. Benchmark / realistic range: establish baselines by module type and category; “Frequently Bought Together” and curated rescue links serve different intents. Cadence: monthly with an annotated pre/post cohort.

Related Products & Internal Linking

Related-product modules — 'You May Also Like,' 'Frequently Bought Together,' 'Customers Also Viewed' — are on-page widgets that link one product or category page to others in the catalog. Each item is an internal link, so the same modules merchandisers build for cross-sell double as an SEO channel: they open crawl paths into deep catalog pages and pass relevance and PageRank between related products.

Related: Internal Link, Anchor Text, Product Page SEO, Category Page SEO

Related Products & Internal Linking

A related-products module — the widget you see labeled “Related Products,” “You May Also Like,” “Frequently Bought Together,” “Complementary Products,” or “Customers Also Viewed” — links from one product (or category) page to other products in the same catalog. Functionally, every item in the module is an internal link with an anchor, usually the product image plus its name.

Merchandising teams build these for conversion: cross-sell and upsell to raise average order value. But the same modules double as an SEO internal-linking mechanism, because they create crawl paths into deep catalog pages that primary navigation and category listings often can’t reach on their own, and they pass internal PageRank and relevance signal between related products. That gives the widget two competing purposes that live inside the same UI:

• Commerce-driven linking — chosen by a merchandiser or a rules engine (complementary items, basket-affinity / co-purchase data), optimized for conversion and order value.
• SEO-driven linking — deliberately linking to orphaned, deep, or thin-authority product pages with descriptive anchor text, so they get crawled, indexed, and passed relevance signal.

The SEO value is real but conditional. It only lands when the links are genuine crawlable <a href> elements (not JavaScript-only click handlers), use descriptive anchor text rather than “View” or “Learn more,” point to genuinely relevant products, and supplement — rather than replace — the site’s category hierarchy.

Related: Internal Link, Anchor Text, Product Page SEO, Category Page SEO

Changelog