Site Architecture SEO: Plan Your Pages and URL Structure Before Launch

Site architecture is how your pages are grouped, how they link to each other and how their addresses are written. It decides what a visitor sees in the menu, how many clicks it takes to reach a page and whether a crawler can find the whole site by following links. Site architecture SEO is the part of that planning that helps search engines and people understand how the site fits together.

The best time to plan it is before launch. Pages are cheap to rename and move while nothing is public. After launch, each address change needs a redirect and careful monitoring, as the website migration checklist shows. This guide is for owners, designers and developers who are about to build or rebuild a site. By the end you will have a section map, a page-depth target, a URL rulebook and a way to test the plan against the live site.

A good structure removes obstacles to crawling and understanding. It does not promise rankings, and no single structure suits every site.

Before you begin

You will need:

A list of the content the site will have at launch and the content you expect to add within a year: services, products, guides, locations, support articles.
Input from whoever knows your customers' questions, because the structure should follow how people think about your offer.
A decision-maker for naming. Section names become part of addresses, so changing them later has a cost.
Developer access, or a clear brief for the developer, for the URL rules.
A spreadsheet. Allow half a day for a small site and longer for a large catalogue.

If you are not planning a new site but changing a live one, treat this guide as a design reference and read Google's advice carefully first. Google's SEO starter guide says you should not feel you must reorganise a site right away, because search engines will probably understand your pages as they are. Rework a working structure only when there is a real problem to solve.

Step-by-step instructions

Step 1: List every page type and group them

Write down the kinds of page the site needs: home, section landing pages, detail pages (a product, a guide, a service), supporting pages (about, contact, legal) and utility pages (search results, cart, account). Then group the detail pages by topic, the way a visitor would look for them, and not by your internal team structure. A shop might group by what people buy, such as "garden tools", and not by supplier.

Keep the number of top-level sections small enough to show in a menu. A handful of clear sections is easier to use than a long list. If two sections overlap heavily, consider merging them.

What success looks like: a tree on one page, with the home page at the top, a few sections below it and the page types beneath each section.

Step 2: Set a page-depth target

Depth is the number of clicks from the home page to a page. A reasonable target is that important pages sit within three or four clicks. This is a practical design aim and not a figure from any search engine's documentation. Pages that need many clicks are harder for visitors to find and give a crawler a long path to follow.

Check the tree for pages that fall outside your target, such as old articles that only appear on page 12 of an archive. Plan extra routes to them, such as hub pages, topic indexes and related-content links. Internal Linking Strategy covers the linking methods, and Pagination SEO Best Practices covers long lists.

What success looks like: every page in the tree is within your depth target or has a documented extra route.

Step 3: Choose how URLs will mirror the structure

Directories in a URL can reflect the sections you chose, for example /guides/ for guides and /services/ for services. Google's starter guide says that grouping similar topics into directories can help Google learn how often different parts of a site change, and that this matters mostly for larger sites with more than a few thousand URLs. For a small site, simple paths are enough.

The starter guide also notes that parts of the URL can appear in search results as breadcrumbs, and that Google derives breadcrumbs from URL words. So readable section names are useful to people as well.

Do not create a deep folder path just because the structure has depth. A URL such as /services/web/design/small-business/ is longer and harder to maintain than /services/web-design/. The URL does not have to repeat every level of the tree.

What success looks like: each section has a short, readable directory name that you can still defend in two years.

Step 4: Write a URL rulebook

Decide the rules once, write them down and apply them to every page. These rules follow Google's URL structure guidance.

Use readable words. A URL like /wiki/Aviation is more useful to a person than index.php?topic=42&area=3a5ebc944f41daa6f849f730f1. A URL that only contains random identifiers is less helpful.
Use hyphens between words. Google advises hyphens because they clearly signal a word boundary, and advises against underscores. Avoid joining words together, as in greendress.
Pick one letter case. Google treats /APPLE and /apple as different URLs. Use lower case throughout and, if your server treats cases the same, convert to a single form with a redirect.
Use the language of your audience. If your visitors search in German, /lebensmittel/ is fine. Percent-encode non-ASCII characters in URLs and in link href attributes.
Limit parameters. Use query strings only when they change the content, and remove parameters that do not. Separate pairs with = and &.
Never use fragments to change the content. An address like example.com/#/potatoes should not carry different pages. If you build a single-page application, use the History API.
Avoid session IDs in URLs. Consider cookies instead.

Write the pattern for each page type in a table:

Page type	URL pattern	Example
Section landing	`/{section}/`	`https://example.com/guides/`
Detail page	`/{section}/{slug}/`	`https://example.com/guides/site-speed/`
Paginated list	`/{section}/?page={n}`	`https://example.com/guides/?page=2`

Add rules for trailing slashes and for the host (with or without www). The host choice is covered in www vs non-www.

What success looks like: a developer can generate the correct URL for any new page from the table without asking.

Step 5: Keep URLs stable

A URL is a promise. Once a page is public, other sites, bookmarks and search results point to it, and changing it needs a permanent redirect. Choose slugs that describe the content in a way that will stay true, and avoid putting dates, version numbers, product codes that change or the author's name in the address unless they are part of what the page is.

If a page is later renamed, the old address should redirect to the new one with a permanent redirect in a single step, as described in 301 vs 302 Redirects and Redirect Chains and Loops.

What success looks like: slugs are short, descriptive and unlikely to need renaming.

Step 6: Plan how filters, search and duplicates will behave

Decide in advance which URLs are meant to be found in search and which are conveniences for visitors. Google's guidance warns that additive filters can create a huge number of near-duplicate list URLs, that referral, sorting and session parameters multiply URLs, and that a calendar can generate endless future pages. Plan for each:

Sort and filter options: decide which combinations are allowed to be crawled and block or noindex the rest. See Faceted Navigation and URL Parameters.
Internal search results: block crawling of search result pages with robots.txt, as Google suggests for search results and similar dynamic URLs.
Calendars: add nofollow to links to dynamically generated future pages.
Relative links: use root-relative links such as /guides/ and not parent-relative paths, since broken relative links can create endless URL spaces when nonexistent pages do not return the correct status code.

Also decide the canonical version of each page and how duplicates will be redirected. See Fix Duplicate URLs and Incorrect Canonical Tags.

What success looks like: the plan names which URL types are indexable, which are blocked and which redirect.

Step 7: Add navigation, breadcrumbs and a sitemap to the plan

Plan the menus so that every top-level section is one click from the home page, with links that are real <a href> anchors. Plan breadcrumbs for sections with more than one level, and consider marking them up later; see Breadcrumb Structured Data. Plan an XML sitemap that lists the canonical pages you want in search, using absolute URLs, as in How to Create a Valid XML Sitemap. The starter guide describes a sitemap as a file that contains the URLs you care about, and says you do not have to have one.

What success looks like: the plan includes navigation, breadcrumbs and a sitemap, each tied to the section tree.

Step 8: Test the plan against the built site

Once pages exist on staging or after launch, crawl the site and check the results against the plan:

Count the clicks to each page and compare with your depth target.
Compare the live URLs with the rulebook and look for upper-case, underscores and stray parameters.
Look for orphan pages that the structure does not link; see Orphan Pages.
Check that every internal link returns a 200 status and does not redirect.

Keep staging out of search results while you test, as covered in Preventing Staging Site Indexing.

What success looks like: the crawl matches the plan with only deliberate exceptions.

Final verification checklist

A section tree exists with a small number of clear top-level sections.
Important pages are within your chosen click depth, or have extra routes to them.
A URL rulebook covers words, hyphens, case, parameters, fragments and language.
URL patterns for each page type are written down.
Slugs are short, descriptive and unlikely to change.
The plan states which filter, search and calendar URLs are crawlable, blocked or noindexed.
Navigation, breadcrumbs and the sitemap are part of the plan.
A crawl of the built site matches the rulebook.

Common mistakes to avoid

Mirroring the org chart. Visitors do not know your departments. Group by what they are looking for.
Very deep folder paths. Long paths are hard to read and maintain. Use short section names and flat slugs where you can.
Mixed letter case. /Guides/ and /guides/ are different URLs to Google. Pick lower case.
Underscores and joined words. Use hyphens, which signal word boundaries.
Hash-based routing. Fragments should not change the page. Use real paths and the History API.
Session IDs and tracking parameters in indexable URLs. They multiply addresses. Use cookies or strip the parameters.
Renaming sections after launch with no redirects. Every old address needs a permanent redirect.
Reorganising a working site on a whim. Google notes search engines will likely understand your pages as they are. Change a live structure only for a clear reason.

Frequently asked questions

What is the ideal site structure for SEO?

There is no single ideal shape. A clear hierarchy, important pages that are easy to reach and stable readable URLs make a site easier to crawl and understand.

Should my site be flat or deep?

Aim for important pages within a few clicks, which keeps things easy to find. That does not mean putting every page in the menu. Use hub pages and contextual links to keep large sites shallow.

Do I need keywords in URLs?

Words that describe the page help people read the address, and Google recommends descriptive words over random identifiers. Do not stuff keywords into a URL. Describe the page accurately.

Should URLs end with a slash?

Either works. What matters is picking one form and redirecting the other, so each page has one address.

Can I change URLs after launch?

You can, with permanent redirects from each old address to the new one, updated internal links and a sitemap update. It adds work and some risk, so settle the URLs before launch.

Official references

Next step: See how Crawvix checks a website and capture a baseline once scanning opens. This guide provides technical information, not a guarantee of rankings, traffic or index inclusion.