URL Structure for SEO: What Google Documents and What It Does Not

A URL structure is the set of rules a site follows when it turns a page into an address: which host the page sits on, how deep the path runs, what the slug says, and which parameters are allowed to appear. This is written for the person choosing that scheme during a build or a replatform, and for the person looking at a live site wondering whether the URLs are worth changing at all. Google publishes one page on the subject. It contains three hard requirements, seven best practices, and no ranking claim of any kind. Several instructions that circulate as settled URL practice are absent from it, including one that appears verbatim on a page currently ranking on page one for this query. What follows quotes that page, separates what it requires from what it merely suggests, and gives you a three-test procedure for deciding whether an existing URL earns the cost of a redirect.

The short version

• Google's URL structure documentation makes no ranking claim at all. Every problem it describes is a crawling or indexing problem, so any claim that URLs move rankings needs a different source.
• That page separates three requirements from seven best practices. Only the first three are written as conditions a crawlable URL has to meet.
• Google Search treats /APPLE and /apple as distinct URLs with their own content. Case is not cosmetic.
• For multi-regional sites, that page labels both a country-specific domain and a gTLD subdirectory "Recommended" and states no preference between them.
• On a live site, only two things justify changing a URL: it blocks crawling or indexing, or it splits signals across duplicate addresses. Ugly is not one of them.

What is a URL structure, and which parts are decisions?

Five parts, and on most sites you genuinely design two of them. Split a real address and the roles separate cleanly: https://example.com/docs/billing/invoices?tab=history#totals.

The host row is a separate question from the one this piece answers. Whether a section belongs on a subdomain or a subdirectory is settled on its own merits before you design a single path.

The fragment row carries a constraint worth knowing before an engineer builds around it. Google is direct about it: "Don't use fragments to change the content of a page, as Google Search generally doesn't support URL fragments." If a view only exists after the #, treat it as a view that does not exist in search.

What does Google actually require, and what does it only recommend?

Three requirements and seven best practices, and Google's URL structure documentation keeps them in separate sections. The distinction matters, because the requirements are framed as conditions: "To make sure Google Search can crawl your site effectively, use a crawlable URL structure that meets the following requirements."

The three requirements:

• Follow the standard: "Google Search supports URLs as defined by IETF STD 66. Characters defined by the standard as reserved must be percent encoded."
• Do not use fragments to change content: Google says it generally does not support URL fragments, so anything that exists only after the # is content you cannot rely on Search seeing.
• Use conventional parameter encoding: an equal sign to separate key and value, an ampersand to add another pair. Google's "not recommended" examples are bracket and double-comma schemes, which is a real warning to anyone hand-rolling a filter syntax.

The seven best practices are softer, and the sentence that introduces them hedges the whole set: "we recommend creating a simple URL structure, applying the following best practices when possible." They are: descriptive words instead of ID numbers, words in your audience's language, percent encoding in href attributes, hyphens rather than underscores, as few parameters as you can manage, awareness that URLs are case sensitive, and a geotargetable structure for multi-regional sites.

Two of those are directly actionable. "When possible, use readable words rather than long ID numbers in your URLs" rules out the ?id=4471 pattern that older CMS platforms still produce. "Whenever possible, shorten URLs by trimming unnecessary parameters (meaning, parameters that don't change the content)" is worth reading twice: the test is whether the parameter changes the content, not whether it looks untidy.

Which URL rules does the field assert that Google does not?

Several, and the gap is wide enough to be worth tabulating. The left column below collects instructions that circulate as settled URL practice; one of them, "hide the www prefix", appears verbatim as a best practice on a page currently ranking on page one for this query, with no source attached to it. The right column is what Google's URL structure documentation actually contains.

One honest caveat, because the table is easy to over-read: absence from this page does not make an instruction wrong. Google has written about several of these subjects elsewhere, and a shop can have a perfectly good reason for a trailing-slash convention. What the table shows is narrower and more useful. Each of those instructions needs its own source, and if the only support anyone offers is "Google says so", the support does not exist.

The multi-regional row is the one most likely to change a decision, because the assumed preference points the opposite way to the source. That choice belongs with the rest of the geotargeting question, which our guide to multi-regional URL structures works through alongside hreflang.

Do hyphens or underscores matter in a URL?

Hyphens, and this is one of the few URL recommendations Google bothers to explain. The documentation reads: "we recommend using hyphens (-) instead of underscores (_) to separate words in your URLs, as it helps users and search engines better identify concepts in the URL."

The reason it gives is historical rather than algorithmic: "For historical reasons, we don't recommend using underscores, as this style is already commonly used for denoting concepts that should be kept together, for example, by various programming languages to name functions (such as format_date)." An underscore is a joiner. A hyphen is a separator.

When this does not matter: on a live site with underscored URLs that are already indexed and ranking. The recommendation is worth applying to every new URL you create and almost never worth a site-wide rename on its own. That is the decision procedure further down, and word separators do not clear its bar.

Are URLs case sensitive for Google?

Yes, and the documentation states it without hedging: "Like any other HTTP client following IETF STD 66, Google Search's URL handling is case sensitive (for example, Google treats both /APPLE and /apple as distinct URLs with their own content)."

The practical consequence is duplication you cannot see in a sitemap. If your server happily returns the same page at /pricing, /Pricing and /PRICING, those are three addresses competing for one page's signals, and links from elsewhere will scatter across all three.

Google's own fix is a server-level one: "If upper and lower case text in a URL is treated the same by your web server, convert all text to the same case so it's easier for Google to determine that URLs reference the same page." Normalize to lowercase at the edge, redirect the variants, and make lowercase the rule your framework enforces rather than a thing reviewers catch. Where a redirect is not available to you, a canonical tag is the alternative, and our guide to how canonicals consolidate duplicate URLs covers when each one is appropriate.

How do URL parameters cause SEO problems?

By multiplication, not by existing. Parameters are not inherently a problem; an unbounded number of parameter combinations is. Google describes the mechanism plainly: "Overly complex URLs, especially those containing multiple parameters, can cause problems for crawlers by creating unnecessarily high numbers of URLs that point to identical or similar content on your site."

The examples it gives are worth recognizing, because they show up on software sites in slightly different clothes:

• Additive filters: every combination of filters generates its own address, and the count explodes combinatorially rather than linearly.
• Irrelevant parameters: referral tags, sort orders and session IDs that change the address without changing the page.
• Calendars: a date picker with no start or end bound will generate links forever.
• Broken relative links: parent-relative href values on the wrong template, producing paths that nest into each other indefinitely.

The instruction attached to this is the trimming rule quoted earlier, and the test in it is exact: a parameter earns its place if it changes the content. A tracking tag does not. At scale, on templates where filtering is the product, the handling gets more involved than "trim it", and our guide to parameters on faceted templates is where that case belongs.

How deep should a URL path be?

Google's URL structure documentation gives no depth rule, so the honest answer is that folder count is the wrong thing to optimize. That page contains no maximum, no recommended number of segments and no mention of depth at all. What it asks for instead is legibility: "Consider organizing your content so that URLs are constructed logically and in a manner that is most intelligible to humans."

What actually causes trouble is URL count, not nesting. A page four levels down that is linked from a navigation element is reachable. A page two levels down that nothing links to is not, and shortening its path will not change that. Depth is a symptom worth reading, not a number worth hitting. A section that needs five segments to describe itself is telling you something about the information architecture underneath it, and the URL is only where it became visible.

The useful version of the rule: every segment in a path should be a category a user would recognize and that has, or could have, a page of its own. /docs/billing/invoices passes. /resources/content/2026/q3/final/billing does not, and the fix is the structure rather than the string.

Should you change the URLs on a site that is already live?

Usually not, and three tests in order will tell you. Run them from the top and stop at the first yes.

From my experience working on migrations, the redirect is rarely the expensive part of a URL change, which is why the cost gets underestimated in planning. Google says as much about the equity question: its guidance on moving a site with URL changes states that "301 and other permanent redirects don't cause a loss in PageRank."

The cost is elsewhere, and it is mostly time and maintenance. The same page tells you to "expect temporary fluctuation in site ranking during the move", and that "for medium-sized websites, it can take a few weeks or more for Google to gradually start showing the new URLs instead of the old ones (and for larger sites, even longer)". After that you own a redirect map permanently, every external link now points one hop away from the destination, and every place the old URL was pasted into a document or a support macro is now someone else's problem. Test 3 never covers that bill. Tests 1 and 2 usually do, because they are recovering pages rather than tidying strings.

When a change does clear the bar, execution becomes its own discipline with its own failure modes, and the sequence for running a URL change safely is worth following in full.

What does a good URL scheme look like for a B2B SaaS site?

Predictable, shallow, and decided before the first page ships. Divide the site into four territories and name the rule for each one once, rather than deciding page by page.

• Marketing pages: single segment at the root. /pricing, /security, /integrations/slack. These change least and earn the most links, so they should be the URLs you never touch again.
• Blog: one flat level. /blog/url-structure-seo, with no dates and no category segment, because categories get renamed and dates make evergreen posts look stale.
• Docs: nested by product concept, not by team. /docs/billing/invoices rather than /docs/v2/platform-team/billing.
• The application: a separate host, almost always, because the pages behind a login have nothing to offer search and everything to gain from being deployed independently.

In our implementation work, the boundary that causes the most trouble later is the one between the marketing site and the documentation, because both want to own the same explanatory pages and neither wants to redirect. Decide which one owns "what is X" content before either team writes it, and the URL question answers itself.

The rule to write down: lowercase, hyphens, no dates, no stop words, no file extensions, and no segment that names something internal. Put it in the engineering README rather than a marketing document, because the framework is where it will actually be enforced.

Decide the scheme once, at build time. Write it down as a rule someone else can apply without asking you, then leave the URLs alone. A site that keeps renaming URLs does not end up with better URLs; it ends up with a redirect map and a team that never made the decision.

This week, take the ten pages you would least like to lose and request each one with the path in a different case. If /pricing and /Pricing both return 200 with the same content, you have two addresses for one page, and that is the kind of URL problem worth fixing while it is still small.