How expertise-led B2B teams build clear official pages, usable evidence and discovery foundations.
Use this guide to review a real buyer journey, not to generate more pages by default. Start with one offer, one decision and the evidence you are allowed to share. Each chapter gives you a check and an action you can discuss with the person responsible.
- Content type: Guide
- Published by: WuWei Logic
- Version v1.0
- Updated: 22 October 2026
In this guide
1. Official facts
Why it matters
A buyer needs to know which organisation is speaking, what it offers and which statements it can stand behind. Small inconsistencies in service scope or availability can create a very different expectation from the one your team intended. A shared record also makes it easier to update information when a service changes.
How to check it
Choose one service page. Underline statements about capabilities, availability, qualifications and results. For each, record the exact wording, the responsible person, a supporting source and when it was checked. Ask whether the source supports the whole sentence or only part of it. Compare the page with the material the sales and delivery teams actually use. Mark gaps or contradictions for review instead of choosing the most attractive version.
Common mistakes
Treating an approved draft as verified truth; using an old brochure as evidence of current availability; or turning one person's estimate into a company-wide claim. A confident tone cannot resolve conflicting evidence.
One practical action
Select the claim most likely to affect a buying decision. Ask its owner to confirm the scope and identify the source. If either is missing, narrow the claim or withhold it until it can be checked.
Use precise evidence labels
| Label | What it means |
|---|---|
| Client-confirmed | A responsible client representative has confirmed the statement and its scope. Record who, when and on what basis. This is an attributed confirmation, not independent verification. |
| Source-supported | An identified source supports this particular statement within its stated scope and date. Check the original material, relevance and limitations; a source can be incomplete or wrong. |
| Pending verification | The statement lacks sufficient confirmation or supporting evidence, or sources conflict. Keep it out of public claims until resolved, or describe the uncertainty explicitly. |
| Interpretation | A professional reading of evidence, not a fact. Identify the evidence and explain the reasoning and limitations. |
| Hypothesis | An idea to test, not a fact or a promised outcome. State what observation would support or challenge it. |
| Open question | A specific gap that still needs an answer. Assign a responsible person and a next review point. |
Confirmation and source support can coexist. Keep evidence status separate from statement type: an interpretation or hypothesis does not become a fact when someone approves it. Approval is not proof of truth; permission to publish is a separate decision.
2. Buyer questions
Why it matters
A useful website helps someone make progress with a decision. A technical reviewer may need fit conditions, while a budget holder needs to understand what is included and who must contribute. Answering only broad awareness questions can leave the people closest to a decision without the information they need.
How to check it
Review existing sales notes, support questions and proposal objections that you are permitted to use. Remove identifying details from working summaries. Write the question in the buyer's own plain language, name the role asking it and identify the decision it affects. Follow the current website path from the relevant service page to an answer and evidence. Record where the path ends without an answer, or where the answer depends on a private conversation.
Common mistakes
Inventing questions from keyword lists alone; treating every audience as one person; publishing sensitive conversation details; or creating an FAQ whose answers simply repeat a sales pitch. Frequency is useful context, but one rare high-stakes question may deserve priority.
One practical action
Pick one unanswered question that blocks an enquiry. Write a direct answer with a subject-matter owner, note its limits and choose the existing page where a buyer would reasonably expect to find it.
3. Decision pages
Why it matters
A decision page is a page that helps a visitor decide whether an offer fits their situation. It need not be a new page type. A service or application page can do the job when it makes the audience, problem, answer, evidence, limits and next step clear enough to discuss with a colleague.
How to check it
Read a priority page as someone who has not spoken to your team. Can you identify who it is for, what is included, what the buyer needs to provide and when it is not a fit? Check whether an important claim leads to specific evidence rather than another broad promise. Ask a colleague unfamiliar with the offer to explain it back. Record confusion in their words rather than treating your own familiarity as proof that the page is clear.
Common mistakes
Replacing useful detail with slogans; hiding important exclusions at the end; presenting an illustrative example as completed work; or asking for a call before giving enough context to judge fit. A stronger call to action cannot repair a missing answer.
One practical action
Rewrite the opening of one existing page to state the audience, the question it answers and one important fit condition. Add a descriptive link to relevant evidence and a next step that matches the buyer's readiness.
4. Evidence pages
Why it matters
Evidence lets a reader inspect the basis of a claim. A useful case or resource explains the situation, the work, the source material and the limits of what can be concluded. It should help a buyer understand the work even when there is no impressive result statistic to display.
How to check it
For a proposed case, distinguish client work, authorised anonymised work, illustration and public-source analysis before drafting. Check that permissions cover the material you want to publish. Separate observations from explanations of why they happened. If a number is used, record its source, period, definition and comparison, and say what it cannot establish. Identify a responsible author or reviewer and make the next review point meaningful, such as a change in service scope.
Common mistakes
Using a logo as a substitute for permission; implying that public analysis is a partnership; removing a name while leaving identifying details; or claiming that a website edit caused revenue without sufficient evidence. Permission alone does not establish accuracy.
One practical action
Create a short evidence note for one claim: what happened, where the information comes from, what can be published and what remains uncertain. If client evidence cannot be shared, use a clearly labelled illustration instead of inventing proof.
These are editorial safeguards, not legal advice. Refer permission, confidentiality or contractual questions to the person qualified to resolve them.
Google Search Central: creating helpful, reliable, people-first content
5. Technical foundations
Why it matters
Even a helpful page can be difficult to discover if it is disconnected from the site or unintentionally excluded. Technical checks distinguish access problems from content questions. They establish what can be observed, not whether a search system will choose to show a page for a particular query.
How to check it
Select a small set of intended public pages and ask the website owner to record the URL, access result, indexing directives, preferred canonical URL, sitemap inclusion and internal links. Check the visible page title and whether the essential answer is available as text. When authorised Search Console access exists, record the indexed-page observation separately from a live accessibility check; they answer different questions. Label unavailable evidence as unknown rather than reporting a pass.
Common mistakes
Confusing crawling with indexing; submitting a sitemap as if it guarantees inclusion; directing canonical signals to an unrelated page; or relying on a search-result screenshot as a complete technical diagnosis. Do not remove intentional privacy protections to improve a visibility assessment.
One practical action
Choose one important public page that lacks a clear path from a relevant service or resource page. Request a descriptive internal link, then record whether it reaches the intended destination. Assign unresolved indexing questions to the website owner instead of guessing.
Read the relevant primary guidance
Google explains that robots.txt manages crawling; robots.txt is not an access-control or reliable deindexing mechanism. A URL blocked from crawling may still appear in search. Keep private material behind appropriate access controls.
Google Search Central: introduction to robots.txt
Google must be able to crawl a page to see its noindex directive. A robots.txt block can prevent that check. Ask the site owner to distinguish intended exclusions from accidental ones before changing anything.
Google Search Central: block indexing with noindex
A sitemap helps discovery but does not guarantee indexing. Check that it represents the public URLs you intend to make available, rather than treating submission as a completed visibility result.
Google Search Central: sitemap guidance
Canonical annotations express a preferred version of duplicate or very similar content. They are signals, not a command that forces Google to select your preferred URL. Keep references to the preferred page consistent.
Google Search Central: canonical URLs
Use descriptive links that lead to relevant pages. Google recommends normal anchor links with href destinations it can follow, rather than navigation that depends only on scripted click actions.
Google Search Central: crawlable links
Google says its existing SEO foundations also apply to AI Overviews and AI Mode; there is no special technical shortcut. Eligibility does not guarantee appearance. This is guidance about Google, not a promise about every AI service. WuWei does not guarantee indexing, rankings or AI citations.
6. Visibility Systems scorecard
Why it matters
A useful assessment makes uncertainty visible and helps a team choose its next action. It should not turn a quick review into a scientific-looking score. The questions below concern the pages and evidence you actually inspect, not the whole business or a forecast of commercial performance.
How to check it
Choose a scope, such as one service page and the evidence linked from it. For each question record the page or source, what you observed, who checked it and the review date. Use Ready to review when evidence is available for an owner to inspect; Needs work when you can name a gap; Unknown when you cannot check; and Not applicable only with a written reason. Ready to review is not an independent certification or a claim that the page is indexed.
Common mistakes
Adding the labels into a score, comparing the result with an invented industry average, or treating missing access as a successful check. This is not a numerical benchmark. Search visibility, enquiries and buyer understanding are different observations and should not be combined into one unsupported performance claim.
One practical action
Choose the highest-consequence gap, not the easiest cosmetic change. Assign an owner and a concrete next action. Set a review date appropriate to the work and compare the evidence again after that action. Keep unresolved items visible even when the page is approved for publication.
Questions to assess
| Question | Evidence to inspect | Owner / Next action |
|---|---|---|
| Can a visitor identify the business, audience, offer and next step? | The service page and a reader's explanation of it. | Content owner: clarify the first point a reader could not explain. |
| Can a buyer find an answer for a high-stakes question? | The question, the page that answers it and the route to that page. | Sales lead: identify one decision-blocking gap. |
| Is there public evidence behind important claims? | The claim, its supporting source and its publication permissions. | Claim owner: support, narrow or remove an unsupported claim. |
| Is a responsible person, author or team visible? | A reader-visible responsibility statement and an appropriate next step. | Editorial owner: make responsibility clear without exposing private details. |
| Are priority pages crawlable, indexable and internally connected? | A dated technical review separating eligibility from observed indexing. | Website owner: investigate exclusions or record the evidence still needed. |
| Is important information dated, reviewed and maintained? | Actual review records, source dates and a named maintenance owner. | Page owner: check a changed claim before updating its review date. |
Record each result separately: assessment label, evidence, observation, owner, next action and review date. There is no default pass, total score or recommended percentage. A review date records a real check; changing a timestamp alone is not a review.
Continue exploring
A Foundation Sprint starts with an agreed scope, responsibilities and review points. Bring the page or buyer question that is hardest to explain today.