Site architecture used to be an argument about click depth. Three clicks from the homepage, everyone said, as though the number had been handed down rather than invented at a conference.

The concern underneath it was sound. If a page is hard to reach, it gets read less, by people and by machines alike. What’s changed is that the machines reading your site are now doing something more demanding than filing it. They’re trying to work out what your organisation is, what it does, and whether any of it answers the question in front of them.

Architecture is how you make that easy or hard.

One page, one job

The single most useful structural habit is also the least technical. Give every page one clear purpose and let the URL, the title, and the opening paragraph agree on what it is.

You see the opposite constantly. A page that’s part product overview, part pricing explainer, part case study, held together by the fact that it was written in one sitting. A human skims it and extracts what they need. An automated reader trying to summarise it produces something mushy, because the page never committed to a single claim.

Splitting those pages usually improves both audiences at once. The thing to resist is splitting so far that you end up with a dozen thin pages saying almost the same thing in slightly different words, which creates a different problem: several plausible sources for one question and no obvious winner among them.

Hierarchy that means something

The folder structure of a site is read as a statement about relationships. A guide sitting under a topic directory is understood to belong to that topic. A page dumped at the root belongs to nothing in particular.

Some things that tend to hold up:

• Group by subject, not by campaign. Directories named after a quarter’s initiative age badly and stop describing anything.

• Keep URLs stable. Every restructure costs you accumulated signal. Restructure when the site’s meaning genuinely changed, not because a new CMS made it convenient.

• Let the hub pages do real work. A category page that only lists links is a waste of a strong position. Give it an actual explanation of the topic and the links become supporting evidence.

• Link sideways as well as downward. Related pages referencing each other in prose builds the associative map that pure hierarchy misses.
  

Internal links carry more weight in this context than they get credit for, mostly because of the words in them. Linking with the phrase that describes the destination tells any reader what to expect on the other side. Linking with “learn more” tells nobody anything and wastes the one signal you had.

Make sure the content is actually in the response

A page can be beautifully organised and still arrive empty.

If the main content only appears after client-side rendering, you’re relying on whatever is fetching your page to execute scripts and wait for them. Some do. Some don’t. Some do it inconsistently under load. The safe position is that anything you want read should exist in the initial HTML response, with interactivity layered on after.

The same logic applies to content hidden behind interaction. Text inside a collapsed accordion is usually present in the source and generally fine. Text that loads only after a click, or after scrolling, or after a search box is used, may as well not exist. That last one applies to a lot of documentation sites, where the useful material sits behind an internal search index that nothing external can query. Understanding making your pages crawlable and indexable tends to expose a handful of these quietly, and they’re usually cheap to fix once someone has actually looked.

Signals from the server

Architecture isn’t only what’s in the HTML. The response itself carries information.

• Consistent status codes, so missing pages fail properly instead of returning a soft success

• Redirects that resolve in one hop rather than chaining through three legacy domains

• Canonical declarations that point somewhere sensible when the same content is reachable by several paths

• A sitemap that reflects the site as it exists today rather than as it existed at launch

• Response times that don’t degrade badly when several requests arrive at once
  

Sitting alongside those are the essential website security headers, which belong to the same review even though they solve a different problem. A misconfigured content policy can break rendering for some clients while looking perfectly fine in your own browser, and that failure mode is genuinely difficult to spot from the inside.

Headings as the outline

Within a page, headings are the map any automated reader follows first. Use them as a real hierarchy rather than as a font size. One clear H1, section headings that describe what the section contains, and no jumping levels for visual effect.

Descriptive headings beat clever ones here almost every time. “Pricing for teams under fifty people” survives being extracted on its own. “The sweet spot” does not.

Structured data helps where it describes something concrete: an organisation, a product, an author, a set of questions and answers. It’s a supplement to clear content rather than a replacement for it, and marking up a vague page doesn’t make it less vague.

The test that costs nothing

Open your site with styling disabled and read it top to bottom.

What you get is close to what a text-based reader receives: the headings, the copy, the link text, in order. If that reads as a coherent document, your architecture is doing its job. If it reads as a pile of navigation followed by three words of content and a footer, you’ve found the work.