Website Page Viability Before Build

A page that survives the decide phase has a clear reader task, a distinct-value case, and a silo it belongs to. The build phase turns that statement into a page design — what the page is, what it must contain, how it is structured, what it links to, and what evidence backs its claims — before any draft is written.

Key Takeaways:

• The build phase is design first, drafting second; the draft inherits the design rather than producing it.
• Intent shape — informational, navigational, commercial, transactional — determines structure, not preference.
• Fact accuracy is a build-phase concern; verification belongs before publication, not after a correction request.
• Internal-link relationships are planned during the design step, not retrofitted after publication.
• Schema is added only when the page genuinely contains the underlying entity.
• Honest depth is a precondition; word count is a consequence, not a target.

Design before drafting

The build phase begins with a one-page design rather than a draft. The design names the reader task verbatim from the decide-phase statement, identifies the search intent shape that matches it, lists the structural sections the page needs to satisfy that intent, names the inbound and outbound internal links the page will hold, and lists the factual claims the page will make and the sources that will support them.

Skipping this step is the most common reason a finished article looks competent but does not perform — the structure follows the writer’s order of ideas rather than the reader’s order of questions, and the internal-link relationships are added after the fact rather than planned in.

Intent shape, not topic

A topic does not determine page shape. Intent does. The same topic — “managed WordPress hosting” — supports very different page shapes depending on what the reader is trying to do. A reader comparing two specific providers wants a side-by-side comparison structured around decision criteria. A reader new to the concept wants an explanation that defines terms, lists tradeoffs, and recommends a default. A reader ready to buy wants pricing, what is and is not included, and a single clear next step.

Choosing the wrong intent shape for the right topic tends to produce pages that underperform — they show up in results that do not match what the user is doing when they search, and earn impressions without clicks. A page designed for one intent and dressed in surface elements of another — a definition guide with a buy-now button at the top, or a comparison page with a long history of the category — confuses search engines and disappoints readers.

The build phase resolves intent by examining the actual search results for the proposed query. If the top results are comparison articles, the intent is comparison. If they are how-tos, the intent is how-to. If they are a mix, the page either commits to one shape or accepts that it is targeting a less-converged intent and structures accordingly.

Structure that matches intent

Once the intent is resolved, the structure follows. A comparison page is structured around decision criteria with a recommendation. A how-to is structured around an ordered sequence of steps with success checks. A definition guide is structured around progressive disclosure — the short answer first, the longer answer after, the edge cases last. A buyer’s page is structured around what the buyer needs to confirm before committing.

The build phase writes these section headings before the prose is drafted. The drafting step then fills them in. Section headings invented during drafting tend to reflect the writer’s organisation of ideas, which is not always the reader’s order of questions.

Fact accuracy is a build-phase concern

Every claim of fact in a page — a number, a date, a vendor capability, a Google or platform behaviour, a quoted price, a citation of a study — is a liability if it is wrong. The build phase identifies these claims in the design step and identifies the source for each before drafting begins. If a claim cannot be sourced, the page either drops the claim or marks it explicitly as informed opinion rather than fact.

Sourcing claims after the draft is written tends to be skipped, and the unsourced claim ships. Sourcing them before drafting forces the draft to align with what is true, which is cheaper than corrections later.

A useful discipline — for human writers and AI agents alike — is that an unverifiable claim is treated as a candidate for removal rather than as content that needs softening hedging.

Internal-link relationships are planned in advance

A page that arrives without inbound links from elsewhere on the site is harder to discover and tends to perform less well than a page that is wired into the topical cluster around it. The build phase names the inbound links the new page will receive and the outbound links the page itself will contain.

This means small edits to existing pages are part of the build of a new one. The edit is not optional polish — it is part of how the new page becomes part of the site rather than a stranded URL.

Outbound links from the new page are similarly planned, not added during drafting. The page links to its parent pillar, to closely related sibling pages, and to deeper-detail pages where the reader who wants more would go next. Random links inserted to “improve internal linking” are not the goal; planned links that match the reader’s likely next move are.

Schema is added only when honest

Structured data is useful when the page genuinely contains the entity the schema describes. A Product schema on a page that is a comparison guide rather than a product listing is misleading, even if the page mentions products. A FAQPage schema on a page that does not contain a real Q&A section is similarly dishonest.

The build phase decides which schema applies, if any, based on what the page actually contains. Adding schema to win a rich result that the page does not warrant tends to backfire — Google removes the eligibility, and the page is left with a misleading markup it now needs to clean up.

Depth as a precondition

A page that addresses a reader task fully tends to be longer than a page that addresses it partially, but that is a consequence of doing the job, not a target to hit. Designing a page to a word count usually produces filler. Designing a page to fully answer the reader task usually produces honest depth.

The build phase does not commit to a word count. It commits to a structure that answers the reader task end to end, and accepts whatever length that takes.

Ready for drafting

A page that has completed the build-phase design is ready to be drafted — by a human, by an AI agent, or by both. The draft inherits the structure, the intent shape, the sourced claims, the internal-link plan, and the schema decision. What remains is execution, not design.

A draft begun before this design exists tends to invent the design as it goes, which is the slower path to a worse page.