Website structure for SEO: site architecture and internal linking for small business

Good website structure groups pages around real customer tasks. Each important page gets a clear job, with useful links to and from related pages. Priority services stay easy to reach, and older content stays connected. That helps people find the right answer and gives search engines clearer discovery paths.

You don't need a new URL pattern for every topic. You need pages with clear roles, and links that actually connect them.

What website structure includes

Website structure is the set of roles and connections between your pages. It has four parts. Each needs checking on its own.

A neat diagram doesn't prove the published links exist. A visual sitemap is a plan for how pages relate. A tidy URL doesn't prove anything links to the page either. You have to check the live site.

Building a new site from scratch? Settle the scope first with planning a business website. Search engines then handle your pages in stages:

• discovery, when a search engine first learns a URL exists

• crawling, when it fetches the page

• indexing, when it stores the page for use in results

• ranking, when it decides where the page shows for a search

Links can help Google find and understand pages. Finding a page still doesn't guarantee it gets indexed or ranks. Not every URL moves through those stages in one fixed, immediate sequence either.

Structure also isn't the same as folders. An article can sit at the root of your domain and still belong to a topic. Links from a hub, an overview page for the topic, create that relationship. The folder name doesn't.

What internal linking does

Internal links connect your own pages. They carry people and crawlers from one useful answer to the next.

What is an internal link

An external link points to another website. A link to a section further down the same page is different again. It's usually called a jump link.

Menu links repeat across the site. Contextual links sit inside your copy and do the explaining.

Different links do different jobs:

Do internal links help SEO

Yes, in three practical ways:

• People can continue the task they came for.

• Crawlers can discover pages they might otherwise miss.

• Search engines get context about how pages relate.

Google says that if your pages are properly linked, it can usually discover most of your site. Your own links are the part of that picture you control.

More links isn't automatically better. Link quantity says nothing about quality on its own. A useful link can support a buying decision without turning every article into a sales pitch.

Anchor text is the clickable wording of a link. Google recommends anchor text that's descriptive, reasonably concise and makes sense out of context. It treats generic wording like "Click here to learn more" as a poor example. It also says there's no magical ideal number of links for a page.

Google can generally crawl a link only when it's a standard link element with a real destination address. Most other formats won't be followed. A button that opens a menu isn't a link to a page. Links added with JavaScript still work when they use that standard format.

Both versions are examples. Natural labels like blocked drain repair options or website migration checklist tell the reader what comes next. Repeating a consistent menu label is fine. Skip rules about keyword anchor percentages, forced synonyms or a set number of links per page.

Start with a complete working inventory

You can't fix a structure you haven't mapped. No single export maps it completely, so combine sources:

• your content management system (CMS) page list, from the system you edit pages in

• a crawl, meaning a tool that follows links from your homepage and other public entry points

• XML sitemaps, the files listing pages you want search engines to find

• Google Search Console, Google's free reports for site owners, plus analytics exports

• backlink records, meaning links from other websites to yours

• server logs, your server's record of requests, where you're authorised to use them

Each source misses something. Together they get you much closer to the real inventory.

Record these crawl settings every time:

• the start URL and which domains it covered

• subdomains, like a separate shop or booking address, included or left out

• how it treated robots.txt, the file that asks crawlers to skip certain URLs

• login areas it could or couldn't enter

• whether it ran JavaScript, as a browser would

• URL parameters, the part after a question mark, and other exclusions

A crawl fed a list of URLs can fetch a disconnected page. That doesn't prove visitors can reach it. Keep "fetched" and "found through links" as separate states.

Don't merge address variants until you've recorded how the site responds to each one. Variants that can behave differently include:

• upper and lower case letters

• a closing slash

• http and https versions

• added parameters

Separate hosts, like a booking system on a subdomain, may sit outside the first crawl. Customers still experience them as one journey.

Keep these in separate fields:

• the index treatment you intend

• the live response code, the status number the server returns

• the declared canonical, your stated preferred version of a page

• the index status Google reports, with the date checked

Use "unknown" where you don't have evidence yet. URL Inspection in Search Console shows Google's indexed data separately from a live test. The live test can't predict which canonical Google will choose.

Search Console's Links report shows a sample, including links Google found over time that may since have gone. It doesn't replace a current crawl. A missing referring page in an inspection report doesn't prove there are no links either.

Don't forget the easy to miss pages:

• old campaign pages

• downloads and legal pages

• booking integrations

• system pages

Keep private URLs, tokens and customer data out of shared screenshots and sample sheets. A common mistake is treating one crawl export as the whole site, then deleting pages it never found.

Assign a role to every important page

Every important page needs one clear job. Record it in a page role register, one row per page:

Keep the preferred URL, the live state and Google's observed status apart. They can disagree. That gap is where the useful findings sit.

A small business site might mix these page types:

• Homepage: orients visitors and routes them to the main paths

• Service hub: helps people compare related services

• Service page: explains one offer and the next step

• Location page: covers a real office or a service area

• Industry page: shows how a service applies to one sector

• Article: answers a question

• Case study: shows relevant work

• Contact page: completes the enquiry

Existing team pages can connect genuine expertise where it's relevant. Pages for legal terms, support or logged in customers can have valid jobs that aren't about search.

Take a plumbing business. Its starting map might look like this, with each row a hypothesis to test:

A service page can carry useful pricing guidance itself. Searches also mix intentions. The register records your preferred answer. That preferred answer isn't an instruction Google has to follow.

How many pages do you need? Enough to cover your real offers and the decisions customers make, without redundant variants. There's no universal page count or ratio of articles to services. A focused eight page site and a broad catalogue can both be right.

If two URLs overlap, check whether they serve different audiences, needs or stages. Keep both when the distinction helps. Merge them when one complete answer can replace the duplicated work. Two of your URLs showing for one search isn't proof of cannibalisation, meaning your own pages competing.

Structure services, locations and industries

Service structure should follow how customers choose. A parent hub helps people compare. Child pages explain distinct offers, with sibling links where customers benefit.

Picture that example plumber working across northern Melbourne. This teaching excerpt isn't a client sitemap or a full inventory:

A tree can't show every useful link. This example business would also link:

• the blocked drain signs article to the blocked drains service

• service pages to genuinely useful local information

• area pages to the services available there

• proof to the work it relates to

• urgent service pages to a suitable contact action

Picture the before state, also made up. The blocked drains page exists. Yet the services hub doesn't link to it. Its supporting article links only to other articles. The fix connects both to the same service URL.

A separate service page needs a meaningful customer decision and specific, useful information. A minor feature or keyword adjective may belong on an existing page. Writing each page well is its own job. Start with planning a service page.

Now scale up the same example business. Say it offers five services:

• emergency plumbing

• blocked drains

• hot water

• gas work

• leak detection

A page for every service in each of 50 suburbs makes 5 × 50 = 250 pages. Four services would make 200. That doesn't make every one of those pages prohibited. The arithmetic shows how fast the upkeep grows, because each page needs accurate, distinct information someone keeps current.

Choose a location model

Pick the location model that matches how you actually operate:

No model suits every mobile business. None needs a page for every suburb. A genuine office page includes:

• the actual address

• services available at that office

• opening hours

• access and parking details

• a contact route

A service area page describes real coverage and practical limits. It shouldn't imply a branch that doesn't exist. Shared templates are fine when the information is useful and accurate. Wider location strategy sits with local SEO.

Google's spam policies define doorway abuse as pages built to rank for similar searches. They lead people to less useful pages. A template or a shared contact page isn't the problem by itself. The risk is mass combinations that differ only by suburb name. A common mistake is copying one suburb page 50 times and changing only the place name.

Industry pages should explain genuine sector requirements, delivery differences and relevant evidence. Link them to the actual services and proof. Reuse common facts carefully, rather than rewriting the service explanation for every audience.

Build hubs that guide the reader

A hub is an overview or category page that organises related pages. Spokes are the pages that answer narrower questions or needs. A hub can be commercial, like a services page, or educational, like an advice centre.

The same example business might run an advice hub like this:

The hub links to each answer. Each answer links back to the hub and to the matching service page. Related answers link to each other where it helps. The tree shows the hierarchy. Those cross links don't fit in it, so write them into the plan.

A card grid isn't automatically a fake hub. A well labelled category directory can work without a long essay, as long as it helps people choose. An educational pillar page, a long overview of a topic, may need a fuller answer. More introductory words don't make a better hub by themselves.

Rigid silos, topic groups that never link outside themselves, cause their own problems. Forbidding useful cross links creates dead ends and repeated explanations. A website migration guide can sensibly link to technical SEO, measurement and service pages.

Topic strategy is a bigger question. We cover topic strategy and supporting content separately. No particular hub shape or spoke count is a documented ranking formula.

Make navigation useful on every device

Navigation should put your most important routes where people expect them. Main menus earn their space with:

• core services

• meaningful audience or location routes

• proof, like case studies or reviews

• the next action, such as contact or booking

Keep support and legal routes easy to find too, often in the footer.

Clear labels depend on the audience. "SEO" may be clearer than "Solutions" for one agency. Another business may have a genuinely useful Solutions category. Ask whether customers can predict the destination from the label.

A mega menu, a large drop down panel of links, can help a broad catalogue. Lots of URLs alone don't justify one. A small site can use a compact menu and a useful service hub. Keep important pages prominent without making every page equal.

W3C menu guidance recommends menus with recognisable structure, clear labels and visible states, like the current page. Fly out submenus, the panels that open from a menu item, should work by mouse and keyboard. Check that:

• submenus open and close predictably

• the keyboard focus highlight stays visible

• focus moves in a sensible order

• touch works on phones and tablets

A menu Google can crawl can still be hard for a person to use. So run a short task test as well. Ask someone to find a relevant service, check it covers their area and work out how to enquire. Give a neutral goal without naming the menu item. An example session record might read:

A handful of sessions can find real problems. Those sessions aren't a statistically representative conversion study.

On mobile, check that important links and substantive content are still there. Google uses the mobile version of a site for indexing and ranking. A menu collapsed to save space is fine. Content that only loads after a tap, swipe or typed input is different, because Google won't load it.

Test real navigation on a phone. Then check the links in the page as it loads. A desktop screenshot doesn't prove the mobile site matches. For broader checks, see mobile SEO.

Keep URLs and breadcrumbs consistent

Three different measurements get mixed up here:

Link depth, often called click depth, depends on the crawl's start page and rules. An orphan page, one no internal link points to, isn't just very deep. It has no route at all.

Google's ecommerce guidance says the number of steps to reach a page can help it infer importance. So can the number of internal links pointing to that page. Apply that carefully on a small business site. That principle isn't a three click limit. Adding 100 links to a page doesn't create authority either.

A main service buried behind several irrelevant categories deserves a look. A deeper historic resource can be fine, as long as it's still useful and reachable. Neither age nor a depth number replaces judgement.

Google recommends readable words in URLs, with hyphens between words rather than underscores. URLs are case sensitive, so lowercase is a practical habit. URLs with parameters aren't automatically bad. Don't move established addresses just to make folder names match a new menu. If you do change URLs, follow a proper website migration and redirect mapping process.

An example breadcrumb trail might read Home, Services, Plumbing, Blocked drains. Breadcrumbs work best when they:

• show a typical user path, as Google recommends, rather than mirroring the URL

• use one useful visible trail where several paths make sense

• appear on mobile too, where they still help visitors

BreadcrumbList markup, code that describes the trail to search engines, can support Google's breadcrumb display in results. It doesn't guarantee one. Google currently offers that display on desktop only. Your developer can follow our notes on breadcrumb structured data.

Find orphan pages and disconnected groups

Orphan pages are easy to miss, because nothing on your site leads to them. Three states need telling apart:

• A strict orphan has no incoming link from any other page on your site.

• A disconnected group links among its own pages. Nothing on the main site links in.

• A deep page is reachable, just several links away.

Orphans and disconnected groups can both need attention, even when an export shows some incoming links. Work through each page like this:

Google may still know an orphan through an external link, a sitemap or an old crawl. So orphan doesn't mean unindexed. A page with plenty of internal links can still have access, canonical or quality problems. Inspect the specific issue.

Three kinds of sitemap do different jobs:

• An XML sitemap supports discovery, but doesn't replace page links.

• An HTML sitemap is a directory page for people.

• A visual sitemap is a planning diagram.

Submitting a sitemap is a hint, with no guarantee that Google crawls every URL in it. None of the three proves the live journey works.

Compare your URL inventory with a crawl from the homepage and other deliberate public entry points. If only a list or sitemap led the crawler to a page, find the missing link route. First rule out JavaScript, robots settings or a crawl exclusion as the cause.

For each disconnected page, choose one action:

• connect it from a relevant hub or article

• improve it and keep it

• merge it into a stronger page

• redirect it to an equivalent replacement

• keep it out of unpaid search results on purpose

• remove it

A private account page doesn't need a public link just to pass an audit. A common mistake is adding random footer links so the orphan count looks healthy. A page with no onward link isn't automatically broken either. A submission confirmation page has done its job. Ask what the person needs next.

Choose the right URL and index controls

Each control solves a different problem. Pick by purpose, because one error in a shared template or robots rule can hit many pages.

These controls aren't interchangeable. Redirects and removals do different jobs again. A permanent redirect sends people and crawlers to a new address. A 404 or 410 status tells them the page is gone.

Each need maps to a different treatment:

A canonical tag names your preferred version among duplicate or very similar pages. A canonical is a signal, not an instruction. Google may choose a different version, so keep internal links, sitemap entries and redirects consistent with it. Don't point the canonicals of different service pages at a parent page to force them together.

A noindex rule keeps a page out of search results. Google has to crawl the page to see that rule. A robots.txt rule manages crawling instead. It can stop Google ever seeing the noindex. A common mistake is using both on one page and expecting double protection.

Private portals and documents need real access control, like logins with the right permissions. Google's robots.txt guide says a blocked URL can still appear in results. Hiding a link isn't protection. Neither is a noindex tag. Keep private addresses and tokens out of public examples, screenshots included.

Don't copy a universal robots rule from a blog post, including this one. Ask your developer to:

• identify the actual URL pattern first

• test representative allowed and blocked URLs

• write down the intended effect

• keep a rollback route ready

Control generated URLs without removing useful categories

Small sites can generate many URLs without meaning to. Common sources include:

• internal search results

• filters and sort orders

• tags and date archives

• calendars and booking parameters

Start with the purpose of each URL family:

Facets are filter combinations, like size and colour on a store. For facets that don't need crawling, Google's faceted navigation guidance suggests robots.txt rules or URL fragments. A fragment is the part of an address after a # symbol.

For facets that should be crawled, the guidance comes down to this:

• use the standard ampersand separator between filters

• keep the filter order the same every time

• avoid duplicate filters

• return a 404 when a combination has no results or makes no sense

• return a 404 for page numbers that don't exist

• don't redirect them all to one generic error page

• don't show an empty page that reports success

A deliberately kept category is different. It can still hold useful information while stock is temporarily out.

Crawl budget is how much crawling Google gives a site. Google's crawl budget guide is aimed at sites with a million or more pages that change about weekly. Sites with 10,000 or more pages whose content changes very rapidly, like daily, are in scope too.

Sites with many URLs marked "Discovered, currently not indexed" in Search Console qualify as well. That status means Google found the URL but hasn't crawled it yet. If your new pages get crawled the same day they're published, Google says you don't need the guide.

Most small sites should fix sensible links, the URL inventory and index intentions first. Don't diagnose crawl budget trouble from low rankings or one unindexed page.

Keep deeper collections discoverable

Older posts, products and listings can vanish behind a button. Pagination splits a long list across numbered pages. Load more adds items when someone presses a button. Infinite scroll adds them as someone scrolls.

People press buttons. Google's crawlers don't. Items that only appear after a click may be missed.

The same guidance recommends a stable URL for each page, with a normal link to the next. Each page should normally have its own canonical. Don't point every page's canonical at page one because they share a category. Avoid page numbers that exist only after a # symbol, like #page2.

The acceptance list can stay short:

• stable URLs for each page in the sequence

• working links to the next page

• direct links to each item

• each page's own canonical

• a 404 for page numbers that don't exist

• no accidental exclusion of deeper items

If you keep a load more button, also provide a crawlable paginated route. Link directly to individual items too. Then test page three, an old item and a page number that doesn't exist. Pressing the button yourself doesn't prove crawler access.

Google no longer uses the old rel=next and rel=prev page tags for this. Those tags don't replace normal links.

Plan what happens when pages change

Pages change status over time. Make the content decision before the technical one. Age, low traffic or no recorded sale isn't a reason to delete a page on its own.

Keep historical pages where they serve customers, obligations or useful reference. A former team member's legitimate authorship can stay on articles they wrote.

If a page is removed with no relevant replacement, a 404 beats an irrelevant homepage redirect. Google's site move guidance warns against sending many old URLs to one irrelevant page. Not every 404 is a failure. A friendly error page should still return a real 404 status. Google treats an error page that returns success as a soft 404.

A redirect can follow a merge or replacement. It doesn't move missing content by itself. Finish the replacement first. Then update internal links, sitemap entries and canonical references.

Give each page type an owner and a review trigger. Typical triggers include a changed service or a closed location. Updating your business profile and directory listings is a separate job for whoever manages them.

Adapt the structure to different businesses

The same principles fit very different businesses. These maps are made up and conceptual, with no client data or measured outcome behind them.

A clinic connects real services to booking, with practitioner and visit details along the way. Here's an example public structure:

Keep urgent care guidance appropriate to the practice. Patient portals stay behind proper logins and out of public maps. Never make up practitioner credentials. Practices face extra advertising and clinical rules, set out in SEO for medical practices.

A store connects useful categories to products, with buying help nearby. An example excerpt shows the idea:

A product can sit in several useful categories while keeping one product URL. Make delivery and returns information reachable where people decide. Categories, facets and sort orders need deliberate treatment, not indexing of every combination.

An example Sydney accounting firm follows the same logic:

• service pages explain the work

• genuine industry pages explain how it applies

• existing practitioner profiles support trust

• resources lead to a consultation or a secure onboarding route

SEO for accountants goes deeper on that sector.

An example Brisbane restaurant organises pages around what diners do: check the menu, plan a visit and book. Private dining and events get their own routes when they're real offers. Put menus and access details on the site as text. A social feed or an image alone isn't enough. Remove expired booking claims.

These patterns are options, not mandatory page lists. A business can combine roles when one page gives a complete, usable answer.

Audit, improve and hand over the structure

A structure audit turns the inventory into decisions. Work through eight steps:

1. Collect known URLs from every source.

2. Classify each page by type.

3. Assign roles and parents.

4. Measure internal support, like incoming links, depth and menu presence.

5. Assess overlap between pages.

6. Inspect each page's next step.

7. Decide an action for each page.

8. Draw the intended structure.

Record each decision in a consistent format:

"Unknown" beats a made up status. The full working register expands that record into columns:

• identity: URL, page type, purpose and parent

• search state: intended treatment, observed index status and date, live status, declared canonical

• links: reachability, incoming links and depth, plus menu and sitemap presence

• context: traffic, valuable external links and overlap

• decision: next action, recommendation, priority and owner

Name the sitemap field "listed in sitemap", not "discovery status". Being listed doesn't mean Google crawled or indexed the URL. Zero clicks from search doesn't mean no value either. Legal, support and existing customer pages can matter without search traffic.

Example findings turn into testable actions like this:

Fix problems in this order:

1. severe access or journey failures

2. high value disconnected pages

3. misleading overlaps

4. lower impact tidying

A visual map alone isn't enough, so pair it with page purposes and testable requirements.

For a wider technical review, work through our SEO audit checklist.

Improve relationships and release shared changes carefully

Many structure improvements don't need a rebuild. Work in this order:

1. Record the baseline.

2. Improve useful contextual links.

3. Strengthen hubs.

4. Review navigation.

5. Address duplicates.

6. Change URLs only where justified.

Shared templates need extra care. One edit to a shared menu, footer or archive can change hundreds of links at once.

Before release, agree these basics:

• the affected templates

• representative URLs from each page type

• an owner and a recorded approval

• a rollback route

Then test what visitors actually see in the browser:

• the links on the page

• mobile navigation

• breadcrumbs and pagination

• status codes and canonicals

• intended index settings

Template changes can affect speed on every page that uses them. Recheck Core Web Vitals, Google's measures of loading, responsiveness and visual stability, after each one.

Set testable acceptance criteria before the developer starts:

An example project criterion might read like this. Every priority service on the agreed list has a crawlable link from the Services hub. Each also has a tested route from the homepage. That's a requirement chosen for this site, not a Google depth rule.

For a redesign, keep the old URL inventory and the important link relationships. Map genuine replacements. Protect the staging site, the private copy used for testing. After launch, check that staging restrictions are gone from public pages. Private areas should stay protected.

Make launch depend on the required tasks working. A perfect visual sitemap can't make up for a broken booking route or a site wide noindex error. Irrelevant redirects can't be offset either. If a serious fault appears, use the agreed rollback or fix process, rather than tidying optional labels.

Measure progress and maintain the structure

Measure the change you actually made. Rankings alone can't show it. Plan the work in windows:

Days 1 to 30 cover inventory and diagnosis. Days 31 to 60 cover relationship changes. Days 61 to 90 cover technical validation and review. Adjust the scope to your site, because the calendar doesn't forecast rankings.

Evidence comes in three kinds:

Compare against a fixed list of priority pages. In an example, 17 of 20 intended pages were reachable before the change, and all 20 after. Reachable coverage rose from 85% to 100%, an increase of 15 percentage points. That's an implementation measure, not a ranking or revenue uplift.

Use the same crawl scope and JavaScript settings both times. Otherwise a newly enabled JavaScript crawl can look like an architecture win when nothing changed. A shorter page list can inflate the percentage too.

Search Console's Performance report shows page and query trends, not enquiries. Note seasonality, offer changes and campaigns alongside the data. Sales can lag behind visibility changes too. A ranking change after a restructure doesn't prove the restructure caused it. If people reach the right page but don't enquire, diagnosing the conversion path comes next.

Run a structure check whenever:

• a service is added, changed or dropped

• a location opens or closes

• a shared template or archive rule changes

Review the incoming links as well as the edited page. Update the diagram and spreadsheet too. The next editor then inherits an accurate plan.

What we recommend at Elev8d

Frequently asked questions

Next steps

Start small and keep each change testable.

Written by Ajay K.Co-founder, Elev8d

Ajay is the co-founder of Elev8d and writes most of what you will read here. Psychology grad turned marketer, which is a fancy way of saying he cares about why people click, not just where things rank. Every guide is written in plain English for Australian businesses, tested on real campaigns before it earns a spot on this site.