Give an editor a page-fix task they can finish without another meeting

To give an editor a page-fix task they can finish without another meeting, hand over one page, one proposed change, the exact passages that justify it, a clear scope boundary, and acceptance criteria written before the edit starts. The editor should never have to ask "what did you mean?" or "how will you know it is done?". This post gives you that handoff as a copyable template, shows what DiscoveredBy's task packet contributes to it, and fills it in once for a fictional company. Every proposed change is a hypothesis to test, not a promise of more citations.

In short

• Hand over one page and one decision per task. A packet with many unrelated changes becomes a meeting.
• Include the evidence: the passage from the cited page that motivated the change, and its source URL.
• State what is out of scope as clearly as what is in scope.
• Write acceptance criteria an editor can check alone, and separate "edit done" from "did it help".
• Treat a drafted change as a starting point to verify. The editor owns the wording.

What is a page-fix task?

A page-fix task is a unit of editorial work that changes one page you already own, because AI answers for a prompt cite other pages and not yours. A citation is a page an AI answer links as a source. A citation gap is the difference between what the cited pages offer and what your page offers. A prompt is a question a monitoring tool asks AI engines on your behalf; it is not a keyword.

This is different from a new-article brief. If no page of yours should be winning the prompt, the job is a new page, and the content brief post covers it. A page-fix task assumes the page exists and has an owner.

Why do page-fix tasks stall?

They stall because the person who found the gap holds context the editor does not. The analyst knows which competitor page was cited, which sentence made it useful, and why this page was chosen. The editor receives "add an FAQ to the pricing page" and has to reconstruct the rest.

Four gaps commonly cause follow-up meetings:

• Missing evidence. The editor cannot tell whether "add a comparison table" came from a real cited page or a guess.
• Unclear scope. Nobody said whether the headline, the URL or the surrounding sections could change.
• Unclear finish line. "Improve the page" has no end.
• Stale context. The page changed after the analysis, and the advice no longer fits.

The template below answers each one in writing.

What does DiscoveredBy give you to start with?

It gives you a diagnosis and a downloadable task packet, not a finished edit, on plans that include on-page optimization. In the Optimizations screen, a gap with a page of yours behind it becomes an optimization: DiscoveredBy reads your page and the cited competitor pages and decides what yours is missing, such as an FAQ block, a comparison table, a statistic, structured data, a fresher date or a clearer heading.

Two documented details shape how you use it.

• The evidence is checked; the draft is not. A proposed change survives only if at least one of its evidence quotes is a real phrase of at least sixteen characters that appears in the scraped text of the source page it claims to come from. The draft text you would paste in is never compared against a source. Read it as a starting point.
• Nothing reaches your site. You copy the draft into your own page yourself. The export does not publish to a CMS or send the packet to another service.

Choosing Export task packet downloads one Markdown file, and Download PDF task packet gives a paginated PDF. The packet includes the target page, the recorded status and update time, the target-page content hash when saved, a summary, a review checklist, and each change in priority order. Each change carries its anchor, rationale, estimated effort, risk and human-review flag, plus the saved source URL and quote when available. All saved draft formats are included: replacement text, Markdown, HTML and JSON-LD.

Enlarge image

Depending on your plan, exporting requires the project owner's data-export entitlement. See plans and limits.

The page-fix handoff template

Copy this into your task tool. It is built to wrap the exported packet: the packet supplies the evidence, and the template supplies the decisions a packet cannot make for you.

PAGE-FIX TASK

1. Page
   URL:
   Page owner:
   Task packet downloaded on (date):
   Packet status at download (as shown in the app, e.g. ready / applied / stale):

2. Why this page
   Prompt(s) where a competitor page is cited and ours is not:
   Engines where this was observed:
   One-sentence diagnosis (what the cited pages have that ours lacks):

3. The change (one per task)
   Kind of change (FAQ, table, statistic, structured data, date, heading, other):
   Anchor (where on the page):
   Draft text or file reference (from the packet):
   Draft format used (Markdown / HTML / plain text / JSON-LD):

4. Supporting passages
   Source URL 1:
     Quote (from the packet):
   Source URL 2:
     Quote:
   What the passage shows, in your own words:

5. Scope
   You may change:
   You must not change (headline, URL, pricing, legal wording, other):
   Facts you must confirm with a named person before publishing:
   Regulated-topic review flag in the packet? (yes / no) Reviewer:

6. Acceptance criteria (each answerable yes or no)
   [ ] The change appears at the anchor, and nothing outside scope changed.
   [ ] Every factual claim matches an approved source: (link)
   [ ] Copied draft wording was rewritten or confirmed by the editor.
   [ ] Structured data, if any, validates and matches visible page text.
   [ ] The page is published and loads at the same URL.
   [ ] Editor recorded the publish date and what was actually changed.

7. After the edit
   Who marks the recommendation applied in DiscoveredBy:
   Date to check the outcome (at least 30 days after applying):
   Who decides whether to keep the change:

8. Questions
   If something is unclear, ask in this thread. Do not wait for a meeting.

How do you fill in each section?

Each section answers one question the editor would otherwise ask you. Fill them in this order.

Page and freshness

Record the date you downloaded the packet. A packet is a copy at download time and does not refresh as the recommendation changes. Before the editor starts, check the current recommendation and the current page. The task packet's review checklist starts unchecked even for an applied recommendation, so it is not a record of finished work.

If the target page's content changes after a draft was written, DiscoveredBy's daily check marks the recommendation stale. A stale draft is reference material only. The next weekly run, on plans that include it, reopens it with a fresh draft; export again after that.

Why this page

Write the prompt, the engines and a one-sentence diagnosis. Keep it as an observation: "the cited pages include a comparison table and ours does not." Do not write "AI ranks us lower because...". Citations and mentions are observations of an answer, not proof of why a model produced it.

The change

Give the editor one change. The packet lists changes in priority order, so take the top one. If the packet has more, create separate tasks, or the editor will negotiate scope with you.

Supporting passages

Paste the source URL and the saved quote from the packet. This part matters because it lets the editor read the original and judge the claim. Saved quotes are not a fresh check of the sources, so if the source matters, ask the editor to open it.

If a change has no saved quote, say so in the task. A fallback draft in DiscoveredBy can be a fixed template naming the source and telling you what to cover, and it is not page content you can paste as written.

Scope and review

List what the editor may change and what they must not. Copy the packet's human-review flag into the task and name a reviewer. In DiscoveredBy, a regulated topic (medical, legal, financial, security) gets a review flag, and the flag does not change the wording of the draft.

If your team uses batch review, owners and editors can select up to 25 open drafts and choose Approve selected for handoff. Approval records a separate review. It does not mark anything applied, publish anything or start outcome measurement, and edited draft content no longer carries a current approval. Both downloaded formats disclose the recorded review state.

How do you set acceptance criteria an editor can check alone?

Write criteria as yes-or-no statements about the page, not about impact. "The FAQ appears under the pricing table and every answer matches the approved facts sheet" is checkable. "The page is more citable" is not.

Keep three finish lines apart:

Marking applied is a manual step in DiscoveredBy, and it is the point where the tool records the trailing month of visibility for the fix's prompts. Measurement then compares current visibility for those prompts against a baseline from the 30 days before you marked it applied. An outcome of positive or negative at the month mark needs a change of five points or more; anything smaller reads neutral, which means nothing definitive happened yet and not necessarily that the fix failed. An applied date and outcome are saved observations; they do not prove the edit caused a change. For more on judging change, see Did your content update help?.

A worked example

Quillstone sells document-review software to legal and compliance teams. Its analyst, Priya, sees that for the prompt "how do I compare document review tools for contract due diligence?", pages from two fictional competitors, Brieflane and Docket North, are cited, and Quillstone's /solutions/due-diligence page is not. She exports the task packet and finds two changes. She keeps the top-priority one and files the second as its own task.

PAGE-FIX TASK

1. Page
   URL: /solutions/due-diligence
   Page owner: Marcus (web editor)
   Task packet downloaded on: 6 October
   Packet status at download: ready

2. Why this page
   Prompt: how do I compare document review tools for contract due diligence?
   Engines where observed: two of the engines we monitor
   Diagnosis: both cited pages include a table comparing review features by
   deal size; ours describes features in paragraphs only.

3. The change
   Kind: comparison table
   Anchor: directly under the heading "What to look for in review software"
   Draft: packet change 1
   Draft format used: Markdown

4. Supporting passages
   Source URL 1: (Brieflane page, from packet)
     Quote: (saved quote from packet)
   Source URL 2: (Docket North page, from packet)
     Quote: (saved quote from packet)
   What they show: both compare features against document volume, not
   against price. Marcus should read both pages before editing.

5. Scope
   May change: the section under the anchor, plus one sentence of intro.
   Must not change: the headline, URL, customer logos, security wording.
   Confirm with Aisha (product): every feature row and the volume limits.
   Review flag in packet? yes. Reviewer: Dana (compliance).

6. Acceptance criteria
   [ ] Table sits under the anchor; no other section changed.
   [ ] Every row confirmed by Aisha, in writing.
   [ ] Draft wording rewritten in Quillstone house style.
   [ ] Dana has cleared the legal-topic flag.
   [ ] Page live at the same URL; publish date recorded.

7. After the edit
   Marks applied: Priya, after she checks the live page.
   Outcome check: at least 30 days after marking applied.
   Keep or revert decision: Priya and Marcus.

Marcus finishes the task in one sitting. He asks no questions because the anchor, the quotes, the boundaries and the reviewer were already on the page. The one thing he does ask is whether a third row is allowed, and the scope line answers it: the section under the anchor is his to shape.

Enlarge image

What can go wrong?

Most failures are honest limits of the material, not of the editor.

• Treating the draft as verified copy. Only the evidence quote is checked against a source. The draft body is not. The editor should rewrite it or confirm every claim.
• Sending a stale packet. If the page changed after the download, the advice may no longer fit. Check the current page first.
• Bundling changes. Several unrelated changes in one task turn one meeting into three. Split them.
• Confusing approved with applied. Approval records a review. It does not mean the page has changed.
• Reading the outcome as proof. A positive outcome after a month is a saved observation. Other things changed in that month too.
• Writing "improve" as an instruction. If a criterion cannot be answered yes or no, rewrite it.

What this handoff cannot tell you is whether the change will earn a citation. It makes the work clear and the result checkable; it does not make the result likely. For your own audit trail, keep the packet with the task so you can see later exactly what the editor was asked to do. If you want a second person to look at generated wording before publication, see Human review for AI-written content.

Frequently asked questions

Should the editor or the analyst mark the fix as applied?

Whoever runs the monitoring tool should, after checking the published page. In DiscoveredBy, neither downloading nor approving a draft marks it applied; that is a separate manual action taken after you implement and verify the edit. That keeps "edit published" and "edit recorded" as two checked facts.

Can I send the packet to my editor as is?

You can, and for small changes it may be enough. It carries the change, anchor, rationale, effort, risk and source quotes. What it cannot contain is your decisions about scope, named reviewers and who confirms facts, which is why the template wraps it.

What if the source page is behind a login or has changed since the quote was saved?

Tell the editor to treat the quote as a lead, not as current fact. Saved quotes are not a fresh check of the sources. Ask them to open the URL, and if it no longer says the same thing, send the task back to the analyst.

How do I hand off a fix for a page that is not in my known inventory?

The Page issue queue shows known owned pages from prompt-to-page mappings, citation gaps, optimization opportunities, saved diagnostics and the latest finished site audit. It is known inventory, not a complete crawl, and "no saved issues" is not a clean bill of health. A page outside it needs the same template, filled in without a packet.

How does this differ from a ticket for a developer?

A page-fix task changes content an editor owns. A technical finding, such as a blocked crawler, needs a developer with a reproducible observation and an acceptance check; see Turn a technical AI audit finding into a developer-ready ticket.

Next step

Open Optimizations in your project, pick the top recommendation with a draft ready, export its task packet, and fill in the template above around it. If you also need the wider picture of which pages to prioritise, start from the Page issue queue. Sign in or create a project to try the workflow on one page.