What this stage finalises
This is the final inspection stage for a website that is already close to launch. Agent Mode acts like the inspector, not the builder.
Start with factual checks: URL scope, desktop, mobile, visitor flows, SEO, accessibility, and consent. Then run a point-of-view review, turn the findings into a prioritised fix queue, and confirm only the approved fixes.
Steps
Guide
Lock The URL Scope First
Start with scope, not opinions. Agent Mode needs to know which local, staging, or production URLs belong to the launch review.
List the homepage, priority conversion pages, content templates, legal pages, form paths, confirmation states, and any translated or responsive variants that matter.
Also name what is out of scope. If old routes, hidden experiments, or unfinished pages are not part of launch, the agent should not create tasks for them.
Run The Desktop Functional Check
Open the priority pages on desktop and check the basic website experience before judging quality.
Confirm layout, navigation, page hierarchy, spacing, media, links, calls to action, forms, footer, hover states, and the main conversion path.
Look for broken layout, repeated content, missing sections, dead links, weak trust signals, or copy that no longer matches the offer.
Run The Mobile Functional Check
Mobile needs its own pass because many launch issues only appear on small screens.
Check the menu, text wrapping, tap targets, sticky elements, forms, media crop, button visibility, section order, and whether key content appears before weaker supporting content.
The goal is not to make mobile identical to desktop. The goal is to confirm that the mobile visitor can understand the offer, move through the page, and take action without friction.
Test The Main Visitor Flows
After layout checks, follow the actual journeys a visitor might take.
Check whether a first-time visitor can understand the offer, move from the homepage to a priority page, use the navigation, complete a form, reach a confirmation state, and recover if something does not work.
Flow issues are launch risks because they block action. Treat broken forms, unclear next steps, confusing menus, mismatched calls to action, and dead-end pages as higher priority than visual preferences.
Check SEO, Accessibility, And Consent
Keep this pass factual and evidence-based. Do not turn it into a long strategy audit.
For SEO and AEO, check titles, descriptions, headings, internal links, answer-style sections, crawlability, indexation rules, canonical logic, and obvious schema candidates.
For accessibility, check contrast, keyboard access, focus states, alt text, labels, heading order, readable structure, and touch targets. For consent, check analytics events, form tracking, cookie banner behaviour, blocked scripts, cookie categories, and external setup notes.
Prepare The Stakeholder Review Pack
Only after the functional checks are complete should the review move into judgement.
Prepare a short review pack with the website URL, intended audience, business goal, priority pages, original benchmark links, must-have scope, launch constraints, and known decisions that should not be reopened.
Also define what counts as a valid issue: broken flow, unclear message, weak trust signal, mobile friction, missing legal or trust content, visual inconsistency, or a visible gap against the benchmark set.
Run A Point-Of-View Review
A point-of-view review is different from a generic audit. The agent should review the site from a defined perspective, such as a first-time visitor, a stakeholder checking launch readiness, or a business owner comparing the result against the benchmarks.
Use strict wording: review from this point of view, compare against these benchmarks, and return only issues that affect trust, clarity, conversion, usability, mobile experience, SEO visibility, accessibility, consent, or launch quality.
This keeps the review practical. The agent is not voting on taste. It is looking for the few things that could still damage the final result.
Create The Prioritised Fix Queue
The output should not be a long report. A final review is only useful when it becomes a clear repair queue.
Sort findings into three groups:
must fix before launch,quick polish if time allows, andlater or ignore.Every must-fix item needs a page, component, issue, evidence, why it matters, suggested fix, priority, and acceptance check. If the agent cannot show evidence, the issue should not block launch.
Hand Off Only Approved Fixes
Keep review and implementation separate. The review agent finds issues, the owner approves the queue, and the coding agent receives only the approved fixes.
For Codex or another builder, keep each task small and specific. Tell it to preserve the existing style, avoid unrelated redesigns, and report the files changed plus checks run.
Do not let the fix queue become a second build brief. If a finding requires a broad redesign, new positioning, or new page strategy, move it back to the right earlier stage instead of forcing it into launch finalisation.
Confirm Fixes Without Reopening The Project
After approved fixes are applied, run one final confirmation pass. This pass should verify the accepted items, not search for new ideas.
Use the same URL scope, benchmark links, priorities, and acceptance checks. Ask for a short status for each approved item: fixed, still broken, or needs human judgement.
If the confirmation pass finds a large structural problem, do not patch around it at the end. Mark it as a separate follow-up or move the project back to the relevant earlier stage.
Be Aware
The agent gives compliments instead of launch issues.
Use stricter wording: be critical, do not compliment, compare against the benchmarks, and return only prioritised fixes with evidence.
Functional QA and POV review get mixed together.
Run factual checks first. Only move into stakeholder judgement after URL scope, desktop, mobile, flows, SEO, accessibility, and consent have been checked.
The review becomes a redesign request.
Bring it back to launch readiness. Ask what must change before launch, what can wait, and what should be ignored.
The benchmark comparison becomes too literal.
Treat benchmarks as quality references, not templates to copy. Differences matter only when they hurt the stated business goal.
The fix queue is not actionable for implementation.
Require page, component, visible problem, evidence, expected result, and acceptance check for every important item.
The implementation agent receives too much freedom.
Send only approved fixes. Tell it to preserve the existing style, avoid unrelated redesigns, and report the files changed plus checks run.
The final confirmation pass opens new large tasks.
Limit confirmation to approved fixes. Move broad structural issues back to the relevant earlier stage or save them as post-launch follow-up work.
The agent sees private or sensitive data during review.
Use public preview links and sanitised screenshots where possible. If login is required, supervise the session and avoid exposing unnecessary account data.
Return to the Main Guide?
Main guide
Start Your Website Factory
Review & Finalisation Script
Agent Mode
Review and finalise this website before launch.
Inputs:
- Website URL or URL list:
- Intended audience:
- Business goal:
- Priority pages:
- Priority visitor flows:
- Benchmark links:
- Launch constraints:
- SEO, accessibility, tracking, and consent requirements:
- Known decisions that should not be reopened:
If any required input is missing, stop and ask for it before reviewing. Do not invent missing values.
Start with pre-launch functional checks:
1. Confirm URL scope and list anything out of scope.
2. Check desktop layout, navigation, content clarity, spacing, media, links, calls to action, forms, and conversion flow.
3. Check mobile layout, text wrapping, tap targets, menu behaviour, media crop, forms, button visibility, and section order.
4. Test the main visitor flows from first impression to intended action.
5. Check SEO and AEO basics: titles, descriptions, headings, internal links, crawlability, indexation rules, canonical logic, and obvious schema candidates.
6. Check accessibility basics: contrast, keyboard access, focus states, alt text, labels, heading order, readable structure, and touch targets.
7. Check tracking and consent basics: analytics events, form tracking, consent banner behaviour, blocked scripts, cookie categories, and external setup notes.
Then run a point-of-view review from the perspective of a first-time business visitor and a stakeholder checking launch readiness. Compare the site against the benchmark links. Be critical and concise. Do not compliment the work unless it explains a decision.
Return only a prioritised fix queue with:
- page
- component
- category
- issue
- evidence
- why it matters
- suggested fix
- priority
- acceptance check
Use only these priorities:
- must fix before launch
- quick polish if time allows
- later or ignore
Separate launch risks from taste preferences. Do not redesign the site. Do not reopen broad strategy, positioning, or structure tasks unless they clearly block launch.
End with:
1. a short implementation handoff prompt for the approved fixes
2. a confirmation checklist that verifies accepted fixes without reopening the whole project