Breadcrumbs for product pages: add, mark up and test

Make breadcrumbs visible and machine-readable so customers (and crawlers) can see where a product sits. Use your theme or core block first, then add a matching BreadcrumbList JSON‑LD only if needed and test with Google's tools.

Editorial illustration: a product-page browser card showing a breadcrumb trail paired with overlapping checklist and JSON‑LD cards on a pale mint background.

Start with this rule of thumb: use the breadcrumb feature your theme or the WordPress core Breadcrumbs block provides. If your theme doesn’t output a usable trail, add a BreadcrumbList JSON‑LD that exactly matches the visible links — and then test both the visible trail and the structured data.

In this guide

Choose the simplest route

Why start here: changing a theme template or adding code is riskier than a settings change. If your theme or a plugin already outputs breadcrumbs, prefer that because it keeps the visible trail and any structured data in one place.

  • WordPress includes a core Breadcrumbs block you can add to appropriate templates; check whether your theme exposes a block area for it first. See the Core Blocks theme reference for guidance on using core blocks in themes: WordPress core blocks (theme guidance).
  • WooCommerce themes commonly provide their own breadcrumb output and supply hooks/filters for safe changes. If you need to customise the breadcrumb text or placement, follow the official WooCommerce developer guidance rather than editing core or parent theme files: WooCommerce breadcrumb customisation.

Render and structure the visible trail

Visible breadcrumbs must be links in logical order (from the broadest to the most specific) and placed inside a semantic navigation region: <nav aria-label=”Breadcrumbs”> with a list inside. This helps both keyboard and assistive‑technology users. The W3C’s WCAG technique explains this pattern: WCAG G65 — Breadcrumbs technique.

Practical checks to do now on any product page:

  • Open a product page and confirm the trail reads something like Home > Category > Subcategory > Product.
  • Click each crumb and confirm it opens the expected category or listing URL.
  • The current page (product) should be visible but not a link, and marked for assistive tech (see aria-current below).

Add BreadcrumbList JSON‑LD (example)

Only add JSON‑LD if your theme/plugin does not already emit structured breadcrumbs or if the emitted markup does not match the visible trail. The structured data must mirror what the visitor sees — don’t add invisible crumbs purely for indexing hopes. Google documents the required structure and fields for BreadcrumbList (itemListElement → ListItem with position, name and item): Google Search Central — Breadcrumb structured data. The canonical schema is the BreadcrumbList entry on schema.org: schema.org/BreadcrumbList.

Copy-and-edit this minimal example so the name and item values match your visible trail exactly. Place the JSON‑LD in the page body (preferably where your theme outputs other JSON‑LD), not in the head if your tooling rules otherwise — follow your theme/plugin docs where they differ.

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Home",
      "item": "https://example.com/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Kitchen",
      "item": "https://example.com/kitchen/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "Teapots",
      "item": "https://example.com/kitchen/teapots/"
    },
    {
      "@type": "ListItem",
      "position": 4,
      "name": "Earl Grey Teapot",
      "item": "https://example.com/kitchen/teapots/earl-grey"
    }
  ]
}

Notes on the example:

  • position must be a sequential integer starting at 1 and match the visible order.
  • name is the visible crumb text and must match what users see.
  • item is the URL of that crumb; for the current page some authors include the page URL as the last item, and Google accepts it — but ensure that the visible trail and the JSON‑LD agree exactly. For field definitions and examples see schema.org BreadcrumbList and Google’s Breadcrumb guidance.

Make these accessible and programmatically visible:

  • Wrap the trail in <nav aria-label=”Breadcrumbs”> and use an ordered or unordered list. This is the pattern recommended in WCAG G65.
  • Ensure the current page in the visible trail is not a link and has aria-current=”page” set, for example <li aria-current=”page”>Earl Grey Teapot</li> so screen readers announce it as the present page.
  • Do not use rel=”nofollow” on internal breadcrumb links; they should behave like normal navigational links so crawlers and users can follow the hierarchy.

Test and verify

Make these checks on 3 representative product pages (a popular product, a deeply nested product, and a recently added product):

  1. Visible-check: Confirm each crumb links to the right page and the current item is marked with aria-current=”page”.
  2. Source-check: View page source (or use the browser inspector) and find the JSON‑LD or microdata. Confirm the name, item and position values match the visible trail exactly.
  3. Structured-data test: Paste the product URL into Google’s testing guidance tools. Google’s Breadcrumb doc describes eligibility and testing; use the Rich Results Test or URL Inspection in Search Console where appropriate: Google Search Central — Breadcrumb structured data. (Remember: the tool shows whether Google can read your markup; it does not guarantee the breadcrumb will appear in search results.)
  4. Search Console URL Inspection: After publishing, use Search Console’s URL Inspection to request indexing and check for structured‑data crawl errors. See Google’s guidance for using Search Console to inspect indexing: WordPress core blocks page (for block placement) and Google’s structured-data guidance for the testing expectations.

Record any mismatch (for example: visible crumb says “Teapots” but JSON‑LD name is “Tea Pots”) and correct it. A mismatch is a common reason structured-data validators flag inconsistency.

Fictional example (illustrative)

Imagine a shop product at /kitchen/teapots/earl-grey. The visible breadcrumb reads Home > Kitchen > Teapots > Earl Grey Teapot. The theme did not emit JSON‑LD, so the owner added the JSON‑LD example above, replacing example.com with their domain and the exact visible names. They then ran the structured-data test and fixed a mismatch where the theme used “Teapots” but the product template output “Tea Pots” (space vs no space). After aligning terms, the validator showed no errors for the breadcrumb object. This is illustrative — run the same checks on your site to verify your results.

Quick rollout checklist

  • Decide approach: theme/block first; JSON‑LD only if needed (use WordPress or WooCommerce docs above).
  • Implement on a staging copy or a single product page first.
  • Confirm visible links, aria-current and list structure (WCAG G65).
  • Confirm source JSON‑LD (if used) matches visible trail exactly (position/name/item).
  • Run Google’s Rich Results Test / use Search Console URL Inspection and correct any validator warnings.
  • Deploy site-wide only after the sample pages validate without mismatch.

Related published guides you may find useful: Validate product structured data with Google’s Rich Results Test and URL Inspection and Add the product structured data search engines expect (WooCommerce).

Make one clear decision: either enable and position the theme/block breadcrumb so it shows the correct trail, or add JSON‑LD that mirrors the visible trail. Then test the three checks above on three product pages and fix any mismatches before rolling out site‑wide. That gives you a verifiable breadcrumb implementation without relying on search engines to change how results appear.