Day 19 of 21
Use Codex for SEO fixes, UI fixes, and bug fixes
Goal: Learn three of the most common Codex job types: improving one SEO element, fixing one visible UI problem, and diagnosing one bug. Each job type needs a different prompt structure — today you build and use all three.
What to do
Build and run an SEO fix prompt
SEO fixes are among the safest Codex tasks — they usually touch one file, one field, and nothing the user sees directly. The key is being specific: name the exact page, name the exact element, and give Codex a character limit or rule to follow. The prompt below shows the structure for fixing a page title. Use it as a template and fill in your own page and issue.
I want to fix one SEO element on one specific page.
Page: [NAME THE PAGE — e.g. "the about page" or "src/pages/about.tsx"]
Element to fix: [NAME THE ELEMENT — e.g. "the page title tag" or "the meta description"]
Current value: [PASTE WHAT IT CURRENTLY SAYS]
Required: [DESCRIBE THE RULE — e.g. "under 60 characters and describes the page clearly"]
Before touching the file:
1. Show me the current value of this element
2. Suggest a replacement that meets the requirement
3. Wait for my approval before changing anythingBuild and run a UI fix prompt
UI fixes are trickier because "it looks wrong" is not specific enough for Codex to fix reliably. You need to describe the exact visual problem and the exact expected behaviour. The prompt below shows the structure: what it looks like now, what it should look like, and which file or component to look in. Do not ask Codex to redesign — ask it to fix the one specific thing that is wrong.
I want to fix one visual issue in my project.
Page or component: [NAME THE PAGE OR COMPONENT]
What it looks like now: [DESCRIBE THE VISUAL PROBLEM — e.g. "the button is overlapping the text below it on mobile"]
What it should look like: [DESCRIBE THE EXPECTED RESULT — e.g. "the button should have 16px of space below it"]
File to check: [NAME THE FILE IF YOU KNOW IT, or "I am not sure — please identify it first"]
Before touching anything:
1. Identify which file controls this specific element
2. Show me the current CSS or layout rule that is causing the problem
3. Suggest a fix and wait for my approvalBuild and run a bug diagnosis prompt
Bug fixes are the highest-risk Codex task because bugs often have root causes in different files than where the symptom appears. Never ask Codex to "fix the bug" immediately — ask it to diagnose first and explain what is causing it before touching any file. The prompt below separates diagnosis from fixing. Use it to understand the bug before approving a fix.
I have a bug I want to understand before fixing.
Symptom: [DESCRIBE EXACTLY WHAT IS HAPPENING — e.g. "clicking the Contact button does nothing" or "the page shows a blank white screen after login"]
Expected behaviour: [DESCRIBE WHAT SHOULD HAPPEN INSTEAD]
When it started: [IF YOU KNOW — e.g. "after the last Codex session" or "I am not sure"]
Diagnosis only — do not fix yet:
1. What is the most likely cause of this symptom?
2. Which file is most likely responsible?
3. Will fixing this require changing more than one file?
4. What is the safest first diagnostic step?Compare Codex's final report to your original request
After any of the three job types, ask Codex for a final report before committing. The report confirms what actually changed, not just what Codex intended to change. Compare the report to your original request. If the report describes something different from what you asked for, do not commit — ask for a revision or check the diff to understand the gap.
Save the three prompt templates to your workflow file
Today you built three prompt templates — one for SEO, one for UI, and one for bugs. These are reusable: next time you need to fix a page title, you open the SEO template, fill in the page and element, and paste it. Add all three templates to your codex-workflow.txt file under a section called "Job-type prompts." This turns today's lesson into a permanent resource you can use in every future session.
Add this section to your codex-workflow.txt:
## Job-type prompts
### SEO fix
I want to fix one SEO element on one specific page.
Page: [NAME THE PAGE]
Element to fix: [NAME THE ELEMENT]
Current value: [PASTE CURRENT VALUE]
Required: [DESCRIBE THE RULE]
Before touching the file: show me the current value, suggest a replacement, wait for approval.
### UI fix
I want to fix one visual issue in my project.
Page or component: [NAME IT]
What it looks like now: [DESCRIBE THE VISUAL PROBLEM]
What it should look like: [DESCRIBE THE EXPECTED RESULT]
Before touching anything: identify the file, show the current rule, suggest a fix, wait for approval.
### Bug diagnosis
I have a bug I want to understand before fixing.
Symptom: [DESCRIBE EXACTLY WHAT IS HAPPENING]
Expected behaviour: [DESCRIBE WHAT SHOULD HAPPEN]
Diagnosis only — do not fix yet: name the likely cause, the file responsible, whether it affects more than one file.Expected result
You have written and run three separate prompts — one SEO fix, one UI fix, and one bug diagnosis — each in its own session, each with a final report reviewed before committing. You saved all three templates to your workflow file. You committed only the changes that matched your original request.
Key takeaway
- SEO, UI, and bug work all need different prompt structures because they carry different risks. SEO: one element, one page, wait for approval. UI: describe the visual problem precisely, not vaguely. Bug: diagnose before fixing. And always compare the final report to the diff — Codex can be confidently wrong about what it changed.