Site architecture

Plan the bones of a site: which pages exist, how they nest, what the URLs look like, what goes in the nav, and how pages link to each other. Search engines and visitors both depend on this being right, and it's far cheaper to fix on paper than after launch.

When to use it

• Building a new site or microsite.
• Adding a large batch of content (say 30+ articles) that needs a structure.
• Merging two products or two sites into one.
• Before any launch where the page list isn't written down.

Don't use it to judge how well an existing site sells (that's /website-score) or to lay out a single page (that's /website-wireframe).

Inputs

• The page list you have or want. If there's a live site, fetch its nav and sitemap.xml.
• context/icp/: so nav labels use the buyer's words, not internal names.
• context/positioning/: the products, use cases and segments the site must cover.
• context/competitors/: tells you whether you need comparison and alternative pages.
• Any content plan or keyword list you already have: it decides the content clusters.

Agency users: swap context/ for clients/<client>/context/. If a context file is missing, ask the user for the product and audience list, and flag the labels you had to guess.

Steps

1. Pick the depth. Flat (2 levels) suits one product and under 30 pages. Most SaaS sites sit at 2 to 4 levels. Go to 5+ only for many products or verticals. Rule: every important page is reachable from the homepage within 3 clicks. Produces: a chosen depth and a reason.
2. Group content into hubs. Each topic gets a pillar page (the full overview) and spoke pages (the details). Every spoke links back to its pillar, and to 3 to 5 related spokes. Produces: a list of clusters.
3. Design the nav zones. Header: 4 to 7 items. Footer: up to 4 columns (product, resources, company, legal). Section sidebars: 5 to 10 items. Breadcrumbs on every interior page. Produces: the nav, item by item.
4. Lock the URL patterns. See the table below. Rules: human-readable slugs, no dates, URL depth that matches the hierarchy, and one trailing-slash convention used everywhere. Produces: a pattern per page type.
5. Plan internal links. 5 to 10 internal links per 1,000 words. Every page has at least one link pointing to it. Vary the anchor text. Produces: inbound and outbound links per page.
6. Write it up in the four formats below. Produces: the deliverable.

URL patterns

What good looks like

• Anyone can find pricing, the main product page and a way to talk to sales in one click.
• Nav labels are words the buyer uses, checked against the ICP file.
• No page without a link to it, and no cluster without a pillar.
• A developer could build the URL map without asking you a question.

Mistakes to avoid

• Pages 4 or more clicks deep. Visitors and crawlers rarely reach them.
• More than 7 header items. It overloads the reader and breaks the mobile menu.
• Date-based URLs like /blog/2026/05/post. They age the content and break when you refresh it.
• A flat blog with no pillars, which spreads authority thin across unrelated posts.
• The same exact-match anchor text on every link. It reads as manipulation.
• Changing live URLs without a redirect plan. Note every old URL that needs a 301.

Output

Save to outputs/website/MMYY-site-architecture.md with four parts:

1. Hierarchy diagram in plain text:

/
├── /product/
│   ├── /product/analytics
│   └── /product/reporting
├── /pricing
├── /use-cases/{slug}
├── /compare/acme-vs-{competitor}
├── /resources/guides/{slug}
├── /blog/{slug}
└── /about

2. The same tree as a Mermaid diagram, for docs that render it.
3. URL map: one row per page with URL, page title, target keyword, status (live, new, redirect).
4. Internal linking plan: for each page, the pages it links to and from, with anchor text.

Next step: lay out the key pages with /website-wireframe, then write them with /website-copy.

Attribution

Adapted from the site-architecture skill in coreyhaines31/marketingskills (MIT, Corey Haines): https://github.com/coreyhaines31/marketingskills