URL Structure for a New Website: 9 Decisions to Make Early

Short answer: Keep URLs short, lowercase, hyphenated and readable, group pages into a small number of folders that match how customers think, and leave out anything that will change (dates, years, file extensions, staff names). Pick one form for trailing slashes and stick to it everywhere. Make these calls before launch, because every URL you change afterward needs a redirect and a few weeks of Google re-learning your site.

Why this is worth an hour before launch

Google's own documentation is relaxed about URLs on small sites. Its SEO Starter Guide says search engines will "likely understand your pages as they are right now, regardless of how your site is organized." So this isn't about ranking tricks. It's about the cost of changing your mind later: a renamed URL means a 301 redirect, updated internal links, an updated sitemap and a period where Google processes the move one URL at a time. Google's site-move guide says permanent redirects don't cost you PageRank, but it also says there are no fixed crawl frequencies and the move happens per URL. On a 40-page site that's an afternoon of work. On a 400-page site with a blog, it's a project.

Below are the nine decisions worth settling on day one. Each has a recommendation and the reason behind it.

The decision list

1. Words, not IDs

Recommendation: /services/roof-repair/, not /page?id=482.

Why: Google's URL structure guide asks for "readable words rather than long ID numbers." The starter guide adds that parts of the URL can show as breadcrumbs in search results, so a readable path is something searchers actually see. Most website builders and CMSs default to readable slugs now; the risk is custom web apps and older shop systems that expose database IDs. If your developer is building something bespoke, ask for slugs in the spec.

2. Hyphens between words

Recommendation: /kitchen-remodeling/, never /kitchen_remodeling/ or /kitchenremodeling/.

Why: Google explicitly recommends hyphens over underscores because hyphens signal a word boundary, while underscores are often read as joining words together. Run-together words are the worst of the three: hard for people to read and easy to misread.

3. Lowercase only

Recommendation: force every URL to lowercase and redirect uppercase variants.

Why: Google treats URLs as case sensitive, so /About and /about are two different addresses. If your server returns the same page for both, Google's guide suggests converting everything to one case so it can tell they're the same page. This bites most often when someone types a URL into a printed flyer or an email signature with a capital letter.

4. Shallow folders that mirror your menu

Recommendation: one level of folders for most small business sites: /services/, /locations/, /blog/, /shop/. Two levels only where a real hierarchy exists (/shop/candles/).

Why: Folders help people and Google understand which pages belong together. Google's starter guide notes that on sites with more than a few thousand URLs, directories can help it learn how often each section changes. Below that size the benefit is mostly human. Deep nesting (/services/residential/interior/painting/walls/) creates long URLs and breaks the moment you reorganize your menu, so keep the folder names broad and stable.

5. No dates in blog URLs

Recommendation: /blog/how-to-winterize-a-sprinkler-system/, not /2026/11/02/how-to-winterize.../.

Why: A date bakes a publish day into the address. When you update a good post next year, the URL still says 2026 and looks stale in search results and when people share it. If you write news that is genuinely tied to a date, use a dedicated /news/ folder for it. For evergreen how-to content, keep the date in the page and the structured data, not the path. The same logic applies to putting a year in a slug like /best-patio-heaters-2026/; you'll be redirecting that every January.

6. One trailing slash rule

Recommendation: choose with or without a trailing slash, redirect the other form, and use the chosen form in internal links and the sitemap.

Why: Google's "To slash or not to slash" post says it treats /foo and /foo/ as separate URLs. If both return the same page with a 200 status, you have duplicates. Google calls that "perfectly legitimate" but not optimal, and recommends picking one version, linking to it consistently and redirecting the other with a 301. The post notes that a trailing slash is the more conventional choice for directory-style URLs, but either works. Your homepage is the exception: example.com and example.com/ are the same thing.

7. Leave out things that change

Recommendation: no .php or .html extensions where your platform allows clean URLs, no staff names, no prices, no "new" or "2026-special."

Why: Every word in a URL is a promise that the page will stay relevant to it. Technology changes (your next platform may not use PHP), people leave, prices move. Keep slugs to the stable noun: the service, the product, the topic.

8. Few parameters, and only real ones

Recommendation: use parameters only for things like sorting and filtering, written in the standard ?key=value&key2=value form.

Why: Google's URL guide lists irrelevant parameters (referral IDs, session IDs) and endlessly combinable filters as a common cause of "unnecessarily high numbers of URLs," which can make crawling inefficient. It also recommends the common encoding with = and & rather than custom separators. For a small shop with filters, decide early which filter combinations deserve their own clean page (/shop/candles/soy/) and which stay as parameters.

9. Language or region folders from the start

Recommendation: if you will ever have a second language or country version, reserve a folder for it now: /es/ or /ca/.

Why: Google's guide lists a country-specific subdirectory on a generic domain (example.com/de/) as a recommended pattern for multi-regional sites. Bolting a language on later is far easier if the original pages already sit in a predictable structure. Use words in your audience's language in those URLs, as Google recommends, rather than reusing English slugs under /es/.

A worked example

A hypothetical landscaping company in Ohio with 30 pages might end up with:

Page type	URL pattern
Service	`/services/lawn-aeration/`
Area served	`/areas/columbus/`
Blog post	`/blog/when-to-aerate-your-lawn/`
Project gallery	`/projects/stone-patio-dublin/`
Spanish version	`/es/servicios/aireacion-de-cesped/`

Four folders, lowercase, hyphens, no dates, one slash rule. Nothing in that table needs to change if the company adds services or rearranges the menu.

What to do if your site is already live

Don't rename URLs just to tidy them. If a page ranks and gets traffic, an ugly URL is a cosmetic problem. Fix structural problems that cause duplicates (case, slashes, parameters) with redirects or canonical tags, and apply the cleaner pattern to new pages only. If you do restructure, map every old URL to its new home and redirect each one individually rather than pointing everything at the homepage.

FAQ

Should my main keyword be in the URL?

A short, accurate description of the page will usually contain it naturally. Don't stuff extra keywords into the slug; Google's guidance asks for descriptive, readable URLs, not keyword lists.

How long should a URL be?

There's no official limit worth designing around. Aim for a slug of two to five words that someone could read aloud over the phone.

Is a flat structure (everything at the root) better?

A flat structure works for very small sites, say under 15 pages. Once you have a blog, several services or a shop, folders make the site easier to manage and to read.

Do I need to change my WordPress permalinks?

If they already use the post name, no. If they include dates or IDs and the site is new, change them now; if it's established, weigh the redirect work against the benefit.

If you're planning a new site and want the URL map agreed before anyone builds a page, send us your page list.