Build one page a visitor can actually use
You chose the page. Now make it useful before you make it long. Codex should organize your evidence into an answer, not pad a keyword into a blog post.
Definition of done: A publish-ready draft with a direct answer, proof, limits, a useful next step, and every uncertain claim marked for review.
Allow 60 to 90 minutes. Bring an approved First Traffic Page Decision, its Proof Request, and your Fact Pack. You are creating a reviewable draft, not giving Codex permission to publish, change a CMS, or invent the missing parts.
Write the brief before the draft
Create first-traffic-page-brief.md with: customer question; page promise; five facts from the Fact Pack; one limitation; page to link to; visitor action. Then run:
Read my First Traffic Page Decision, Traffic Mission, and Fact Pack: [paths].
Create first-traffic-page-draft.md. Start with a direct answer in 2-3
sentences. Then use only sections needed to help the visitor decide: fit,
steps or comparison, proof, limitation, and next action. Use confirmed facts
only. Mark missing claims NEEDS OWNER FACT. Include suggested internal links
but do not add them. Do not publish, edit site files, invent examples, prices,
reviews, outcomes, or sources.Fill the brief with actual decisions, not headings
Here is a compact brief for the bookkeeping page chosen in Lesson 9:
Customer question: What records should a freelance designer gather before a
self-assessment deadline, and when might monthly bookkeeping help fit?
Page promise: This checklist explains what to gather before a discovery call
and where the monthly service begins and ends.
CONFIRMED facts: monthly bookkeeping is offered to sole-trader designers;
discovery call precedes onboarding; onboarding checklist exists; personal tax
return filing is excluded; documented handoff process exists.
Limitation: We cannot yet state whether service is Bristol-only or UK-remote.
Link to: /bookkeeping-for-designers after the checklist explains service fit.
Visitor action: Check whether the stated monthly service scope fits.If you cannot write the limitation, you have not done the Fact Pack work. The limitation is where a trustworthy page keeps a visitor from making the wrong assumption.
Quality check: Every fact in the brief exists as a CONFIRMED Fact Pack row. Do not paste raw research notes or a competitor page and call it proof.
Give Codex the inputs in the right order
Do not paste a pile of notes and say "make it good." Put the inputs under these labels, even if a label has only one sentence:
Input | What to provide | Why it matters |
|---|---|---|
Reader question | The exact question from the First Traffic Page Decision | Stops the draft becoming a broad topic overview |
Direct answer | Your current best answer in plain English | Gives Codex a conclusion to prove rather than a keyword to repeat |
Confirmed facts | Five to ten Fact Pack rows | Supplies information only you can prove |
Limitation | One situation where the offer, product, or advice does not fit | Prevents overclaiming |
Next action | One relevant booking, purchase, signup, comparison, or page | Gives the visitor a useful route after the answer |
If you cannot provide a direct answer, ask Codex for two possible positions labelled NEEDS OWNER DECISION. Do not let it pick an aggressive promise for you.
Use a skeleton before asking for prose
Most first traffic pages need only this structure:
Title: the customer's decision in ordinary language
Opening: direct answer in two or three sentences
Section 1: who this is for and when it applies
Section 2: the decision criteria or steps
Section 3: confirmed proof, process, or example
Section 4: limitation, alternative, or when not to choose this option
Section 5: next useful actionA product page may lead with a fit table. A local emergency-service page may lead with a safety boundary and booking route. A SaaS comparison may lead with a decision matrix. The non-negotiable part is answer, evidence, limitation, and next action.
Ask for a section plan before you ask for full prose
For beginners, an outline review is cheaper than a 2,000-word rewrite. Use this first:
Read first-traffic-page-brief.md and fact-pack.md. Create a page plan, not
prose. For each section, show: the visitor question it answers; the CONFIRMED
Fact Pack rows it will use; any limitation; and the next section or action it
should lead to. Include no more than six sections. Do not invent examples,
write page copy, edit files, or publish.Approve the plan only if its sections have distinct jobs. For the checklist, the plan could be: direct answer; records to gather; when monthly help fits; what the service does not include; what happens after a discovery call; next action. It does not need a long history of bookkeeping, a generic SEO FAQ, or a competitor comparison.
If Codex gives you a generic article outline, reply:
This outline does not use the approved brief. Rewrite it as a decision page
for the named customer question. Beside every section, cite the Fact Pack row
that allows it. Delete sections with no visitor decision or confirmed fact.Review the draft in two passes
First pass: claims
Open the draft beside the Fact Pack. Highlight every number, date, price, capability, location, customer outcome, comparison statement, and policy claim. Each highlight needs a status:
CONFIRMED: present in the Fact Pack with a source.NEEDS OWNER FACT: may be true but you have not supplied proof.REMOVE: vague, unnecessary, or unverifiable.
Compare first-traffic-page-draft.md with fact-pack.md. Create a Claim Review
table with: draft claim, status (CONFIRMED / NEEDS OWNER FACT / REMOVE), Fact
Pack source, and required action. Do not rewrite the page or add claims.Second pass: visitor value
Read only the title, opening, headings, and final action. A visitor must be able to answer: Is this for me? What should I decide? What proof makes it credible? If not, change the structure before polishing sentences.
Run a third pass for page mechanics
Before anyone moves the draft into a CMS or repository, ask Codex for a mechanical handoff:
Read the approved draft, Claim Review table, and first-traffic-page-brief.md.
Produce a CMS-neutral implementation sheet with:
1. Proposed URL slug and title.
2. Heading outline in order.
3. Internal link source sentence, anchor text, and destination.
4. CTA text, destination, and required owner confirmation.
5. Image or table needs, with alt text and what each visual proves.
6. Metadata options that reflect the finished page only.
7. A publish checklist and rollback note.
Do not edit a CMS, commit files, upload images, create redirects, publish, or
change tracking.This is the point where a developer or CMS editor can work safely. If you do use Codex in a local website repository, give it the implementation sheet and ask it to list files it would change before it touches anything. Require a diff and review the diff against the Fact Pack.
Review it like the visitor
Ask | Pass condition |
|---|---|
Does the opening answer the question? | The visitor knows the page's conclusion before scrolling |
Is the advice specific? | It uses your proof, process, limits, or examples |
Is the page honest? | It says who does not fit or what it cannot prove |
Is there a next action? | The action follows naturally from the decision |
If the page could be published unchanged by ten competitors, add better first-party proof or narrow the question. Do not add filler.
Save a handoff for the next lessons
Create first-traffic-page-handoff.md:
# First Traffic Page Handoff
- Customer question:
- Page promise:
- Confirmed facts used:
- Claims needing approval:
- Page to link from:
- Page to link to:
- Visitor action:
- Draft path:
- Reviewer:This small file is the input for clarity, linking, and publishing review. Save it even if you are working alone.
What to do when the draft is weak
It reads like every competitor page. The brief probably has no distinctive proof. Do not ask for a more persuasive tone. Add a documented process, specific limitation, approved example, or narrower customer question.
It has dozens of `NEEDS OWNER FACT` labels. Stop drafting. Send the owner only the blocking questions, update the Fact Pack, then regenerate the affected sections. A page full of placeholders is not a draft ready for copyediting.
It answers the question but has no next action. Decide whether the page is intended to lead to a service, product, signup, tool, or another guide. If none helps, do not force a sales CTA. Use a useful related page and log the missing conversion path for later.
Save the outline, draft, Claim Review, implementation sheet, and handoff in one folder. A clear record lets you improve one element in Lesson 11 instead of losing the original reason the page was written.
Review the draft with a real page checklist
Before calling a draft publish-ready, check it in this order:
Check | What to inspect | Stop when |
|---|---|---|
Question match | Title and opening reflect the page decision | The draft answers a broader topic instead |
Fact boundary | Every material claim appears in the Claim Review | A price, outcome, capability, location, or policy has no source |
Reader path | Headings move from answer to evidence to next action | Two sections repeat the same point or a section has no job |
Link path | The page points to one genuinely useful destination | The CTA or internal link is unrelated to the question |
Mobile scan | Short paragraphs, useful table labels, readable CTA | A key instruction depends on a dense wall of copy |
For a CMS editor, turn the checklist into a pre-publish comment sheet. For a repository, ask Codex to run the available local checks only after it has shown the proposed file list. The human approval is for the content and the actual website change, not for a generic green checkmark.
A bad draft and the correct repair
Bad opening: Bookkeeping is important for every freelancer. Our friendly team can save you time and reduce stress.
It fails because it does not answer the decision, makes an unsupported outcome claim, and gives no evidence or scope.
Better direction: This checklist helps sole-trader designers gather records before deciding whether monthly bookkeeping support fits. It covers the documented onboarding handoff and does not replace personal tax-return filing.
It is not clever, but a reader can understand it. From there, the page can earn trust with the actual checklist and a clear service boundary.
Do not let formatting hide unfinished work
Tables, image placeholders, FAQs, metadata, and polished headings can make an unfinished draft look finished. Before publishing, scan for TODO, TBD, NEEDS OWNER FACT, bracketed placeholder text, and source notes. Resolve or remove each one. A reader should never see the internal evidence boundary; they should see a page that states only what you can support.
Course map
Next: Turn One Page Into the Clearest Answer in Google and AI Search. Save the approved draft and your review notes.
Author: Martin Hayes, GEO Playbook Builder for 200+ Execution Checklists at Auspia. Martin writes practical, reviewable content workflows.
Use this sequence for the assignment: start with a real input, check the evidence, prepare one reviewable output, then choose the reader next step.
