The short version

The key ideas.

  • Give each important page a distinct buyer question and a useful next step.
  • Treat discovery, indexing, content quality, and business results as separate problems.
  • Build an ownership and measurement plan alongside the website itself.

Start with the decision your customer is making

Search planning often begins with a spreadsheet of phrases. A more useful first document is a map of customer decisions. What problem sends someone looking? What would make them consider your business? What evidence would they need before making contact? The answers establish what the website needs to say, which pages deserve their own address, and where a visitor should go next.

Separate discovery questions from selection questions. Someone learning why their current website is difficult to update needs an explanation. Someone choosing a development partner needs scope, approach, relevant work, and commercial clarity. Forcing both needs into a single page usually produces an awkward compromise: too promotional for the learner and too vague for the buyer.

For each proposed page, write a simple brief: intended reader, decision, essential answer, available evidence, and next action. Add a page only when it has a distinct job. A small site with credible service explanations and strong supporting material can be a better starting point than a sprawling publication that nobody can maintain. The useful planning unit is a resolved question, not a keyword quota.

Make the important material reachable

A custom build should have an explicit search acceptance check. Can someone reach each important page through a normal link? Does the page return the expected content? Are public pages accidentally blocked? Does the mobile experience contain the same essential information? These checks belong in delivery, alongside checking that the contact form works.

Google's SEO Starter Guide explains that links help Google discover content and recommends using Search Console's URL Inspection tool to see how a page is received. It also makes clear that no checklist guarantees a first-place ranking. Technical work removes obstacles; it does not create demand or establish a business's credibility by itself.

Ask the development team to document preferred URLs, redirects from replaced pages, metadata ownership, and the process for publishing future pages. Decide how duplicate versions will be handled before navigation or campaigns generate them. A launch inventory should record old addresses and their intended destinations. Rebuilding the appearance of a site without preserving useful routes can make a familiar business unexpectedly difficult to find.

Test representative page types, including a service page, article, case study, and error page. The goal is confidence in the publishing system, not merely a clean homepage.

Make expertise visible in the answer

A service page should do more than declare that a team is experienced. It can explain what the service includes, what changes its cost or timeline, what the client must supply, and what would make the engagement unsuitable. These details allow a prospective customer to assess fit without first arranging a meeting.

Evidence needs context. A screenshot demonstrates an interface; it does not demonstrate a revenue increase. A project description can establish the brief, constraints, and delivered scope. If a performance result is included, explain the measurement period and what else changed. Where outcomes were not measured, a precise account of the work is more useful than a confident adjective.

Build articles around knowledge the business can contribute. A manufacturer might explain a material tradeoff using its own specifications. A consultant might show how to prepare for a workshop. A studio might describe the decisions behind a content model. Each topic earns its place by helping an intended reader act.

Review drafts with someone close to the work. Ask what is missing, which claim needs support, and where the answer depends on circumstances. Specific limitations often make an explanation more credible because they reveal the judgment behind it.

Connect pages around a real path

Hypothetical example: a small architecture practice wants more enquiries for commercial renovations. Its original site has a gallery and a general contact page. Adding the phrase “commercial architect” throughout the gallery would leave the buyer's main questions unanswered.

A useful structure could include one commercial renovation service page, several projects with relevant constraints, and an article on preparing a feasibility brief. The service page explains engagement stages and who commissions the work. The project pages describe building type, scope, and approved images. The preparation article helps a potential client gather information before a conversation. Each page points to the next useful resource.

This structure is a proposed approach, not a prediction of search performance. Its value can be assessed by asking a prospective buyer to complete a task: determine whether the practice handles their type of project and identify what to prepare. If they cannot, the team has a concrete content problem to fix.

Apply the same thinking to geography. Create location content when the location changes the service, evidence, or customer question. Swapping city names across otherwise identical pages is a poor substitute for explaining genuine local relevance. Every additional page creates a maintenance obligation.

Read search data in stages

A useful measurement discussion separates four questions. Is the page discoverable? Is it appearing for relevant searches? Are suitable visitors arriving? Are those visitors progressing toward a meaningful business outcome? A problem at one stage calls for different work from a problem at another.

A page receiving irrelevant enquiries may need clearer positioning, even if its traffic is growing. A useful page with little visibility may need better internal connections, stronger evidence, or time to establish a baseline. A page with visits but no enquiries may be serving a learning task successfully; its next step could be another resource rather than an immediate sales request.

Define what counts as a qualified enquiry with the person who handles leads. Record the criteria consistently, such as service fit, geography, or project readiness. Google Analytics distinguishes lead generation from later qualification in its recommended lead events. That distinction is helpful even when a small team uses a simpler reporting process.

Review the same page groups over meaningful periods and annotate major changes. Avoid declaring a redesign successful because one week looks better than the last. Seasonality, campaigns, and changes in the offer can all affect the interpretation.

Give every important page a role in the customer journey

Map a short route through the site before expanding the sitemap. A service page explains what can be commissioned. A relevant project demonstrates the scope and quality of the work. An article helps the reader prepare for a decision. The contact page collects enough context to start a useful conversation. Each page should still answer its own question when a visitor arrives directly from search.

A community platform needs the same clarity. Nocturnum’s Nikken / Team Diamond Global project is a website for a mastermind platform within the Nikken network. Explaining that relationship accurately gives the project context without implying that a community website is the corporate website of the entire global company. Precise naming helps a reader understand whose work they are seeing.

Write a one-line purpose for each proposed page and remove those that merely repeat another page’s answer. Link related material with labels that explain the destination. The website brief can capture this map, while the launch review checks that the routes actually work. This is information architecture, not a promise of search rankings.

A practical launch and ownership checklist

Before approving the design, choose the pages that matter commercially and complete their briefs. Confirm that the business can supply the promised evidence. Before approving development, agree who can update page titles, descriptions, navigation, and content without rebuilding the site. Before launch, inspect the routes that existing customers and search visitors already use.

Use this action checklist to make the work reviewable:

  • List the main buyer decisions and assign a useful page to each.
  • Check public page access, internal links, mobile content, and redirect destinations.
  • Replace unsupported claims with evidence or a narrower statement.
  • Define qualified enquiries and verify that their source can be reviewed.
  • Assign an owner and review date to commercially important content.
  • Schedule a post-launch review with specific questions to answer.

Keep a short backlog after launch. Rank work by the seriousness of the problem, the number of important pages affected, and the effort required. Fix a broken enquiry route before polishing an incidental description. Update an obsolete service offer before commissioning another general article. A custom website becomes a stronger search asset when its structure and knowledge remain accurate as the business changes.

Sources & further reading

From perspective to practice

Build the structure around the questions that matter

We can help connect your services, project evidence and useful content in a website that is clear to explore and maintain.

Discuss your website structure Explore services & pricing