Use site-architecture when a small site grows into several sections or existing information becomes hard to find. It plans how readers enter and connect pages, rather than merely producing an XML sitemap. A page inventory and user tasks provide the basis for meaningful decisions.
Install and invoke
Run this in your project terminal to install only this skill for Claude Code:
npx skills add coreyhaines31/marketingskills --skill site-architecture -a claude-code
Node.js and npx must be available. For Codex, replace -a claude-code with -a codex. In the agent conversation, explicitly ask it to use site-architecture and supply your material. The installation command belongs in the terminal, not in your content brief.
Inventory before drawing
List URLs, titles, purposes, traffic or business importance, and current entry points. For a new site, start with three to five reader tasks, such as finding a beginner guide, comparing options, or checking pricing.
Example brief:
Use site-architecture to organize pages.csv.
This is a skill tutorial site. Readers need to find guides by task, check prerequisites, and reach related material.
Identify duplicate purposes and orphaned pages, then provide a page tree, URL table, main navigation, and internal-link plan.
Keep important existing pages reachable. If an address changes, map it individually to its actual replacement.
Group pages by concepts or tasks readers understand, not merely by internal departments. Homepages, section pages, and tutorials have different jobs. Every tag does not necessarily need its own indexable destination. Treat depth and click-count guidance as diagnostic prompts rather than rigid search-engine rules.
Test the structure with real tasks
Request both a readable tree and a URL table showing parent sections, navigation placement, and priority. Main navigation provides core entry points. Footers can hold stable secondary information, breadcrumbs explain hierarchy, and contextual links connect questions arising during reading. A single menu should not carry every responsibility.
Walk through three concrete tasks: where a new visitor starts, where someone finds prerequisites halfway through a guide, and how a finished tutorial leads to a sensible next step. If the path requires knowing internal terminology, revise labels or add contextual entrances. Link text should explain its destination rather than simply say “click here.”
For a redesign, maintain an individual old-to-new URL map. Plan redirects only where a genuine or appropriate replacement exists; do not send every retired address to the homepage. Before launch, check that navigation, links, and redirects actually implement the design. Sample important entry points afterward. The diagram is a planning artifact; the live pages and connections must deliver the intended reading journey.
Before launch, ask people unfamiliar with the site to find three important pages without explaining the navigation. Record where they pause, then compare their paths with site-search terms and 404 logs. Do not flatten everything to satisfy a three-click slogan.
Example: consolidate two category systems that confuse readers
Suppose a tutorial site categorizes by both “tool” and “task.” One guide appears in two near-duplicate sections while ten articles have no entry path. Give the skill current navigation, page inventory, and site-search terms. Ask: “Use site-architecture so a reader trying to organize interview notes can find the right guide. Propose a primary entry point and the relationship among task pages and detail pages. Identify duplicate sections and orphans. Preserve existing URLs unless a merger has a clear mapping and reason.”
Actually try to find three tasks from the homepage; a tidy ASCII tree is not enough. If a reader must already know an agent’s name to locate “organize interviews,” the classification serves internal concepts rather than tasks. Dumping every article into footer links still lacks meaningful context. The structure works when both navigation and relevant in-page links lead people to the guide they need.
How public workflows connect planning to implementation
GOV.UK used several rounds of task-based navigation research and revised the design around actual paths. A neat page tree and a findable site are different results; the reader tasks above remain the acceptance check.
One public pipeline loads site-architecture text and a route inventory as non-interactive system-prompt guidance in its strategy stage, then applies per-route recommendations in code. It does not invoke a separate slash command or show visitors finding pages faster.
A separate Astro website-builder workflow puts site-architecture before scaffolding: settle hierarchy, URLs, navigation and internal links, then implement the pages. The workflow file shows a developer's order of work, not the results of visitor testing.