Turn a selected page into a work plan

The toolkit already grades every individual page signal on its own. What it hasn’t had is the step after that: a strategist names one page, and the handoff back needs to be a work plan with a proposed change and a priority on every row — not another audit restating what’s already known.

1. Confirm exactly one page, already selected. If the real ask is “which page should we work on this month,” that’s the selection job, not this one — this recipe assumes the URL is settled.
2. Grade on-page fundamentals and structured data. Title, meta, canonical, headings, and social/schema markup, against zero. This is the baseline every recommendation below either confirms is already clean or proposes changing.
3. Pull link and image evidence. Broken links and images on the page itself, and — where a URL universe already exists for the site — the internal link graph. An under-linked or orphaned page is where the recommendation “add internal links from these pages” writes itself.
4. Grade content on three separate axes. Readability, spelling, and freshness relative to a normal refresh window. Keep them separate — a page can be readable and stale, or freshly edited and hard to read, and a blended score would hide which one is actually the problem.
5. Grade technical and UX signals, and capture the page while at it. Performance, accessibility, layout, and — where the stack is WordPress — plugin/theme health. Screenshot it across devices in the same pass, since the before-state is needed again in step 9 regardless.
6. Add keyword and competitive context where it’s configured. A content brief for the target term if one doesn’t already exist, and keyword-gap data against competitors through the SEMrush client. Both are optional inputs — where the account isn’t configured, or a competitor-comparison tool isn’t available, the search-intent read is labelled “Not verified — data unavailable” rather than blocked or guessed at.
7. Write the output as a change list, not a findings list. Each row: the issue, the exact change — copy, tag, or structure — where evidence supports a specific one, the evidence it rests on, the impact, the effort, a P1/P2/P3, and the post-change KPI that will tell you it worked (position, CTR, clicks, or conversions for that page). A row with no proposed change is a finding, not a work-plan item, and doesn’t belong in this document.
8. [manual] Add a “what not to change” section. Every check that already passes gets named as passing and left alone. The point of running the full check set first is exactly so an editor doesn’t rewrite something that was never broken.
9. Record the baseline before anything is edited. The screenshot capture from step 5, plus current position and impressions for the target term. This is the same before-state every recipe here relies on, and it’s the only way “did this work” has an answer once the changes are live.
10. [manual] Make the approved changes, then rerun steps 2, 4 and 5 against the published page to confirm the work landed and record the result.

Reuses tool JSON outputs and report-kit rather than duplicating each scanner; a page that already satisfies a check is explicitly retained rather than rewritten.

A work plan, not another audit

The difference between this and grading the page in isolation is that every row here carries a proposed change, evidence, and a priority. An audit that stops at “here’s what’s wrong” hands the strategist the same page a second time; a work plan hands them something to execute.