Google chooses between these three display options based on whether structured, trustworthy hierarchy signals exist for the page: valid BreadcrumbList structured data drives the breadcrumb-style display when present and trusted, an algorithmically generated hierarchy (based on Google’s own understanding of the site’s URL structure and navigation) is used when the site’s architecture is clear enough for Google’s systems to infer a sensible path without explicit markup, and the plain green URL path is the fallback when neither condition is confidently met. Google documents the structured-data path directly; the exact internal logic governing when it prefers its own generated hierarchy over a flat URL, or vice versa, is not fully disclosed.
The structured-data path
Google’s Search Central documentation on breadcrumb structured data specifies that if you implement BreadcrumbList markup (via JSON-LD, microdata, or RDFa) correctly, Google may use it to build the breadcrumb trail shown in the snippet instead of displaying the raw URL. This is the most controllable of the three outcomes: you’re providing explicit, machine-readable hierarchy information, and Google’s snippet-generation system has a documented preference for using structured data when it’s valid and consistent with what a crawler independently observes about the page’s place in the site.
The word “may” matters here. Google does not guarantee that valid BreadcrumbList markup will always produce the breadcrumb display. It’s a strong signal, not a directive. Google’s systems still evaluate whether the markup is trustworthy: consistent with the actual site navigation, not contradicted by other signals, and not used in a way that looks manipulative (for example, breadcrumb markup that doesn’t match the visible on-page breadcrumb, which violates Google’s structured data guidelines and can cause the markup to be ignored entirely).
The algorithmically generated hierarchy
Even without any breadcrumb markup, Google can construct its own version of a hierarchy display by analyzing the site’s URL patterns, internal linking structure, and navigational architecture. This happens because Google’s systems crawl and model the relationships between pages on a site (parent categories, subcategories, and leaf pages) independent of any schema.org markup. When that inferred structure is clean and confident (a well-organized site with a logical URL taxonomy and consistent internal navigation), Google can choose to render its own generated path instead of a literal URL string or an explicit breadcrumb.
This is the least controllable of the three outcomes since there’s no direct implementation lever for it beyond having a genuinely clear, logical site architecture in the first place. It’s a byproduct of Google’s broader site-understanding systems rather than a discrete feature you turn on. Google has not published a specific algorithm or decision threshold for when it opts to generate its own hierarchy versus falling back to a raw URL.
The plain green URL path
When neither of the above conditions is confidently met, no valid breadcrumb structured data, or a site structure that isn’t clear enough for confident inference, Google falls back to displaying the literal URL path (or a truncated/formatted version of it) beneath the result title. This is the default, lowest-information display, and it’s what most pages without any structured markup and without a strongly legible URL hierarchy will show.
A messy or non-hierarchical URL structure (query-string-heavy URLs, flat structures with no folder logic, inconsistent patterns across templates) makes this fallback more likely regardless of whether breadcrumb markup exists elsewhere on the page, because the raw URL itself doesn’t give Google’s snippet system a clean hierarchy to render even algorithmically.
What isn’t publicly disclosed
Google documents the mechanics of the structured-data option clearly: implement valid BreadcrumbList markup, keep it consistent with the visible page, and it becomes eligible for use. What Google has not published is the precise decision logic for choosing between its own algorithmically generated hierarchy and a flat URL fallback when no breadcrumb markup exists, or the exact conditions under which Google might override valid breadcrumb markup in favor of its own generated version. This is a case where Google engineers (including John Mueller, in various Search Central discussions) have generally described snippet and breadcrumb display as an algorithmic decision made per-query and per-result, subject to change, rather than something webmasters can fully dictate, meaning even with correct implementation, no display option is guaranteed for every impression of the same URL.
Practical implication
The one lever you fully control is implementing valid, accurate BreadcrumbList structured data that matches your actual on-page navigation. That’s the documented path to eligibility for the breadcrumb display, and it’s worth doing correctly (matching visible breadcrumbs, using the correct hierarchy order, avoiding markup on pages where no real breadcrumb trail exists). Beyond that, maintaining a logical, consistent URL structure and internal linking pattern improves your odds of Google’s own hierarchy-generation system producing a clean result instead of falling back to a raw URL, even though this isn’t something you can directly implement the way you can implement schema markup.
What you can’t do is force Google to choose the breadcrumb display over its own generated hierarchy, or guarantee any one of the three outcomes will show consistently across all queries and devices for the same URL. Different queries, different result contexts (mobile vs desktop), and ongoing changes to Google’s snippet-rendering systems all mean the same page can display differently at different times. Implementing breadcrumb markup correctly is the highest-leverage action available; expecting full, predictable control over which of the three renders is not realistic given what Google has actually disclosed about the mechanism.
