GeoSeoToday · 2026-07-16 · 更新 2026-07-16 · On-page SEO

URL Structure & Site Architecture: How to Plan Them

Four rules for URL structure: keep it short and readable, fold it into semantic directories (like /blog/ and /services/), use lowercase hyphenated English slugs, and never change a URL once it’s published. For site architecture, follow “every page is reachable within three clicks of the home page,” and let your directory levels map to topic clusters. Architecture is a pre-launch decision — change it after you go live and every time it’s a house move.

Why is URL structure worth nailing down on day one?

1. Google reads directories to understand sections of a site. A clean path (/en/blog/...) lets both crawlers and your Search Console reports break the site down folder by folder.
2. Changing a URL is enormously expensive. Every change needs a 301 redirect, there’s a risk of authority leaking during the pass-through, and every existing external link now has to route through that redirect — so rule one is “design it so you never have to change it.”
3. Users and AI both read the URL. example.com/blog/what-is-content-debt looks more trustworthy in search results, on social shares, and in AI citation lists than example.com/p?id=8471.

Seven URL-naming rules

1. Lowercase English plus hyphens: what-is-content-debt. Google officially recommends hyphens (-) over underscores (_); mixed case manufactures duplicate URLs.
2. Short — cut the filler. Put only the core meaning in the slug; 3–6 English words is the comfort zone. Use /blog/internal-linking-strategy/, not /blog/how-to-build-an-internal-linking-strategy-for-your-website/.
3. No dates. /2026/08/17/ makes content look like it expires, and once you update an evergreen piece the old date in the URL becomes a lie.
4. No categories that can change. Reclassifying an article shouldn’t change its URL — keep every blog post at /blog/<slug>/, and manage categories with tags or frontmatter, never in the path.
5. On Chinese-language sites, prefer English slugs. A Chinese URL turns into a long string of percent-encoding when shared (%E5%85%A7%E5%AE%B9...) — ugly and prone to breaking. Putting the Chinese keyword in the title and body is plenty.
6. Avoid parameters as content paths. Parameter pages like ?id= and ?cat= are hard to manage and easily duplicated; keep parameters for filtering and tracking, and consolidate with canonical.
7. Pick one trailing-slash convention. Choose either /blog/foo or /blog/foo/ and 301 the other one to it — otherwise you have site-wide duplicate URLs.

Site architecture: directories map to topic clusters

Take an SEO/GEO site like this one, a “blog plus service pages” setup, as an example:

/en/                           ← language root
├── blog/<slug>/               ← all articles (long-tail + pillar pages)
├── geo/                       ← Boss page: GEO service + tools
├── seo-audit/                 ← Boss page: SEO audit service
└── about/                     ← trust page

Key points:

• Keep it shallow. Content pages should sit at most two directories deep. Google’s own documentation says URL depth itself isn’t a ranking factor, but every extra level adds a bit of complexity to internal-link maintenance and crawl paths.
• Architectural “depth” is decided by internal links, not by directories. A page can live one level deep in the path and still be a deep page if it takes five clicks from the home page to reach. The goal: every important page reachable in ≤ 3 clicks. Link design for passing authority is its own topic (internal linking strategy).
• Topic clusters form through links, not subdirectories. Keep same-cluster articles all under /blog/ and string them together with a pillar page; opening a subdirectory per cluster (/blog/technical-seo/...) works too, but the cost is that an article changing clusters has to move house.

Flat vs. deep: how to choose?

For most content sites, flat is the right call — simple, stable, never moving house.

Path design for multilingual sites

Language subdirectories are the best answer in most cases: /zh-hant/, /zh-hans/, /en/, paired with hreflang markup. Compared with subdomains (en.example.com) or ccTLDs (example.tw), subdirectories let every language share the same domain authority and keep maintenance cost lowest. Note that each language’s slugs are planned independently — don’t use machine-translated paths.

A site that’s already live wants to change URLs — is it worth it?

First ask: is the current structure causing actual harm (duplicate URLs, parameter hell, reports you can’t analyze)?

• No → don’t change it. An ugly-but-harmless URL isn’t worth a house move.
• Yes → fix it all in one concentrated pass, prepare a complete one-to-one 301 mapping table, and execute it in a single move rather than trickling changes out over time.

FAQ

Q1: Does putting keywords in the URL help rankings? Yes, but very slightly — Google officially calls it a “very small ranking factor.” The real reasons to do it are readability and click-through trust; don’t stretch the slug just to cram keywords in.

Q2: Do I need to drop the .html ending? It doesn’t affect rankings. For a new site, clean paths (no file extension) are recommended purely for looks and consistency; if an old site has .html, leave it — it’s not worth a redirect.

Q3: I found a typo in an article slug after publishing — do I fix it? If it just went live (not yet indexed, no external links), change it right away; if it’s already indexed, weigh it up — leave a typo that doesn’t break function, and if you do change it you must set a 301.

Q4: Does URL depth affect crawl budget? Indirectly, yes: a deep page with few internal links gets low crawl priority and easily gets stuck at “Discovered - currently not indexed.” The fix is links, not hacking directory levels off — it’s a demand-side problem.

GeoSeoToday’s own site runs on “language subdirectories plus a flat /blog/,” and looking back over 2026, the lowest-effort decision was locking slugs down on day one and never moving house. Whether your page structure is friendly to AI engines is something you can check with the GEO Readiness Checker; for how citable content is laid out within a well-structured page, see the GEO Content Structure Template.