WordPress Breadcrumbs Setup

Breadcrumbs are small furniture with three jobs — orienting readers in the site's hierarchy, feeding crawlers a machine-readable structure map, and replacing the raw URL in your SERP listing with a readable trail — and WordPress setup is a fifteen-minute task with one recurring complication: the markup comes from one place, the rendering from another, and sites regularly configure half. Here's the complete setup, the display decisions, and the verification that both halves work.

The two halves

Half one — the data and markup: your SEO plugin generates the trail logic and emits BreadcrumbList JSON-LD — Yoast and Rank Math both do this once breadcrumbs are enabled in settings, including the structure decisions: the Home anchor's label, taxonomy paths for posts (which category chains into the trail — set the primary category deliberately on multi-category posts), and prefix/separator cosmetics. Half two — the rendering: the trail must actually appear on pages, via whichever your stack supports: the plugin's block/widget (block themes place it in templates via the site editor), a theme integration (many quality themes auto-render the SEO plugin's breadcrumbs when detected — check the theme's docs first; it's the zero-code path), or the classic one-line template tag in header/single templates (child-theme edit, the developer path). The recurring half-config: markup enabled, rendering never placed — schema describing a trail users can't see, which drifts against the visible-content rule.

The display decisions

1. Trail shape mirrors the real hierarchy: Home → Category → Post for blogs (the primary-category choice matters on multi-category posts — pick the canonical home per the taxonomy doctrine); Home → Category → Subcategory → Product for stores, where breadcrumbs earn their keep hardest, per the structure rules.
2. Placement: top of content, above the H1, small and unobtrusive — orientation furniture, not navigation chrome; mobile included (truncation patterns beat hiding entirely).
3. Don't breadcrumb the homepage, and keep the current page as unlinked text — conventions both plugins default correctly.

Verification and payoff

The both-halves check: view a post — trail visible; view-source — one BreadcrumbList block (the one-emitter rule: themes with native breadcrumb schema plus the plugin's is the classic duplicate — disable one); Rich Results Test — valid; then Search Console's breadcrumbs enhancement report as the standing monitor. The payoff arrives quietly: SERP listings showing the trail instead of the raw URL (a modest readability-and-trust lift on every impression), the upward link path on every deep page (equity and crawl routing per the standard physics), and the structure legibility that feeds everything from sitelinks to the site's hierarchy understanding.

Frequently asked questions

Do breadcrumbs meaningfully affect rankings?

Individually marginal, structurally worthwhile: the internal-link contribution is real-but-small (nav-level, per the widget-vs-prose ranking), the SERP display is a standing micro-CTR win, and the structure clarity compounds with everything else architectural. Fifteen minutes for permanent small dividends is the trade — the definition of furniture worth installing.

Should breadcrumbs show on pages (not just posts)?

Where pages have hierarchy (parent → child), yes — the trail mirrors it automatically; on flat top-level pages the one-item trail adds nothing and can be suppressed. Stores: everywhere, always — product depth is what breadcrumbs were born for.

My theme has breadcrumbs built in — theme's or plugin's?

Whichever renders and marks up correctly, once — test the theme's version first (visible trail + valid BreadcrumbList = keep it, disable the plugin's); themes that render without schema or emit legacy microdata lose to the plugin's implementation. One system, both halves, then back to the work that ranks: content and authority (our trail).