Structure

Most sitemaps start as five words. Home, About, Services, Blog, Contact. Nobody decided on those five. They were copied from every other site in the category, and they say nothing about what this business's visitors need.

A sitemap is the set of decisions about which pages exist and why. I mean the plan of pages you design from. The XML file for search engines is a separate job. The test for every page is one question: what does a visitor come here to get done? If the answer's vague, the page will be vague, and so will everything written for it. Fixing that now costs you a line of text. Fixing it after the build means rewriting whatever sits on the page.

You don't have to start from nothing. A blueprint for a kind of site gives you a starting list. Here's one for a local food shop, which fits the bakery we've been following. But a starting list isn't a plan. Every page on it has to earn its place, with one sentence in this shape: this page helps someone decide or do something, so they can take a next step. Today's bread helps a regular see what's baked today and what's left, so they order before it sells out. That sentence commits you to a person, a decision, and the page's main action, before anyone has drawn a button.

Once every page has a sentence, read them side by side. They start arguing with each other, which is the point. Wholesale's sentence turns out to be Contact's sentence: someone with a question, here a café. Same job twice means one page, so wholesale becomes a short section on Contact. Cakes can't be ordered online at launch, so a cake page has no next step. It's cut for now.

Then name the pages. A label is a promise about what's behind it, so write it in the words visitors use. The bakery's regulars don't say products. They ask what bread there is today. So Products becomes Today's bread, and Location and hours becomes Visit. A quick test: show someone the label on its own and ask what they expect behind it. If they guess wrong, the label is wrong. And skip the clever names. Every clever label makes a visitor stop and decode it.

This is the plan I hand on, as a tree. Group the pages by what visitors are trying to do, never by how the business is organized inside. The main navigation holds what most visitors need: today's bread, ordering, the visit details, and the page for someone new. The footer repeats Visit and Contact on every page, because someone stuck on any page needs them. Each line is the address, the label and the job. It's short, and every line can be argued with.

Last, check it against the visitor journey you mapped in strategy. Take one path and walk it. A regular lands on Home, goes to Today's bread, then to Order ahead, and places her order. Then she wonders how early she can collect. On the day this plan was written, nobody knew. So it's marked as an open question, not guessed. The owner answered three days later: seven o'clock. Then walk it the other way. A page no path reaches gets cut, or folded into one that's on a path.

This matters more when an AI agent is doing the writing. Hand it a page called About and it'll produce the average About page: founded in, passionate about, committed to quality. Hand it the job sentence and it has something to aim at. The sitemap is one of the first files the agent reads, so vagueness here spreads into every page after it.

If you can't say a page's job in one sentence, it isn't a page yet. Write the sentence, then the label, then walk a visitor through it.

The site plan says which pages exist. This decides how people move between them: what sits in the main menu, how the one action stays in reach, and where each page sends people next.

My strategy draft planned seven menu items, with one rule I'd keep anywhere: don't overload the main navigation. The ticket button has to stand apart from the links. The built homepage has five links, each jumping to a section, and the ticket button set apart on the right. Write that into the plan, in the words the menu actually uses.

Then keep the one action in reach at every width. The draft says phones must keep immediate access to tickets. On a phone, the header shrinks to the logo and the menu, because the hero's ticket button sits right under it. Scroll past the hero, and a ticket button stays pinned to the bottom of the screen. That goes in the plan too, so whoever builds the next page keeps it.

Next, the links between pages. They follow the visitor's next question. Someone reading about a speaker wants their session, and the year they spoke. Someone watching a talk wants the speaker and the year. Most of those pages aren't built yet. Write the links into the plan anyway, so each new page arrives already connected.

Last, give every page one main next step, so nobody reaches the bottom with nowhere to go. One, not five. A page that offers everything asks for nothing.

Keep the menu to what most visitors need, keep the one action in reach at every width, link pages the way questions follow each other, and end every page with one next step.

A sitemap tells you which pages exist. It doesn't tell anyone what goes on them, and that gap is where generic pages come from.

Start by sorting the sitemap into page types. A page type is a pattern of content that repeats. The bakery's six pages come down to three types. Today's bread is a product list: one entry per loaf, the same slots every time. Order ahead is an order form. Visit, About and Contact are info pages. Thinking in types keeps scope honest. The bread list changes every morning, and six loaves written up one at a time are six chances to drift. If you started from a site blueprint, it already lists the pages and the sections on each. Treat those sections as your first draft of slots, then give each one this client's rule, source and count.

Each page type is a set of slots. A slot is a named piece of content the page has to carry. It isn't a box in a layout, and it isn't a database field yet, though it may become one. Define each slot by four things. A name that says what it carries. A rule for what it must contain. A source, meaning where the content comes from: a fact from the bread list, copy someone writes, or evidence like a photo or a review. And a count: exactly one, one or more, or allowed to be empty.

Here's one written out. Read the source column first, because that's where most of the thinking is. The price comes from the owner, and the rule says always shown, never 'ask in store'. The allergens come from the head baker, every one, for every loaf. Nobody can fill those by writing nicely. If the source doesn't exist yet, the slot stays empty, and you've found a research task for the client. Here, on the ninth of October, nobody had written down prices or allergens.

Name slots for what they carry. If your model says hero, feature grid, testimonial carousel, you've designed the page before you know what's on it, and you've picked the components everyone else picks. 'A regular's words' could end up as one quote set large, or a single line beside the order button. 'Testimonial carousel' has already decided, and it decided the average. Design decisions come later, from the content.

The count matters more than it looks. One photo or twelve is a different component. 'Optional' means the page has to look finished when that slot is empty, and someone has to design that state on purpose. When you get to building components, these counts are the specification. When you get to copy, each slot is the brief for one piece of writing, with its length and its source already set.

Before you hand the model on, test it against one real instance. Take one actual loaf, the sourdough, and fill every slot from its real source. You'll find things. On the ninth of October, the bread list had the name and the description, but no price and no allergens. Each gap is either a slot that shouldn't exist or a fact the business needs to start keeping. Here it was two questions: prices for the owner, allergens for the head baker. The content model is ready when one real loaf fills every slot. Better to find the gaps with one loaf than after the whole list is built.

This is also the most useful file you can give an AI agent. Without it, the agent fills each gap with what pages like this usually say. With it, the agent knows each slot, its source, and when to leave it empty and say so.

Design the slots before the page. A slot says what must be there and where it comes from, never what it looks like.

A one-page site has to answer questions in the order people ask them. In Plan, you wrote down the attendee's questions, in order. Now each one becomes a section of the homepage.

Give each question a section: what it must answer, the slots it holds, and what it asks next. What it is, when and where go first, with the ticket button, because that's what someone arriving cold needs. Is it credible comes next. A stranger won't care who's speaking until they believe the event is real. The proof is AllWeb's own published history, and the figures come from their site.

Then who will I hear from, what the day is like, whether it's worth it, and what happened before. Each section answers one question, and none tries to answer two. The last section asks how do I go, and repeats the date, the place and the ticket button. By the bottom of the page, a convinced visitor is ready to act.

Then check the build kept the order. On the built page, each section starts with a note naming its question. One search lists them, top to bottom. Those notes are for whoever edits the page next. Move a section, and the note says which question you just moved.

Last, map the calls to action. For each section, write the one action it offers and where it sits. One search finds every action button on the page: five for tickets, one for partners. Write each one down with its place. The header button is hidden on phones, so phones get one pinned to the bottom after the hero. Now nobody has to guess where the next step is.

Take the visitor's questions in the order they ask them, give each one a section with its slots, map where each action sits, and keep that order all the way into the code.

Before anyone designs, know what will fill every slot. The section list says which slots exist. Now write down what each one needs, and where it will come from.

Walk the page section by section. The hero needs a line, the date and the city: the line from the brief, the rest from AllWeb's own site. The proof needs the published figures, and the speakers need a photo and a short bio each. Some things don't exist yet. No 2026 talk titles have been published, and the next ticket price is unknown. Those become asks to the client, never guesses.

Every image needs a source you can name. Most of these come from AllWeb's own photo library. The venue photo came from Wikimedia Commons, free to use, and the page credits it anyway. AllWeb's own photos are fine in a concept. A real launch needs the client's written OK, so the list says that too.

Where nothing fits, don't drop in a stock photo or an AI picture. The brief's rule is an empty, labeled box that says what to shoot or find. A visible gap gets filled. A stand-in gets shipped.

List what fills every slot and where it comes from. Ask for what's missing, and leave a labeled gap rather than a stand-in.

Here's a line from an AI's first draft of the bakery's About page: 'Nestled in the heart of the neighborhood, we're passionate about baking fresh, delicious, artisan bread for everyone.' Every bakery in the country could put that on their site tomorrow, and that's what's wrong with it.

Write slot by slot. The content model already tells you each slot's job, how long it can be, and where its facts come from. Today's bread's intro is one line, from the head baker's bread list. The order rule comes from the decision made in strategy. When you write to the slot, the padding goes, because there's no room for it and nothing to pad with. Most bloated pages come from someone writing 'the homepage' in one sitting and filling the space.

Then use the words customers use. The bakery's reviews say 'the sourdough sells out by ten' and 'I order the rye for Saturday'. Nobody writes 'artisan sourdough boule'. The glossary you built in research decides the nouns. If a customer would type it into a search or say it at the counter, it belongs in the slot. If only the business says it, swap it for the customer's word or leave it out.

Swap adjectives for specifics. 'Fresh' is a claim nobody can check. 'Order by six for pickup the next day' is something a customer can hold the bakery to. Notice the placeholder. The AI's draft said the bakery opened in 1998, and nobody could find a source. So the line says CONFIRM, in brackets, until the owner tells me. Then run the swap test on every sentence: could a competitor paste it onto their own site unchanged? If so, write what only this business can say, or cut it.

Specific copy makes claims, and claims need sources. For each sentence with a fact in it, find the claim and match it to the claims list you built in research. Baked every morning: the owner says so, and it's on the list. Since 1998: no source anywhere. No source means a placeholder or a cut. And placeholders have to be loud. A quiet one, like 'TBC' in gray text, gets read past and published. Use one format everywhere: square brackets with the word CONFIRM. Then, before anything is reachable, run one text search across every page and file in the project for an opening bracket followed by CONFIRM. You're done when that one search lists every fact still open.

If an AI drafts the copy, give it the slot, the source material and the customers' own words, then read what comes back for the tells. 'It's not just bread, it's a tradition.' Three adjectives where one fact should be. 'Whether you're grabbing breakfast or planning a dinner party.' Words that only exist on websites: nestled, passionate, pride ourselves. And a closing line that says the heading again. None of these is banned. They're the sound of a sentence written for any business, and each one usually sits where a specific fact should go. Find the fact, or delete the line.

Here's the line from the start, rewritten for its slot. It's one line, because the slot says one line. Everything in it comes from the owner, and the year the draft made up isn't in it: that has its own slot, marked CONFIRM, until the owner answers. It's less exciting than the original. It's also the only version a regular reads and thinks: that's my bakery.

If a competitor could paste your sentence onto their site, it isn't finished. Write to the slot, trace the fact, and mark what you can't confirm.

Ask an AI agent for a homepage and you get a styled one: a color, a font, a gradient, a stock photo. Then the review turns into an argument about the gradient, and nobody notices the prices are buried at the bottom.

So solve the structure first, on purpose, before any style exists. Here's the same homepage in gray, with the bakery's real copy. Style gets in the way of these decisions. A gray page keeps everyone looking at the order.

Keep it deliberately unresolved. Grayscale, the system font, no brand color, and boxes labeled with what each image will show. The copy, though, is real, because hierarchy depends on what the words say and how long they are. Lorem ipsum hides both. Sketch on paper, draw boxes, or have an agent build a rough structural page, as long as it lives somewhere separate from the production site.

Now number everything in the order you want it read. Number one is the dominant element. For the bakery, that's the photo of the morning queue, then the headline under it, then the button, then today's bread, then the visit details.

Then test it. Step back from the screen, or blur it, and see what your eye lands on first, then second. Here's a draft where the bread list is set big and dark. Blur it, and the list lands first. The numbers didn't hold. Make the list quieter and squint again. The photo wins, then the headline. Better still, show it to someone for five seconds and ask what the page is about.

If you'd rather have an agent build the rough page, tell it what to leave unresolved, as plainly as this. Without those lines it will reach for a color and a typeface, because that's what a finished-looking page has. Pointing it at the manuscript keeps the real copy in. Pointing it at a separate folder keeps the sketch out of the site, so nobody can mistake it for the start of the build.

Reading order isn't only visual. A screen reader follows the order the page is written in the code, and WCAG asks that the reading sequence can be worked out correctly wherever order affects meaning. So the code says the same order, and at phone width the slots stack in that order too. Decide it here and the build can follow it.

The wireframe's done when each page type has one dominant element, every slot from the content model is placed and numbered, the copy is real, and someone who isn't you reads it in the order you meant. Then style has something to serve.

Decide what the eye hits first and what it reads next while the page is still gray. Style comes after, and it has to keep that order.