URL Structure: The Small Decisions That Compound Over Time
Most URL structure decisions get made in the first week of building a website, often by whoever happened to set up the CMS. Once Google has crawled and indexed a few hundred URLs in that pattern, once other sites have linked to those exact addresses, once customers have bookmarked them, the pattern is no longer a preference. It is the site's permanent address book.
That is the argument for getting it right before you publish rather than after. None of the decisions below will make or break a single page's ranking. All four compound in the background for as long as the site exists.
Quick Navigation
- Folder Depth and Category Structure
- Dates in Blog Post URLs: A Choice That's Hard to Undo
- Hyphens vs Underscores: What Google Actually Prefers
- Trailing Slashes and Staying Consistent
- Keeping URLs Readable and Reasonably Short
- What to Do If Your URLs Are Already a Mess
- Frequently Asked Questions
Folder Depth and Category Structure
Google's own URL structure documentation does not specify a maximum number of folder levels. What it asks for instead is a URL "constructed logically and in a manner that is most intelligible to humans." There is no official rule that says three folders deep is fine and five is not.
That leaves two practical decisions for you to make, and they are different questions.
The first is depth: how many /folder/folder/folder/ levels sit between your domain and the page. A flat structure (yourdomain.com/page-slug) is simple and easy to reorganize later. A nested structure (yourdomain.com/services/plumbing/water-heater-repair) can help humans and crawlers understand where a page sits in your site's topic hierarchy, particularly on large sites with hundreds of pages across distinct categories.
The second is whether to put a category name in the path at all — yourdomain.com/blog/post-slug versus yourdomain.com/post-slug. This decision matters more than folder count, because a category name is content, and content changes. Rename "Blog" to "Insights" two years in, or split "Services" into "Residential" and "Commercial," and every URL carrying that category name changes with it. A flat structure sidesteps the problem entirely: this blog uses /blog/post-slug, one folder deep, with no sub-category in the path, so reorganizing the topic taxonomy never touches a single published URL.
If your site is small — a handful of service pages, a blog, a contact page — default to shallow and flat. Reserve nested categories for sites where the number of pages genuinely requires a browsable hierarchy, and where the categories themselves are stable enough that you are not likely to rename them in a year.
Dates in Blog Post URLs: A Choice That's Hard to Undo
A URL like /blog/2022/03/five-tips-for-x carries a piece of information you can never update on the sly: the year you published it. A reader scanning search results treats that date as a shelf-life label, even after you have rewritten the content in 2026 to reflect current information.
News and evergreen content have opposite needs here. A news site benefits from dated URLs — the date is part of the story, and archiving by publish date genuinely helps readers browse the timeline. A small business blog post about "how to fix a running toilet" or "how to choose a GSC property type" is not time-stamped content. It answers the same question in three years that it answers today, provided you keep it updated.
Google has not published guidance stating that a date in a URL directly lowers rankings. The practical cost is different: a dated URL discourages you from treating the content as evergreen, because updating a post without updating the date it announces feels dishonest, and updating the date means either leaving a stale year in the URL or migrating the URL and managing the resulting redirect. Undated URLs remove that tension. You can refresh a post's content indefinitely without the address ever looking out of step with what is inside it.
The fix is simple if you have not published yet: leave the date out of the URL path. Put it in the frontmatter, the byline, or the sidebar instead, where it can be visible to readers without being baked into the address.
Hyphens vs Underscores: What Google Actually Prefers
Google's Search Central documentation is explicit on this point: "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 reasoning Google gives is about parsing, not aesthetics. A hyphen reads as a space, so water-heater-repair parses as three separate words: water, heater, repair. An underscore does not reliably split the same way — Google notes underscores are already used in programming to join words into a single token, as in water_heater_repair, which search engines are more likely to read as one long string than three distinct concepts.
This is one of the few URL structure questions with a direct, sourced answer from Google itself rather than industry convention. If your CMS defaults to underscores or spaces-as-plus-signs, change the setting before you publish your first hundred posts. Retrofitting hyphens later means every existing URL needs a redirect to the new hyphenated version, for no ranking gain beyond restoring what a correct setup would have given you from day one.
Trailing Slashes and Staying Consistent
A trailing slash is not cosmetic. yourdomain.com/about and yourdomain.com/about/ can be crawled and indexed as two distinct URLs, even when they render identical content, because the two strings are not the same address as far as a crawler is concerned. This is the same duplicate-URL mechanism covered in our guide to HTTPS, WWW, and trailing slash issues — that post walks through diagnosing and fixing it after the fact. Here, the point is simpler: decide the convention before launch, so you never generate the problem in the first place.
Pick one format, either always with a trailing slash or never, and configure your CMS or framework to enforce it. Most modern web frameworks default to no trailing slash on individual pages. Whichever you choose, apply it everywhere: internal links, your sitemap, canonical tags, and any URLs you paste into outreach emails or social posts. A site that is 95% consistent still has the 5% generating duplicate URLs Google has to sort out on its own.
Keeping URLs Readable and Reasonably Short
Google's guidance favors readable words over long identifiers: "Use readable words rather than long ID numbers in your URLs," and trim "unnecessary parameters (meaning, parameters that don't change the content)."
In practice this means two things for a small business site. First, avoid your CMS's default of auto-generated numeric or hash-based slugs — yourdomain.com/page?id=4471 tells a reader nothing, while yourdomain.com/water-heater-repair tells them exactly what they will find. Second, resist stuffing every possible keyword into the slug. A URL like /best-affordable-emergency-24-hour-water-heater-repair-services-near-me is not more informative than /water-heater-repair. It just takes longer to read and is easy to mistype from memory. Pick the two or three words that describe the page and stop.
The same logic applies to URL parameters. Tracking parameters and session IDs that do not change the content of the page (?utm_source= links excepted, since those serve a real analytics purpose) should not become part of a page's canonical, indexed address. If your platform generates parameter-heavy URLs for filtered or sorted views of the same content, a canonical tag pointing back to the clean version keeps the parameter clutter from being treated as separate pages.
What to Do If Your URLs Are Already a Mess
If your site has been live for a while and the URL structure does not match any of the guidance above, changing it now is not automatically the wrong move, but it is not free either. An established URL has accumulated backlinks, bookmarks, and search rankings tied to that exact string. Moving it without a plan can cost you all three.
The mechanics of doing that safely — setting up 301 redirects, preserving ranking signals, and avoiding the common mistakes that turn a URL migration into a traffic drop — are covered in full in our complete guide to 301 redirects. Read that before you touch a single live URL. And if you are trying to decide how your site's content should be organized before you start moving anything, our content architecture guide covers the planning side: how pages, categories, and internal links should fit together as a system, not just as individual URL strings.
Get an Outside Read on Your Site's Structure
Fixing URL structure on paper is one thing. Knowing whether your specific site's URLs, folder depth, and indexing status actually line up with what you have just read is another. Brass-SEO connects to your Google Search Console and Google Analytics 4 data and answers plain-English questions about what is actually happening with your pages — which URLs are indexed, which are competing with each other, and where your site structure might be working against you. Start a free trial and ask it about your own URLs.
Frequently Asked Questions
Should I change my URL structure if my site already ranks well?
Not without a specific reason. If your current URLs are indexed, ranking, and consistent, the structure is doing its job even if it is not the pattern you would choose starting fresh. Changing established URLs means redirecting every one of them and waiting for Google to re-crawl and re-associate ranking signals with the new addresses. That process carries real risk of temporary ranking loss. Reserve URL structure changes for sites with an active problem — duplicate URLs, broken indexing, or a taxonomy that no longer matches the business — not for cosmetic improvement.
Does folder depth affect how Google crawls my site?
Google does not publish a maximum folder depth, and going one or two levels deeper than another site does not inherently hurt your rankings. What can affect crawling is a site so deeply nested that important pages sit many clicks from the homepage with too few internal links pointing to them. Weak internal linking causes that problem, independent of how many folders deep the URL happens to sit. A shallow, logical structure with strong internal linking solves both at once.
Is it too late to remove dates from my existing blog URLs?
It is possible, but it means redirecting every dated URL to a new undated version, which is exactly the kind of migration that needs to be planned carefully rather than done post by post. If your dated URLs are already ranking well, weigh the long-term benefit of an undated structure against the short-term risk of the migration. For a new site or a blog just getting started, leaving dates out from day one avoids the decision entirely.
Do capital letters in URLs cause the same duplicate content issue as trailing slashes?
They can. Most web servers treat URL paths case-insensitively, so /About and /about load the same page without creating two separate crawlable addresses. Some server configurations, particularly on Linux-based hosting, are case-sensitive and will treat them as different URLs. Lowercase your URLs consistently as a matter of convention, and it stops being a variable you have to think about either way.
Does it matter whether I use www or a subdirectory for a blog versus a separate subdomain?
That's a related but separate decision from folder depth, and it mainly comes down to whether you want the blog's authority to consolidate with the rest of your domain. A subdirectory (yourdomain.com/blog/) shares ranking signals with your main domain. A subdomain (blog.yourdomain.com) is treated more independently by search engines in most cases. For a small business site with one domain and one audience, a subdirectory is almost always the simpler, more effective choice.