“Google generally doesn’t look at the structure of URLs to work out the structure of a site. Instead, it analyzes the linkages between pages.” That sentence is from Google’s own documentation, and it contradicts a decade of advice about folder depth, clean hierarchies and the three-click rule.

What Google says it uses instead is links: “As a general rule, the more links a page has to it within a site, the higher the relative importance of the page to other pages on your site.”

So the architecture question is not what your URLs look like. It is what links to what, and whether anything links to the pages you care about, which is settled when a B2B site is planned around the handful of pages that have to bring in business rather than patched afterwards. Everything below follows from that, including the breadcrumb, which turns out to serve a different purpose from the one usually claimed for it.

What is asserted, and what is not

It is worth separating the documented claims from the folklore, because the folklore is more confident than the documentation.

Directories are about crawl frequency, and only above a size. “If you have more than a few thousand URLs on your site, how you organize your content may have effects on how Google crawls and indexes your site. Specifically, using directories (or folders) to group similar topics can help Google learn how often the URLs in individual directories change.”

The stated benefit is scheduling, not ranking. The worked example is a policies directory that seldom changes next to a promotions directory that changes often: “Google can learn this information and crawl the different directories at different frequencies.”

And reorganising is explicitly deprioritised. “Don’t drop everything and start reorganizing your site right now though … search engines will likely understand your pages as they are right now, regardless of how your site is organized.”

On click depth, the actual claim is weaker than the rule people quote. Google “can use information such as the number of links it needs to follow to reach a page and the number of links to a page to infer the relative importance of a page.” That is an inference about importance. It is not a threshold, and no number appears anywhere in the documentation.

Two things are worth stating as absences. No Google documentation sets a click-depth limit, and none says folder depth affects ranking. The term “orphan page” does not appear in Google’s documentation either; the equivalent published instruction is simpler.

And that instruction is the one to act on. “Every page you care about should have a link from at least one other page on your site.”

Documented statements about site structure compared with widely repeated rules that are not documentedSeparation of what search engine documentation actually asserts about site architecture from the rules commonly built on top of it which the documentation does not support. What is asserted is that the search engine generally does not look at the structure of uniform resource locators to work out the structure of a site, and instead analyzes the linkages between pages to gain insights about the relative importance of different pages, with the general rule that the more links a page has within a site the higher its relative importance relative to other pages. It is also asserted that grouping topically similar pages into directories can help the search engine learn how often addresses in individual directories change, with the worked example of a policies directory whose content seldom changes sitting alongside a promotions directory whose content changes often, allowing the two to be crawled at different frequencies. That directory advice is explicitly gated at sites having more than a few thousand addresses, and the documentation adds that a site owner should not drop everything and reorganise immediately, since search engines will likely understand the pages as they currently are regardless of how the site is organised. On reaching pages, the documented claim is that the engine can use information such as the number of links it needs to follow to reach a page, and the number of links to a page, to infer the relative importance of that page, which is an inference about importance rather than a threshold. What is not asserted anywhere in the documentation is any numeric click depth limit, any statement that folder depth affects ranking, any claim that a flat architecture ranks better, and the term orphan page, which does not appear in the documentation at all. The published instruction that replaces all of these is that every page the owner cares about should have a link from at least one other page on the site.Documented, and not documentedWhat Google statesIt analyzes “the linkages between pages”More internal links to a page implieshigher relative importanceDirectories help it learn how oftencontent changes, above a few thousand URLs”Every page you care about should have alink from at least one other page”What appears nowhereAny click-depth thresholdAny statement that folder depth affectsrankingAny claim that flat architecture ranks betterThe term “orphan page”, which is notGoogle’s vocabulary at allThe sentence that rewrites the rest”Google generally doesn’t look at the structure of URLs to work out the structure of a site.”And on rebuilding your hierarchy: “Don’t drop everything and start reorganizing your site right now though …search engines will likely understand your pages as they are right now.”
The documented claims are narrower and more conditional than the rules built on top of them. Source : Google Search Central, SEO Starter Guide and ecommerce site structure, updated 10 December 2025 (2025)

The breadcrumb does two jobs, and neither is the one usually claimed

Breadcrumbs are worth having. The reasons are specific, and one common justification for them is wrong.

What the markup produces. “Google Search uses breadcrumb markup in the body of a web page to categorize the information from the page in search results.” The feature “is available on desktop”, which is a limitation worth knowing before it is presented as a universal win.

And the guideline that contradicts standard practice. “We recommend providing breadcrumbs that represent a typical user path to a page, instead of mirroring the URL structure.”

Which means your breadcrumb is a navigation artefact, not a URL echo. If people reach a page from a category that is not in its URL path, that category is the correct breadcrumb.

The markup requirements are short. At least two list items. Each needs item, name and position, where “Position 1 signifies the beginning of the trail.” And a detail that saves an argument: “If the breadcrumb is the last item in the breadcrumb trail, item is not required.”

Multiple trails are permitted. “If there are multiple ways to navigate to a page on your site, you can specify multiple breadcrumb trails for a single page.”

Now the accessibility claim, which is usually overstated. Under WCAG, a breadcrumb is a sufficient technique for 2.4.8 Location, and 2.4.8 is Level AAA. The criterion reads: “Information about the user’s location within a set of web pages is available.”

It does not satisfy the AA criterion people cite. 2.4.5 Multiple Ways requires that “More than one way is available to locate a web page within a set of web pages”, and its sufficient techniques are a table of contents, a site map, a search function, links to related pages, and links from the home page. A breadcrumb is not on that list.

So the honest position. Breadcrumbs are endorsed by W3C as good practice and they help orientation, but no A or AA criterion requires them, and having one does not discharge Multiple Ways.

The functions of a breadcrumb trail and the accessibility conformance claim it does not supportThe functions a breadcrumb trail actually performs and the accessibility conformance claim commonly but wrongly attached to it. On the search side, breadcrumb markup in the body of a page is used by the search engine to categorize the information from the page in search results, so that users arriving from very different types of query see the content placed in the context of their query, though the feature is available on desktop rather than universally. The most consequential guideline is that breadcrumbs should represent a typical user path to a page instead of mirroring the address structure, which means the breadcrumb is a navigation artefact rather than an echo of the folder path, and that where people reach a page through a category absent from its address, that category is the correct breadcrumb to display. The markup requires at least two list items, each carrying an item property, a name property and a position property, with position one signifying the beginning of the trail, and with the item property not required on the final element since the address of the containing page is used instead. Multiple trails may be specified for a single page where multiple navigation paths exist. On the accessibility side, the relevant standard treats a breadcrumb trail as a sufficient technique for the criterion concerning location within a set of pages, which reads that information about the user’s location within a set of web pages is available, and which sits at conformance level triple A. It is not among the sufficient techniques for the double A criterion requiring that more than one way be available to locate a page, whose listed techniques comprise links to related pages, a table of contents, a site map, a search function, a list of links to all other pages, and linking to all pages from the home page. The honest position is therefore that breadcrumbs are endorsed as good practice and assist orientation, but that no single A or double A criterion requires them and possessing one does not discharge the multiple ways requirement.Two real jobs, one false claimJob 1: categorises the page in resultsMarkup is used “to categorize the informationfrom the page in search results.”Available on desktop. Not everywhere.Job 2: orients the readerA sufficient technique for the criterion onlocation within a set of pages.But only at Level AAA.The claim it does not support2.4.5 Multiple Ways, at AA, is satisfied by a table of contents, a site map, a search function, links to relatedpages, or links from the home page. A breadcrumb is not on that list.And the markup guideline most sites get backwards”Provide breadcrumbs that represent a typical user path to a page, instead of mirroring the URL structure.”Two list items minimum. Position 1 starts the trail. The last item needs no item property.
It categorises the page in results and orients the reader. It is only a AAA technique, and it does not satisfy Multiple Ways. Source : Google breadcrumb documentation and W3C WCAG 2.2 techniques G65 and 2.4.5 (2025)

Sitemaps, and when you do not need one

The documentation is unusually direct about this, and it saves small sites a piece of work they were told was mandatory.

The three conditions. “You might not need a sitemap if: Your site is ‘small’. By small, we mean about 500 pages or fewer on your site … Your site is comprehensively linked internally … You don’t have many media files (video, image) or news pages that you want to show in search results.”

With the reason. “If your site’s pages are properly linked, Google can usually discover most of your site.”

And the honest limit on what a sitemap buys you. “A sitemap helps search engines discover URLs on your site, but it doesn’t guarantee that all the items in your sitemap will be crawled and indexed.”

Two elements are wasted effort. “Google ignores <priority> and <changefreq> values.” The protocol itself says the same about priority: it “is not likely to influence the position of your URLs in a search engine’s result pages.”

One element is worth getting right. Google uses the last modified value “if it’s consistently and verifiably … accurate”, and defines what counts: “an update to the main content, the structured data, or links on the page is generally considered significant, however an update to the copyright date is not.”

And the hard limits, from the protocol. 50,000 URLs and 50MB uncompressed per file, all URLs from a single host, and each URL under 2,048 characters.

Crawl budget is not your problem

This is the topic most likely to consume a small site’s attention for no return, and the documentation opens by saying so.

The disqualifier is the first sentence. “If your site doesn’t have a large number of pages that change rapidly, or if your pages seem to be crawled the same day that they are published, you don’t need to read this guide.”

The stated audience. “Large sites (1 million+ unique pages) with content that changes moderately often (once a week)” or “Medium or larger sites (10,000+ unique pages) with very rapidly changing content (daily)”.

With the caveat that belongs beside the numbers. “The numbers given here are a rough estimate to help you classify your site. These are not exact thresholds.”

And two counter-intuitive instructions for anyone who does qualify. Do not use robots.txt to reallocate budget: “Google won’t shift this newly available crawl budget to other pages unless Google is already hitting your site’s crawl capacity limit.” And do not use noindex for the purpose, “as Google will still request, but then drop the page … wasting crawling time.”

What does create the problem, for a B2B site, is filters. Faceted navigation “based on URL parameters, can generate infinite URL spaces”, producing overcrawling and “slower discovery crawls”. If your site has filterable listings, that is where the attention belongs.

Published thresholds determining whether sitemap and crawl budget guidance applies to a siteThe published thresholds determining whether sitemap guidance and crawl budget guidance apply to a given site, both of which exclude the majority of business to business websites on the documentation’s own terms. On sitemaps, the documentation lists three conditions under which a sitemap may not be needed, being that the site is small, defined as about five hundred pages or fewer counting only pages the owner believes need to appear in search results, that the site is comprehensively linked internally meaning the crawler can find all important pages by following links from the home page, and that the site does not have many media files or news pages intended for search results. The stated reasoning is that where a site’s pages are properly linked the engine can usually discover most of the site. The documentation also limits what a sitemap achieves, stating that it helps search engines discover addresses but does not guarantee that all items in it will be crawled and indexed. Two sitemap elements are stated to be ignored entirely, namely the priority value and the change frequency value, while the last modified value is used where consistently and verifiably accurate, with an update to main content, structured data or links counting as significant and an update to a copyright date not counting. Protocol limits are fifty thousand addresses and fifty megabytes uncompressed per file, all addresses from a single host, and each address under two thousand and forty eight characters. On crawl budget, the guidance opens by stating that a site whose pages do not change rapidly, or whose pages appear to be crawled the same day they are published, does not need to read the guide. Its stated audience is large sites of over one million unique pages changing about weekly, or medium and larger sites of over ten thousand unique pages changing daily, accompanied by the caveat that these numbers are a rough estimate for classification rather than exact thresholds.Two things most B2B sites can skipYou might not need a sitemap ifAbout 500 pages or fewerComprehensively linked internallyFew media files or news pagesAll three, per the documentation’s own wording.Crawl budget applies to1 million+ pages changing weeklyOr 10,000+ pages changing dailyOr many URLs stuck at “discovered,currently not indexed""The numbers given here are a rough estimate to help you classify your site. These are not exact thresholds.”And the opening line: if your pages are crawled the same day they are published, “you don’t need to read this guide.”What does create the problem, on a B2B siteFilterable listings. Faceted navigation on URL parameters “can generate infinite URL spaces”, producingovercrawling and “slower discovery crawls”. That is where the attention belongs.
Two pieces of published advice that most B2B sites can skip, on the documentation's own terms. Source : Google Search Central, sitemaps overview and crawl budget guide (2026)
Recent changes to structured data features and the guarantee that structured data has never carriedRecent changes to search structured data features together with the limitation that has always applied to structured data generally. The sitelinks search box feature has been removed, its documentation withdrawn in November 2024 with the changelog recording that the feature is no longer available in search results and that the associated exclusion rule was archived, meaning any recommendation to implement website markup carrying a search action for that purpose is obsolete. Website markup nevertheless retains a current use, being the principal means of indicating a preference for the site name shown alongside results, requiring two properties, a name and a uniform resource locator, placed on the home page only, with the engine supporting one site name per domain or subdomain and not supporting site names at subdirectory level, and with the further instruction that where website structured data already exists on a site the name properties should be nested in the same node rather than duplicated in an additional block. Organization markup carries no required properties whatsoever, the documentation instead recommending the addition of as many properties as are relevant, with a suggested focus on the name or alternate name of the business, an indication of real world presence such as an address or telephone number, and an indication of online presence such as a website address or logo, the logo image being required to be at least one hundred and twelve pixels square and to be crawlable and indexable. The overarching limitation is that the search engine does not guarantee that structured data will show up in search results even where a page is marked up correctly according to the testing tool, since using structured data enables a feature to be present rather than guaranteeing that it will be. A related clarification is that a structured data manual action causes a page to lose eligibility for appearance as a rich result but does not affect how that page ranks in web search. A further deprecation is that the frequently asked questions rich result will no longer appear in search results from the seventh of May 2026.What changed, and what was never promisedRemoved, November 2024: the sitelinks search box”The sitelinks search box feature is no longer available in Google Search results.” The documentation is gone.Still useful: WebSite markupNow the lever on the site name shown inresults. Two properties, home page only,one name per domain.Organization: nothing is required”There are no required properties.” Add name,a real-world presence such as address, and anonline one such as url or logo.And the guarantee that has never existed”Google does not guarantee that your structured data will show up in search results, even if your page is marked up correctly.”A structured data manual action “means that a page loses eligibility for appearance as a rich result; it doesn’t affecthow the page ranks in Google web search.” And the FAQ rich result stops appearing on 7 May 2026.
One feature removed, one deprecation coming, and a guarantee that has never existed. Source : Google Search Central changelog, site names and structured data policies (2026)

Two markup changes worth knowing

Structured data guidance moves, and two changes affect what is worth implementing.

The sitelinks search box is gone. Google removed the documentation in November 2024, recording the reason plainly: “The sitelinks search box feature is no longer available in Google Search results.” Any advice to add WebSite markup with a search action for that purpose is out of date.

But WebSite markup still has a use. It is now the main lever on the site name shown in results: “To indicate your site name preference, add WebSite structured data to your home page.” Two required properties, name and url, on the home page only, one name per domain or subdomain.

Organization markup has no required properties at all. “There are no required properties; instead, we recommend adding as many properties that are relevant to your organization”, with the suggestion to focus on name, an indication of real-world presence such as address or telephone, and online presence such as url or logo.

And the sentence that should temper every structured data project. “Google does not guarantee that your structured data will show up in search results, even if your page is marked up correctly according to the Rich Results Test.”

With a useful clarification about consequences. A structured data manual action “means that a page loses eligibility for appearance as a rich result; it doesn’t affect how the page ranks in Google web search.”

One further deprecation to note if you have it. The FAQ rich result is being withdrawn, no longer appearing in results from 7 May 2026.

Published recommendations on uniform resource locator structure and the reasons given for eachThe published recommendations on uniform resource locator structure and the stated reason accompanying each, none of which is ranking. The framing of the whole document is crawl efficiency, stating that a crawlable structure meeting the listed requirements is needed to ensure the site can be crawled effectively, and that addresses failing to meet the criteria will likely result in the site being crawled inefficiently, including but not limited to extremely high crawl rates, or not at all. On readable words, the recommendation is to use readable words rather than long identification numbers where possible, with the illustrative contrast between an address ending in a topic word and one ending in a query string containing a numeric topic parameter and a long hexadecimal identifier. On word separators, the recommendation is to separate words using hyphens rather than underscores, with the stated reason being that hyphens help users and search engines better identify concepts in the address, and that underscores are not recommended for historical reasons since that character is already commonly used to denote concepts that should be kept together, for example by programming languages naming functions. On parameters, the recommendation is to use an equals sign to separate key and value pairs and an ampersand to add further parameters, and to shorten addresses by trimming parameters that do not change the content. On letter case, the documentation does not simply recommend lowercase but states that address handling is case sensitive so that two addresses differing only in case are distinct addresses with their own content, and that where a server treats them identically all text should be converted to the same case so the engine can more easily determine that the addresses reference the same page. On complexity, overly complex addresses containing multiple parameters can create unnecessarily high numbers of addresses pointing to identical or similar content, consuming more bandwidth than necessary or preventing complete indexing. On fragments, they should not be used to change page content since fragments are generally not supported.URLs, and the reason behind each ruleRecommendationThe stated reasonReadable words, not ID numbersHuman comprehensionHyphens, not underscoresUnderscores already denote “kept together”Trim parameters that change nothingFewer duplicate URLs to crawlConsistent letter caseURLs are case sensitive; /APPLE and /apple differNo fragments to change contentFragments are generally not supportedThe document’s own framing is crawl efficiency: addresses that fail these criteria mean the site is crawled”inefficiently, including but not limited to extremely high crawl rates, or not at all.” Ranking is not mentioned.
The stated reason for each recommendation is crawl efficiency or human readability. Ranking is not among them. Source : Google Search Central, URL structure best practices, updated 10 December 2025 (2025)

What to do with this

Start with the instruction that is actually binding: every page you care about should have a link from at least one other page. Export your page list, compare it against your internal links, and fix the gaps. That is worth more than any restructure.

Add breadcrumbs, and build them from how people actually reach the page rather than from the folder path. Mark them up with at least two items and correct positions, and know that the accessibility benefit is real but sits at AAA.

Check the two thresholds before spending anything on sitemaps or crawl budget. Under 500 well-linked pages, one of those jobs is optional and the other does not apply to you.

And if your site has filters that generate URL parameters, look there. That is the one architecture problem a mid-sized B2B site genuinely creates for itself.

The related pieces are what a B2B homepage has to do and B2B website usability that is testable.