Spoke
Site architecture and URLs
How your pages are organized decides how they get found, how authority moves between them, and whether anyone can tell what the site is about. URLs are the visible shape of that decision.
Google documents URL structure guidance and how it handles duplicate URLs, linked below. That shallow, densely linked structures are better is practitioner consensus, not a published rule.
Architecture is the quiet decision that constrains everything after it.
Get it wrong and every fix from then on is working against the structure instead of with it.
How should a website be structured for SEO?
Group pages by subject. Keep everything within a few clicks of the home page. Link densely inside each subject, so the hub connects down to its pages and those pages link back and across to each other.
The structure should be an argument about what relates to what — not a picture of your org chart. URLs should mirror it, stay readable, and stay put. A URL is a promise that something lives there.
Shallow and dense
Every extra click from the home page cuts the chance a page gets found, crawled regularly, and treated as important.
Flat doesn't mean unstructured. It means a hub links to all its pages, those pages link back and to each other, and nothing is reachable only through a chain of index pages or a search box.
Your internal links are doing three jobs at once: they're how pages get discovered, how authority moves around, and your statement about what belongs with what. Three jobs, one structure.
URL design
Words, not identifiers. People read URLs in results, in emails, and out loud over the phone.
Lowercase, hyphens, consistently. Mixed case creates URLs that look like duplicates on a case-sensitive server.
Short, with hierarchy where it means something. /learn/geo/entity-consistency/ says something about how those relate. Depth for its own sake doesn't.
Stable. The expensive part of changing a URL is everything pointing at the old one that you don't control.
No session IDs or tracking parameters in the canonical URL. A parameter that doesn't change the content creates a duplicate.
Duplicates and canonicals
One piece of content, one canonical URL, and everything agreeing on it — internal links, sitemap, canonical tag, redirects.
The usual failure is disagreement. The canonical points one way, your internal links another, the sitemap a third. The system picks one, generally not the one you meant, and you notice because the wrong URL shows up in results.
Watch the usual suspects: trailing slash or not, www or not, http or https, parameter variants, and print or AMP versions.
Changing it
Sometimes you have to. It always costs something.
Map every old URL to its best new equivalent. Use permanent redirects. Never chain them. Update your internal links to point at the new URL instead of leaning on the redirect. And expect a stretch of instability while everything gets reprocessed.
What not to do: redirect everything to the home page. That's a soft 404 at scale, and it throws away whatever those pages had earned.
What we do here
Directories with an index file, so /learn/geo/entity-consistency/ is a real path rather than a rewrite rule — it resolves the same way on any host.
Every breadcrumb and section link is generated from the content tree, so the structure and the navigation can't disagree with each other. And the build fails outright if an internal link doesn't resolve.
More in Technical SEO
Crawlability & indexing
Crawling and indexing are two different things, and a page can fail at either one. Most diagnosis goes wrong by treating them as a single step.
Sitemaps & robots
These two files are where confident wrong advice concentrates, probably because they look simple enough that nobody bothers checking the documentation.
Structured data
Markup won't rank your page and won't make a claim true. Its job is to state outright what a machine would otherwise have to work out by guessing.
Core Web Vitals
Three metrics with published thresholds, measured on real visits rather than a test you ran once. No interpretation needed. You either meet them or you don't.
AI crawler access
Letting AI crawlers read your site is a real decision with a real trade-off. Most advice about it mixes up controls that do completely different jobs.
JavaScript & rendering
Google can render JavaScript" is true, and it gets used to justify architectures that cause real problems. The useful questions are when rendering happens, how reliably, and who else is looking.