Turn audit findings into SEO recommendations a developer will action
A prompt that converts a raw audit export into ordered recommendations, each with the change to make, who makes it, and what to check afterwards.
- Works in
- ChatGPT, Claude
- You need
- An audit export or a pasted list of findings · Who is available to do the work · What the site is for
- Written for
- seo recommendations
Scored by our own engine
This page, run through the audit we sell. Measured 6 August 2026.
An audit produces findings. A finding is not a recommendation, and the gap between the two is where most audit reports quietly die. The prompt below turns a list of findings into ordered instructions, each with an owner, an effort size and a way to check the fix landed, and it names the findings it would not act on at all.
Severity is the wrong sort order
Audit tools rank by how bad something is, because that is the only thing they can see. They cannot see your team. A critical finding that needs a platform change and a moderate finding that needs one line in a template arrive in the same list with the critical one on top, and the list stops being touched in week two.
Impact divided by effort is a worse looking order and a better one to work from. It puts the template edit first, ships something, and buys the political room for the platform conversation later. The prompt asks the model to explain any position it thinks is wrong, so you get the argument rather than a silent reordering.
Grouping by root cause changes the size of the job
Eleven missing titles are usually not eleven problems. They are one template rendering nothing when a field is empty. Presented as eleven rows the work looks like a fortnight, and presented as one row it looks like an afternoon, which is what it is.
This is the single largest reduction available in most audit reports, and it is the thing a model does well when you ask for it explicitly, because grouping by shared cause is pattern matching over a list rather than judgement about a business.
What to check before you trust the output
The model is reading your findings, not your site. If your tool produced a false positive, you will get a confident, well written recommendation to fix something that was never broken. Open the pages behind the top three rows before anything reaches a ticket. Those three are the ones that will get built, and they are cheap to verify.
You are an SEO consultant writing the recommendations section of an audit
for a client who has limited engineering time. I will paste a list of
findings. Turn them into an ordered set of recommendations somebody can
start on Monday.
Rules you must follow:
1. One recommendation per row, written as an instruction. "Add a canonical
tag to the 412 paginated URLs" is a recommendation. "Improve
canonicalisation" is a heading pretending to be one.
2. Order by expected impact divided by effort, not by severity. A critical
finding that needs a platform migration ranks below a moderate one that
needs a template edit, and if you disagree with that ordering for a
specific row, say why in the reasoning column rather than silently
reordering.
3. Assign each row an owner from this set only: developer, content, SEO,
platform vendor, nobody. Use "nobody" when the fix is not available on
this stack, and say what would make it available.
4. Give each row an effort estimate of S, M or L, defined as: S is one
person for under a day, M is a few days, L is a project with a kickoff.
Do not use hours. Hour estimates for work you cannot see are fiction.
5. Give each row a verification step: the specific thing to look at
afterwards to confirm the fix landed. A recommendation with no
verification step is how a site ends up with a closed ticket and the
same finding next quarter.
6. Group anything that shares a root cause. If eleven findings all come
from one template, that is one recommendation affecting eleven URLs, and
presenting it as eleven rows makes the list look enormous and the work
look impossible.
7. Put anything you would not do into a section called Leave alone, with a
sentence each. Findings that are technically true and not worth fixing
are a normal part of every audit and pretending otherwise wastes the
first week on cosmetics.
Output a markdown table with these columns:
# | Recommendation | Owner | Effort | Why this position | How to verify
Then give me:
- The Leave alone list.
- The three rows I should do this week if I only get one developer day.
- Any finding I pasted that you could not turn into a recommendation
because it needs information I did not give you. Ask me for that
information specifically.
Constraints:
- Do not invent findings that are not in my list, and do not soften one. If
a finding says pages are noindexed, the recommendation is to fix it, not
to review the indexation strategy.
- Do not estimate traffic uplift. You cannot know it. Rank on reasoning
about impact, and say that the ordering is a judgement rather than a
forecast.
- Write for somebody who will paste the row into a ticket. No preamble in
the cells.
What the site is for: [ONE SENTENCE ON THE SITE AND WHAT A CONVERSION IS]
Who is available: [WHO CAN ACTUALLY DO WORK, AND ROUGHLY HOW MUCH TIME]
The findings: [PASTE THE AUDIT EXPORT OR THE LIST OF ISSUES]What to change
Everything in square brackets is yours to replace. Nothing else needs editing.
[ONE SENTENCE ON THE SITE AND WHAT A CONVERSION IS]- The ordering changes completely depending on what the site is for. A slow product template is the first row on an ecommerce site and the fourth on a documentation site, because on one of them it costs revenue and on the other it costs patience. Without this the model orders by generic best practice.
[WHO CAN ACTUALLY DO WORK, AND ROUGHLY HOW MUCH TIME]- Say "one developer, half a day a week" if that is the truth. It is the input that stops the list being a wish. A plan written for a team you do not have is the most common reason audit recommendations never get implemented, and it is avoidable in one sentence.
[PASTE THE AUDIT EXPORT OR THE LIST OF ISSUES]- The findings themselves, from any tool, or typed by hand. Keep the affected URL counts if you have them, because rule 6 uses them to work out which findings share a template. Drop the tool marketing copy that usually surrounds each finding, since the model will otherwise treat it as evidence.
How to run it
- 01Get the findings into plain text
Export from whatever tool produced them and keep the finding, the severity and the affected URL count. Delete the explanatory paragraphs the tool attaches to each issue. Those paragraphs are written to sell the tool and the model treats them as context, which biases the ordering towards whatever the vendor emphasises.
- 02Write the two sentences of context
One sentence on what the site is for and what counts as a conversion, one on who is available to do work. These two lines do more for the quality of the output than any other change you can make to the input.
- 03Run it and read the Leave alone list first
The Leave alone list tells you how much of your audit was noise. If it is empty, be suspicious and run it again, because every real audit contains findings that are true and not worth anybody time. If it is half the list, your tool is generous with warnings.
- 04Sanity check the top three by hand
Open the pages the top three rows refer to and confirm the finding is real. Audit tools produce false positives, and a model reading a false positive will write you a confident recommendation to fix something that is not broken. The top three are the ones that will actually get built, so check those.
- 05Paste the rows into tickets, verification step included
Copy each row into your tracker with the verification step in the ticket body rather than in a separate document. The verification step is the part that survives a handover, and it is the reason the same finding does not reappear in the next audit.
- 06Recheck the site after the first batch ships
Run the audit again once the first three rows are live and compare. This is the only way to find out whether the ordering was any good, and it turns the next round of recommendations into something informed by your site rather than by general practice.
Questions people ask
How do you write SEO recommendations from an audit?
Convert every finding into a single instruction with an owner, an effort size and a verification step, group the findings that share a root cause, and order the result by impact divided by effort rather than by severity. The severity column tells you how bad something is. It does not tell you what to do first, which is the only question the recommendations section exists to answer.
Should SEO recommendations be ordered by severity?
No, and this is where most audit deliverables go wrong. Severity ignores cost. A critical issue requiring a replatform and a moderate issue requiring a template edit are not the same decision, and a list that puts the replatform first is a list nobody starts. Order by what the available team can finish, then revisit.
Can ChatGPT estimate how much traffic a fix will bring?
It will if you ask, and the number will be invented. Traffic outcomes depend on your competitors, your history and the query, none of which the model can see. This prompt forbids uplift estimates for that reason and asks the model to state that the ordering is a judgement rather than a forecast.
What makes a recommendation actually get implemented?
An owner, a size and a way to check it worked. Recommendations fail at the handover, not at the analysis: a developer given "improve internal linking" has nothing to build, while one given "add three contextual links from the category template to the top selling products" has a ticket. Write for the person holding the keyboard.
Why does the prompt ask for a Leave alone list?
Because every audit contains findings that are true and not worth fixing, and naming them is what makes the rest of the list credible. A consultant who says every one of ninety findings needs work is either not reading them or is selling hours. Saying which twelve you would ignore is the part clients remember.
Unsubscribe in one click. We never pass your address on.