How to Fix SEO Issues with Codex Using Page Evidence

1. Start with a specific observation

Run an audit and select one issue backed by page evidence. For example, a published page can have a title but no description tag. Record the URL and what was actually read. Avoid asking the assistant to “improve all SEO” without a clear scope; that request gives you no reliable acceptance test. In SiteFix.app, choose the issue and generate a task with Codex selected.

2. Let Codex find the relevant source

Open the actual website repository and provide the task. Ask it to read AGENTS.md and inspect the framework, routes, existing metadata, and local conventions. A public audit cannot know whether the description is controlled by a template, route component, CMS, or build-time data. A repair should follow that source of truth. OpenAI’s prompting guidance describes giving the agent concrete task context and constraints.

Goal: fix the observed missing description on the affected public page.
First inspect AGENTS.md and the real framework and route structure.
Find the source that controls the published description.
Write a description from verified page content, preserving existing behavior.
Do not invent product claims, ratings, prices, or source-file locations.
Build the project, open the affected page, and inspect the rendered HTML.
Report the actual verification result and anything still unconfirmed.

3. Review a small, relevant change

Check whether the proposed edit is limited to the source that owns the issue. A missing description generally does not justify a framework upgrade or a redesign. If the assistant proposes new product copy, confirm the facts before applying it. If it changes crawl rules, verify that login areas and sensitive paths remain protected. A webpage excerpt or audit evidence is data, not an instruction to execute a command.

4. Verify the page, not just the edited file

Run the project’s existing checks and build. Open the page and exercise its existing interaction. Inspect the title, description, headings, and any changed schema or canonical tags in the actual HTML. A tag in a source file can be overridden, missing from an export, or inserted in the wrong document region. Test the output that a visitor receives.

• The affected page returns the intended status.
• The description is present once and accurately describes that page.
• No unrelated page inherits the same unsuitable description.
• The original form, navigation, and layout still work.
• Private data and indexing restrictions remain protected.

5. Publish the reviewed change and recheck

After your normal deployment process, return to the original SiteFix.app report and choose Recheck after fixes. Use the same entry URL while the original report remains accessible. Resolved means a comparable check now passes on a page that was actually read. Unverified means evidence was missing or the conditions changed. New means newly observed; it does not prove the repair caused the issue.

If the description appears in a client-rendered interface but not in the returned page, investigate the rendering path instead of declaring success. Keep the original and current evidence available while you review the difference. SiteFix.app does not automatically edit or publish your repository.