Website Planning
Planning an SEO Website Around Your Business and Your Buyers
A website plan should explain why each page exists. It should show whose question the page answers, what the business can truthfully say, and where the reader can go next.
The result is more useful than a menu sketch. It becomes a working agreement for writing, building, and reviewing the website. It also makes omissions visible before they become expensive changes.
This guide covers the planning stage of a complete WordPress website. Its output is a page map and content plan, with a defined first release and room for later development.
Begin with an offer inventory
Describe the business in terms of deliverable work or available products. Separate what you do now from what you might offer later. A topic that would attract interest but lead to work you cannot fulfill should not quietly become part of the core website.
For each offer, record:
- The customer and situation it is intended for.
- The problem it addresses and the result the customer receives.
- What is included, excluded, or dependent on a separate arrangement.
- The information or materials needed from the customer.
- Factors that change suitability, cost, or delivery.
- The evidence available to support the description.
Use concrete statements. “Complete service” needs an explanation of where responsibility begins and ends. “Fast delivery” needs a basis. If the business cannot yet confirm a claim, mark it for review instead of treating it as approved copy.
This inventory defines the boundaries of the website. Supporting content can explore a subject deeply while remaining connected to an offer the business actually provides.
Find the decisions behind the questions
People can ask different questions while trying to make the same decision. They may also use the same broad term while needing very different kinds of help.
Read competitor pages for the decisions they address. Look beyond their navigation labels. What do they explain about suitability, preparation, alternatives, limitations, cost, and the next step? Which questions receive a real answer, and which disappear into a sales statement?
Combine those observations with the owner’s experience of customer conversations. Support requests, proposal discussions, and reasons people hesitate can reveal questions a competitor has missed.
Keep a distinction between observation and assumption. Seeing several competitors discuss a topic is a reason to examine it, not proof of its search volume or its importance to your particular customers. An inferred intent remains a working hypothesis until stronger evidence is available.
Search-demand research can add another layer when it forms part of a project. The underlying task remains the same: determine the decision that needs an answer. A business owner does not need to purchase a research subscription or learn its interface to participate in that work.
Connect entities rather than collecting terminology
The important entities are the things a reader needs to understand and the relationships between them. On a website project, for example, a domain, hosting account, DNS configuration, and business mailbox are different things. The useful explanation is how they connect and who controls each one.
For your subject, ask:
- What objects, people, systems, or conditions are essential to the decision?
- Which of them depend on something else?
- Which distinctions commonly confuse a buyer?
- What must be checked before the next action is possible?
Use those relationships to organize the explanation. A glossary of terms cannot substitute for an account of how the work fits together. Equally, mentioning every adjacent technology can distract from the decision the page is supposed to support.
Assign one primary job to each page
Write a one-sentence purpose before choosing a final page title. “Help the owner decide what belongs in the first website release” is a clearer assignment than “write something about websites.”
Then define what a successful reading produces. The visitor might be able to prepare materials, compare approaches, test a configuration, understand the scope of a project, or submit a better brief.
Your page map can use the following fields:
| Field | What to record | Why it matters |
|---|---|---|
| Proposed page and URL | A stable, descriptive name and address | Makes the intended structure visible |
| Reader’s situation | What they know and what they need now | Sets the level and scope of the explanation |
| Main decision or task | The answer this page is responsible for | Prevents several pages from doing the same job |
| Essential coverage | Facts, steps, limitations, and checks | Gives the writer a usable brief |
| Available evidence | Owner input, documents, media, reliable references | Separates supported statements from assumptions |
| Parent and related pages | Where context comes from and where detail continues | Plans useful internal links |
| Next action | A practical action, relevant reading, or project inquiry | Connects understanding to progress |
| Release and status | Initial release or later; ready, missing facts, in review | Turns the plan into a production inventory |
Do not use the table as a substitute for thinking. If the same generic decision appears in ten rows, revisit the page boundaries.
Decide when to split or combine pages
Two pages can mention many of the same entities and still serve different purposes. Conversely, changing the heading does not make duplicated advice into a separate useful page.
Keep a subject within the current page when it is a short prerequisite, an explanation needed to understand the main answer, or a minor variation that does not change the recommendation.
Create a supporting page when the reader has a distinct task, the task requires a substantial explanation, and that explanation can stand on its own. The main page should still provide a meaningful answer before offering the deeper guide.
Combine planned pages when they would share the same introduction, decision criteria, advice, and next action, with only wording changes. Review actual drafts as well as the plan: overlap is sometimes easier to see after writing.
Similar vocabulary is not sufficient evidence of harmful competition between pages. The planning concern is unclear ownership of the answer. After launch, search data can help determine whether Google and visitors are finding the intended page.
Give the hub enough substance
A hub should explain the whole subject at the level its reader needs. Someone should be able to understand the overall approach without opening six browser tabs.
For each major section, include the decision, the practical principle, and a way to recognize a satisfactory outcome. Link to a supporting page where implementation or a specialized branch needs more space.
The spoke then deepens that particular job. It should not repeat the hub’s entire introduction or reproduce the same overview under a longer title. Include just enough context for someone arriving directly from search, then move into the specific work.
The parent-child relationship is editorial as well as structural. A nested URL alone does not tell the reader why the pages belong together.
Plan internal links as part of the explanation
Choose the destination because it answers the next relevant question. Use link text that identifies what the reader will find. A link to a launch checklist belongs where the discussion reaches readiness, not in every paragraph that happens to mention a website.
There are three useful connections to review:
- Hub to spoke: the overview leads to detailed implementation or a specialized decision.
- Spoke to hub: the detailed task reconnects with the complete project.
- Related page to related page: one task depends on another, even if the pages belong to different hubs.
For example, infrastructure belongs in the website plan because the site must run somewhere. The detailed server configuration can live in Website Infrastructure. The planning page needs to identify the dependency, not duplicate the server guide.
Check that planned public pages can be reached through sensible navigation or contextual links. Avoid creating an article that exists only in the XML sitemap and has no useful place in the reader’s journey.
Set the boundary of the first release
The first release should cover what a buyer needs to understand and act on the current offer. Prioritize missing answers that would block a decision over peripheral topics that simply add page count.
Review each proposed page against three questions: does a current offer need it; can the business support its claims; and can it be completed well with the available resources? A later-release decision is appropriate when a topic depends on an unlaunched service, missing evidence, or a function outside the current scope.
Do not publish an empty future section merely to show the eventual ambition. Keep the future structure in the plan until it has useful content.
The number of initial pages follows from this review. It is possible to launch a complete first stage while retaining a much larger backlog of worthwhile subjects.
Review the plan with the owner
The owner should be able to recognize the business in the structure without understanding SEO terminology. Present page purposes in plain language and ask for factual corrections: missing capabilities, inaccurate boundaries, unavailable materials, and questions real buyers repeatedly ask.
Flag dependencies that affect the build. A planned store requires product and operational information. A comparison may need specifications. A case study requires a real project and permission to use the relevant material.
I share the structure and content plan during the project. This gives the owner a chance to correct the foundation before the content system is built around it.
Once that foundation is settled, the WordPress and YOOtheme implementation can translate it into manageable content types and templates. A WooCommerce project adds catalog relationships and purchase requirements to the plan.
Frequently asked questions
Should I copy the structure of the strongest competitor?
Use it as evidence of how another business explains its offer. Their services, audience, resources, and history may differ from yours. Extract useful questions and examine their answers; retain only the structure that fits your business and improves the reader’s experience.
Does every service need its own page?
It needs a clear explanation. A separate page is useful when the service has enough distinct scope, buyer questions, and substance to warrant one. Closely related variants may be better explained together. Make the decision from the answer required, rather than from the desire to increase URL count.
Can the website be planned before all the text is ready?
Yes. Planning establishes what needs to be written and which facts are missing. Test the plan with representative content before treating it as final: drafting can expose a section that is too broad, too thin, or too similar to another page.
Do all supporting pages need to sell something?
They should help with a relevant task. A reader may use the advice independently or later choose to request help. The connection to the business should be natural and specific, without withholding the practical answer until someone contacts you.
How detailed should the content brief be?
Detailed enough that a writer understands the reader’s task, required coverage, evidence, boundaries, and related pages. It should leave room for the most suitable explanation instead of forcing every article into the same headings and word count.
What happens when the business adds another service?
Review the existing map first. The new offer may fit within a current hub or justify a new branch. Update affected explanations and links, and make sure the older pages still describe the business accurately. Ongoing expansion belongs in a website development plan after launch.
Apply this planning to your new website
If you want me to build your website, this planning is part of connecting the business to its future content and implementation. Start with what you do and who you serve. I can organize that information into a structure and content plan you can review before the build progresses.