A prompt for planning an SEO-friendly site structure before you build

The prompt to use before you build

This one is not tied to a platform. Use it in any AI assistant, then hand the result to Lovable, Bolt, Replit, Cursor or a developer as the brief. Fill in the bracketed business details as fully as you can, because the quality of the plan depends on them.

Help me plan the structure of a new website before any of it is built. Do not write code or page copy. Ask me questions if you need more information, then produce the plan.

About the business
- What it does: [one or two sentences]
- Who it serves: [customer types and locations]
- How people make contact or buy: [form, booking, phone, purchase]
- Services or products: [list them, and say which matter most commercially]
- Things people ask before they buy: [questions you hear regularly]
- Existing website or URLs to preserve: [none / list]

Produce, in this order:
1. PAGE INVENTORY. A table of every page the site needs, with: page name, the one main purpose, the search intent it serves (what a person would be trying to do or find out), and whether it should be indexable. Do not suggest separate pages for topics that are too thin to justify one. If two ideas serve the same intent, combine them and explain why.
2. URL MAP. A proposed URL for each page: short, lower case, hyphen-separated, descriptive, with no dates or file extensions, and logically nested only where the hierarchy is real. Mark which URLs must remain stable for the life of the site.
3. NAVIGATION. The primary navigation, footer links and any secondary navigation. Say which pages are no more than two clicks from the homepage.
4. INTERNAL LINKS. For each important page, list three to five contextual links to other pages with suggested descriptive anchor text. Do not use "click here" or "learn more".
5. PAGE OUTLINES. For each indexable page, a proposed H1 and the H2 headings, with no copy.
6. KEEP OUT OF SEARCH. List pages that should be noindex or sit behind a login, such as thank-you pages, account areas and internal search results, and say why.
7. TECHNICAL REQUIREMENTS FOR THE BUILD. A short checklist I can give the builder: content present in the delivered HTML, unique title and description per page, canonical tags, a real 404 page, an XML sitemap, robots.txt, and redirects if URLs are changing.
8. RISKS AND ASSUMPTIONS. What you assumed and where my answers were thin.

Do not promise rankings or traffic. Use UK English.

The prompt asks for a plan and nothing else, which stops the assistant jumping to a design before the structure is settled.

When to use it

Use it before the first build prompt. Changing a site’s structure after launch means renaming URLs, setting redirects and rebuilding navigation, all of which are avoidable if the structure is right at the start.

It also helps when a project has grown through many separate prompts and nobody can say how the pages relate. Run it against the intended structure, compare it with what exists, and decide what to merge, remove or redirect. If a site already exists and URLs will change, plan the redirects carefully and read about migration and release checks before you proceed.

What it checks and produces

Strictly this prompt produces a plan rather than checking a finished site, but the eight outputs are built around the problems that undermine generated sites later:

• Page inventory by intent. Each page has one job and one kind of visitor in mind, which prevents overlapping pages competing with one another.
• Thin-page avoidance. The assistant is told to combine topics that do not justify their own page.
• Stable URLs. Short, descriptive paths that can last.
• Navigation depth. Important pages should be easy to reach from the homepage.
• Contextual links with real anchor text, because internal links tell crawlers and readers how pages relate.
• Page outlines. A heading structure agreed before the copy is written.
• Private pages. A deliberate list of what stays out of search.
• A builder checklist. Technical requirements stated up front, not discovered at launch.

What the assistant may still get wrong

• It does not know your market. It cannot see search demand, competitors or what people in your sector actually type. Check the proposed pages against real keyword and search results data before committing.
• Too many pages. Assistants tend to propose a page for every thought. Challenge any page you cannot write something genuinely useful for.
• Generic structures. Without detail, you may receive the standard home, services, about and contact layout. Specific answers produce a specific plan.
• No knowledge of platform limits. A builder may not support every URL pattern or rendering option. Test one sample page before building the lot.
• No guarantee of visibility. A good structure makes content easier to find and understand. It does not make a site rank.

Treat the output as a draft for human review. Our platform guides explain how each builder is supported, which affects what is practical.

A worked example

This is an illustrative scenario, not a client result. Imagine an independent physiotherapy clinic planning a new site for patients in one town.

The assistant’s inventory might propose a homepage, one page each for back pain, sports injuries and pregnancy physiotherapy, a page about the practitioners, a fees and booking page, and a contact page. It might suggest combining “neck pain” and “back pain” if the clinic’s answers show it does not have enough distinct things to say about neck pain alone.

Its URL map could use /services/back-pain and /about/our-team. The internal-link section would then connect each service to the booking page with anchor text such as “book a back pain assessment”. The thank-you page would be listed as noindex.

You would test the plan against what patients genuinely search for and ask, trim anything weak, then give section 7 to the builder. After the build, confirm each page on the live domain.

Next step: check the finished site

A plan is only as good as the build that follows it. Once pages exist, they need testing on the live domain for crawlability and indexability. If you would like help turning a plan into a build brief, see how we support sites built with AI tools.

Book a site review and we will check the live pages for you, or send us a message if you would like to describe the problem first. You can also browse the rest of the resources hub.