Agency operations guide
Train a Reviewer to Catch Bad Assistant SEO Changes
Train a new reviewer with a written authority statement, a marked exercise of synthetic assistant proposals with seeded errors and valid exceptions, an answer key, and escalation rules.
On this page
Train a reviewer for assistant SEO changes with four things: a written statement of what they may decide, a practice set of synthetic proposals containing planted errors and some changes that look wrong but are correct, an answer key that explains every decision, and rules for when to escalate instead of deciding. Run the exercise before the reviewer touches a real client queue, and repeat it when the work changes.
The exercise tests judgment on SEO changes. Passing it does not make someone a security reviewer, and it does not replace controls on what the assistant’s credential can reach.
Define the reviewer’s decision authority
Write down, in a few lines, what the reviewer may approve, what they must reject, and what they must pass up. Ambiguity here produces reviewers who either approve everything or escalate everything.
| The reviewer may | The reviewer must escalate | Outside the reviewer’s role |
|---|---|---|
| Approve or reject title, description, and social text changes within the client brief | Any change to indexing, canonicals, or redirects on important pages | Changing the assistant’s credentials or role |
| Reject changes with factual errors or unsupported claims | Claims needing legal, medical, or financial review | Changing guard mode or the write limit |
| Refresh a stale proposal and re-read it | Batches that touch many pages at once | Approving their own edits |
Be specific about the system too. In WP Visibility, the review queue holds proposals from supported write abilities when the Assistant connection and Autopilot modules are on and Assistant changes is set to Hold for my review. It does not catch every possible write: an administrator credential can also approve through the plugin’s REST route, per the approval documentation, and can reach core WordPress routes outside the queue, per the pause documentation. The Review queue and the plugin’s settings both require the manage_options capability, so the plugin does not stop a reviewer from changing guard mode or the write limit; the right-hand column is a written rule, not a technical one. The reviewer should know which changes reach them and which do not, so they do not assume the queue is the whole picture.
Build the exercise from synthetic proposals
Write about ten proposals for a fictional site. Each has a target, a field, the before and after values, and the assistant’s rationale. Plant errors of different kinds, and include some changes that look suspicious but are correct, so the reviewer cannot pass by rejecting everything unusual.
The set below is for garden.example, a fictional garden supply shop in Portland that delivers within the city and does not offer landscaping. Every proposal is invented.
| # | Target | Field | Before | After | Rationale given |
|---|---|---|---|---|---|
| 1 | Delivery page | Description | “Garden supplies delivered in Portland.” | “Garden supplies delivered anywhere in Oregon within 24 hours.” | “Broader reach” |
| 2 | Home page | Title | “garden.example: Garden Supplies in Portland” | “Portland’s #1 Rated Garden Store | garden.example” | “Stronger title” |
| 3 | Compost guide | Canonical | (none) | https://staging.garden.example/compost-guide/ |
“Set canonical” |
| 4 | Soil testing page | Title | “Soil Testing” | “Soil Testing Kits and How to Read the Results | garden.example” | “More descriptive” |
| 5 | Order confirmation page | Indexing | Index | Noindex | “Utility page” |
| 6 | Landscaping page (old) | Redirect | (none) | 301 to /services/ |
“Service discontinued” |
| 7 | Syndicated article | Canonical | Partner’s original URL | (removed) | “Canonical points off site” |
| 8 | Seed catalog | Description | (none) | “Browse heirloom and organic seeds for Pacific Northwest gardens.” | “Missing description” |
| 9 | Raised beds page | Indexing | Index | Noindex | “Thin content” |
| 10 | Tools page | Title | “Hand Tools” | “Hand Tools | garden.example” | (proposal marked stale) |
Use the answer key
Mark each response on the decision and the reason. A correct decision with the wrong reason gets coaching, because the reason is what transfers to the next case.
| # | Correct decision | Reason |
|---|---|---|
| 1 | Reject | Factual error: the shop delivers within Portland only, and no delivery time is in the brief |
| 2 | Reject | Unsupported claim: “#1 Rated” has no source; the reviewer should not approve claims the business cannot back |
| 3 | Reject and escalate | Wrong host: the canonical points to a staging address, which asks search engines to prefer a non-public URL |
| 4 | Approve | A title over 60 characters is fine when it describes the page accurately; length checks are editing prompts, not rules. Google sets no length limit on the title element and truncates the displayed title as needed (Google on title links, checked September 27, 2026) |
| 5 | Approve | Keeping an order confirmation page out of search is normal |
| 6 | Escalate | Plausible, but redirects on service pages need the client’s confirmation that the service ended |
| 7 | Reject | Intentional exception: the canonical to the partner’s original was set on purpose, and removing it drops a signal pointing to the original. Google does not recommend the canonical for syndicated copies and calls blocking their indexing the most effective option (Google’s canonicalization troubleshooting, checked September 27, 2026), so any change here is the client’s decision |
| 8 | Approve | Accurate, matches the page’s purpose, no invented facts |
| 9 | Reject and escalate | Noindexing a product page removes it from search; “thin” needs a content decision, not an indexing change |
| 10 | Refresh, then decide | A stale proposal means the target changed since it was written; refresh the diff and read the current before value first |
Item 10 mirrors how WP Visibility handles stale proposals: approval stops, the card offers Refresh diff, and the refreshed proposal needs re-reading because the change may no longer be the one that was proposed, per the approval documentation.
The factual checks follow a question from Google’s guidance on helpful content: does the content have any easily verified factual errors? Google’s guide to creating helpful, reliable, people-first content, checked September 27, 2026. The reviewer needs the client brief open beside the queue to answer it.
Items 3 and 9 rest on how Google reads these signals: a rel="canonical" annotation is a strong signal that the named URL should become canonical (Google on canonical URLs), and a noindex rule drops the page from Google Search results once Googlebot sees it (Google on noindex), both checked September 27, 2026.
Score and coach
Set the pass line by severity, not by percentage. A reviewer who approves item 3 or item 9 has missed a change that can remove or misdirect pages in search, which matters more than a wrong call on item 4.
A workable rule: no misses on indexing, canonical, or redirect items, and a correct reason on at least most of the copy items. Then coach on the pattern of mistakes:
- Approves too much. Usually trusts the rationale. Remind them that the rationale is context supplied with the request, not proof.
- Rejects too much. Usually treats audit thresholds as rules. Walk through item 4, then item 7, where the same habit produces a wrong approval.
- Right decisions, weak reasons. Ask them to write one line per decision for the next week of real reviews.
Record who took the exercise, when, and which items they missed. Do not record it as a certification.
Write the escalation rules
Escalation needs a destination and a time limit, or items stall in the queue. Write the rules as conditions:
- Indexing, canonical, or redirect changes on pages listed as important in the client brief go to the senior reviewer.
- Claims about prices, guarantees, health, safety, or legal matters go to the client’s named approver.
- A batch touching more than an agreed number of pages goes to the senior reviewer before any item is approved.
- Anything suggesting the assistant is acting outside its brief, such as proposals for sites or pages not in scope, triggers a pause. The pause documentation covers stopping every assistant call to the plugin’s abilities at once, and the activity log shows the ability calls it completed.
- If the reviewer is unsure and no rule applies, they reject and write down why; the WP Visibility queue has no field for a rejection reason, so keep the note in your own review record. A rejected proposal changes nothing and can be proposed again.
Training checklist
- Written authority statement, including what the queue does not cover.
- About ten synthetic proposals with planted errors and valid exceptions.
- Answer key with a reason for every decision.
- Pass line set by severity, with coaching notes recorded.
- Escalation rules with destinations and time limits.
- Exercise repeated when the site, brief, or tooling changes.