Mục lục bài viết48 mục
- 1.Prerequisites
- 2.Step 0: Validate the Root Cause Before Committing Resources
- 2.1Check These First
- 2.2Decision Gate
- 3.Step 1: Triage Losses and Select Priority Pages
- 3.1Pull Losses from GSC
- 3.2Tag Candidates by Severity
- 3.3Scope to Bandwidth
- 3.4Start the Mapping Sheet
- 3.5Early Warning Signals — Cut Scope If You See These
- 4.Step 2: Identify Target Entities and Write Disambiguation Notes
- 4.1Derive the Primary Entity from Search Intent
- 4.2Find Authoritative sameAs References
- 4.3Write the Disambiguation Note
- 4.4List Secondary Entities
- 4.5Document Everything in the Mapping Sheet
- 4.6Prompt to Speed Up Entity Selection
- 5.Step 3: Apply On-Page Entity Signals
- 5.1Checklist
- 5.2Before-and-After Examples
- 5.3Guardrails
- 6.Step 4: Add and Validate Schema
- 6.1Prioritized Schema Types by Page Type
- 6.2Required Properties for Safe Deployment
- 6.3JSON-LD Examples
- 6.4Validation Workflow
- 6.5Common Mistakes to Avoid
- 7.Step 5: Reinforce Entity Signals with Internal Linking
- 7.1Hub-and-Spoke Architecture
- 7.2Linking and Anchor Rules
- 7.3Checklist Before Shipping Links
- 7.4Guardrails
- 8.Step 6: Stabilize Brand Entity Signals
- 8.1Core Actions
- 8.2Success Criteria
- 8.3Warning Signals
- 9.Step 7: Measurement, Change Log, and Rollback
- 9.1Per-Page Recovery Estimates
- 9.2KPIs and Daily Checkpoints
- 9.3Change Log — Required Fields
- 9.4Rollback Triggers
- 10.Step 8: Package the Plan for Executive Sign-Off
- 10.1One-Page Executive Summary Template
- 10.2Filled Example
- 10.3Sign-Off Standard
- 11.Day-by-Day Execution Timeline
- 12.Writer-Ready Brief Template (One Per Page)
- 13.Operating Rules for the Sprint
Use this playbook to diagnose traffic losses, validate the root cause, map target entities, ship safe fixes, and package an executive-ready plan with owners, timelines, and recovery estimates — all within 14 days.
Prerequisites
Before starting, confirm you have:
- Google Search Console and Analytics access with edit rights
- CMS access to update copy, anchors, and JSON-LD
- Content inventory and sitemap
- Rich Results Test and Schema Markup Validator
- Limited dev and content bandwidth — assume on-page edits, schema, and internal links are in scope; template or layout changes are out of scope for this sprint
Expected output: An executive-ready plan mapping target entities to priority pages, prioritizing low-effort on-page, schema, and internal-link updates with named owners and timelines, plus page-level recovery estimates. Initial changes are shipped and validated within the window. Executives approve rollout and early metrics show stabilizing impressions on targeted pages.
Step 0: Validate the Root Cause Before Committing Resources
This step is frequently skipped — and it is the most common reason a technically sound entity-based fix delivers no recovery. Entity ambiguity is one cause of core update traffic loss, not the only one. Before assigning hours to schema and disambiguation work, rule out the alternatives.
Check These First
Confirm it is not a technical issue Verify the affected pages return 200, are not canonicalized elsewhere, carry no noindex tag, have no soft 404 signals, and are not blocked in robots.txt. Use Screaming Frog or a site audit crawl. If technical issues are present on any candidate page, fix those first and exclude the page from entity recovery scope.
Check whether the loss is brand navigational, not entity confusion Pull the query breakdown per page in GSC. If the majority of lost clicks come from queries containing your brand name, the problem is brand signal or SERP feature displacement, not entity ambiguity. Entity-based fixes will not recover brand navigational losses.
Look at competitor and SERP-level signals Search the primary query for each candidate page and note what Google currently shows: does a Knowledge Panel appear for a different entity? Has a competitor moved into a featured snippet or top position? Has the SERP format shifted from blue links to an AI Overview or rich result? If the SERP itself changed, the fix may need to be content depth or structured data eligibility — not disambiguation alone.
Check whether the Knowledge Graph already recognizes your entity Search [your brand name] site:wikidata.org and check whether a Knowledge Panel surfaces for your brand on a branded query. If Google’s Knowledge Graph already has a clean signal for your entity, page-level confusion is less likely to be the dominant cause.
Decision Gate
If after these checks entity ambiguity remains the most plausible explanation — same or similar entity names competing, mixed signals across heading, schema, and anchors, or a page that could reasonably be parsed as covering two different things — proceed to Step 1.
If a different root cause is identified, stop this playbook and address that cause directly. Do not force entity-based fixes onto a technical or content-depth problem.
Step 1: Triage Losses and Select Priority Pages
You cannot fix everything in 14 days. This step narrows scope to the highest-impact, lowest-effort pages and creates the single source of truth for the rest of the plan.
Pull Losses from GSC
GSC Performance → Search Results
- Date range: last 28 days vs. previous 28 days
- Dimensions: Page, Query
- Metrics: Clicks, Impressions, CTR, Position
- Run once filtering out brand terms (non-brand view), then again for brand view
Export Analytics landing page data for the same periods with Sessions and Revenue or Goal value where available.
Tag Candidates by Severity
| Severity | Threshold | Criteria |
|---|---|---|
| S1 | −40% or more clicks | High past value — prioritize |
| S2 | −20% to −39% clicks | Material value — include |
| S3 | −10% to −19% clicks | Experimental or peripheral content |
Exclude any page with a confirmed technical issue (404, wrong canonical, noindex, soft 404, layout shifts, robots block) before severity tagging. Technical issues require a different fix track.
Scope to Bandwidth
Choose 10 to 20 pages total, weighted toward S1, where fixes are achievable without template changes or significant dev work. For each page, assign a page type (Article, Guide, Product, Category, Comparison, Feature, Docs) and write a working hypothesis: what entity this page must own and what it is currently being confused with.
Start the Mapping Sheet
Use the following columns. Keep it in a shared doc and update daily.
| Column | Description |
|---|---|
| Page URL | |
| Page type | |
| Primary target entity | |
| Disambiguation note | |
| Secondary entities to cover | |
| Current sameAs on page | |
| Proposed sameAs | |
| On-page fixes | |
| Schema to add or fix | |
| Internal links to add | |
| Owner | |
| Effort (1–3) | |
| Impact (1–3) | |
| Due date | |
| Status | |
| Baseline clicks 28d | |
| Est. recovery clicks 28d | |
| Confidence (Low / Med / High) | |
| Risks and rollback |
Example rows:
URL: https://acme.com/hr-software
Type: Product
Primary entity: Acme HR Software
Disambiguation: Distinct from Acme Consulting
Secondary entities: HRIS, payroll, time tracking
Proposed sameAs: Wikidata Q1234567, LinkedIn, Crunchbase
On-page fixes: Add definition block, tighten H1, replace stock logo with product UI image
Schema: SoftwareApplication with sameAs and offers
Internal links: From /hr-software hub, /pricing, top 3 guides with anchor "hr software"
Owner: PM | Effort: 2 | Impact: 3 | Due: Day 8
Baseline: 5,200 clicks | Est. recovery: 1,300 | Confidence: Med
Rollback: Revert if CTR drops 20% over 7 days post-indexing
URL: https://acme.com/what-is-hris
Type: Article
Primary entity: Human Resource Information System
Disambiguation: Distinct from HCM and payroll-only tools
Secondary entities: HR database, employee records
Proposed sameAs: Wikipedia HRIS, Wikidata Q890123, Gartner glossary
On-page fixes: Add single-sentence definition, add comparison section, adjust internal anchors
Schema: Article with mainEntity and sameAs
Internal links: From /hr-software hub and glossary, add related module
Owner: Content Lead | Effort: 1 | Impact: 2 | Due: Day 5
Baseline: 8,900 clicks | Est. recovery: 900 | Confidence: High
Rollback: Revert if impressions fall 30% over 7 days
Early Warning Signals — Cut Scope If You See These
- Candidates require template changes or CMS migrations
- Top losses are brand navigational queries, not entity-confused queries
- Multiple pages are targeting the same entity and cannibalizing each other at scale
If any of these apply, reduce scope immediately and replace affected pages with ones that fit the low-effort criteria.
Step 2: Identify Target Entities and Write Disambiguation Notes
Entity-first recovery depends on naming the one thing the page is about and explicitly removing ambiguity. Without this, schema and internal links amplify mixed signals rather than resolving them.
Derive the Primary Entity from Search Intent
Use the query data from GSC for each page. For informational guides, choose a concept entity — not your product name. For product and feature pages, choose your product or the specific feature as the entity. Check for ambiguity risks: similar names, acronyms shared with other concepts, or your brand name overlapping with a generic category term.
Find Authoritative sameAs References
Preferred sources (in order of entity recognition strength with Google):
- Wikidata item
- Wikipedia article
- Official standards body or major industry glossary
- Your official LinkedIn company page
- Crunchbase organization profile
- App Store or G2 listing (for software products)
- GitHub (for developer tools)
If your brand or product has no Wikidata or Wikipedia entry — which is common for B2B SaaS products — use LinkedIn and Crunchbase as primary sameAs sources. Be aware that Google’s entity recognition from these sources is weaker than from Wikidata or Wikipedia. In this case, invest more effort in on-page clarity: a precise definition sentence in the first 100 words carries more weight when authoritative external references are thin. If building a Wikidata entry is feasible (notable enough product, enough sourcing), doing so before this sprint ends will strengthen recovery.
Write the Disambiguation Note
One sentence stating what this entity is and what it is not. You will reuse this sentence in on-page copy and in anchor context. Keep it consistent across every surface.
Example: Acme HR Software is a Human Resource Information System for mid-market HR teams — not a standalone payroll tool or an HR consulting service.
List Secondary Entities
Identify 3 to 6 related entities you must mention or define on the page to anchor the primary entity’s meaning. These support disambiguation without diluting the primary focus.
Document Everything in the Mapping Sheet
Fill: Primary target entity, Disambiguation note, Secondary entities, Proposed sameAs.
Prompt to Speed Up Entity Selection
Paste this into your preferred AI assistant to generate candidates quickly:
Analyze [PAGE URL]. List:
1. Candidate primary entity for this page
2. Top 5 secondary entities required for disambiguation
3. Ambiguity risks (similar names, shared acronyms, brand vs. generic)
4. Recommended authoritative sameAs URLs for the primary entity
5. A one-sentence disambiguation note
Return in bullet points only.
Step 3: Apply On-Page Entity Signals
On-page is where you remove ambiguity for both users and parsers. Aim for small, safe edits that clarify the entity without rewriting or restructuring the page.
Checklist
Headings
- H1 includes the canonical entity label where it reads naturally
- First H2 introduces a precise definition or scopes the page’s coverage
Definition block
- Single-sentence definition within the first 100 words
- If ambiguous, add a short “This page covers X, not Y” clarification immediately after
Attributes and qualifiers
- Include key properties that narrow meaning: industry, geography, format, version, scale
Media
- Replace generic hero images with entity-revealing visuals
- Add captions that name the entity and a relevant attribute
Anchors
- First internal link to the hub uses the exact canonical entity label
- Subsequent links use attribute anchors aligned to search intent variants
Glossary popovers
- Where overlapping terms exist, insert a short tooltip definition matching your disambiguation note
Cannibalization check
- If two pages target the same entity, designate one as the hub and retitle or re-scope the other before shipping either
Before-and-After Examples
| Element | Before | After |
|---|---|---|
| H1 | The Complete Platform You Need | Acme HR Software — HRIS for mid-market teams |
| Opening | Our platform helps HR teams do more. | Acme HR Software is a Human Resource Information System for mid-market HR teams. This page covers HRIS capabilities, not standalone payroll apps. |
| Image caption | Powerful dashboard | Acme HR Software dashboard showing employee records — the core HRIS database |
Guardrails
- Use the canonical label clearly once, then vary with attribute qualifiers — do not repeat the exact phrase unnaturally
- Keep all edits inside the current layout — no template or design debt in this sprint
- Keep definitions consistent with sameAs references and hub copy
Step 4: Add and Validate Schema
Start with minimal, high-signal JSON-LD that accurately reflects the visible page content. Validate everything before deploying. Keep a change log entry for every deployment.
Prioritized Schema Types by Page Type
| Page type | Schema type |
|---|---|
| Product or feature page | SoftwareApplication or Product embedded in WebPage |
| Informational article or guide | Article with mainEntity and about |
| Category or hub page | CollectionPage or WebPage with about array |
| Homepage and About page | Organization with sameAs; add BreadcrumbList sitewide if already supported |
Key distinction: Use
mainEntitywhen the page is the entity (product pages, glossary definitions). Useaboutwhen the page discusses an entity (articles, guides). Mixing these up is a common error that creates schema that contradicts your visible content.
Required Properties for Safe Deployment
All types: @context, @type, name, url
mainEntityoraboutreferencing your primary entitysameAsarray using authoritative sources (see Step 2 priority order)
SoftwareApplication: applicationCategory, operatingSystem, offers (only if pricing is explicitly stated on the page)
Article: headline, datePublished, author, mainEntityOfPage
JSON-LD Examples
SoftwareApplication on a product page:
{
"@context": "https://schema.org",
"@type": "WebPage",
"url": "https://acme.com/hr-software",
"name": "Acme HR Software - HRIS for mid-market teams",
"mainEntity": {
"@type": "SoftwareApplication",
"name": "Acme HR Software",
"applicationCategory": "Human Resource Information System",
"operatingSystem": "Web",
"url": "https://acme.com/hr-software",
"sameAs": [
"https://www.wikidata.org/wiki/Q1234567",
"https://www.linkedin.com/company/acme",
"https://www.crunchbase.com/organization/acme"
],
"offers": {
"@type": "Offer",
"priceSpecification": {
"@type": "PriceSpecification",
"priceCurrency": "USD"
},
"url": "https://acme.com/pricing"
}
}
}
Article with concept entity:
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "What is HRIS? Definition, examples, and architecture",
"url": "https://acme.com/what-is-hris",
"mainEntityOfPage": "https://acme.com/what-is-hris",
"author": {
"@type": "Organization",
"name": "Acme"
},
"about": [
{
"@type": "Thing",
"name": "Human Resource Information System",
"sameAs": [
"https://en.wikipedia.org/wiki/Human_resource_information_system",
"https://www.wikidata.org/wiki/Q890123"
]
}
],
"datePublished": "2024-06-05",
"dateModified": "2024-07-01"
}
Organization on homepage:
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "Acme, Inc.",
"url": "https://acme.com",
"logo": "https://acme.com/assets/logo.png",
"sameAs": [
"https://www.linkedin.com/company/acme",
"https://www.crunchbase.com/organization/acme",
"https://en.wikipedia.org/wiki/Acme_Inc"
]
}
Validation Workflow
- Paste code into Rich Results Test — confirm eligibility and no critical errors
- Paste into Schema Markup Validator — check type and property validity
- Deploy to staging and re-run both validations
- After publishing, use URL Inspection → Request Indexing in GSC
- Add a change log entry immediately (see Step 7 for the change log format)
Common Mistakes to Avoid
- Adding
FAQPageschema when no visible Q&A exists on the page sameAspointing to sales pages, low-authority directories, or internal redirectsmainEntitythat contradicts your H1 or definition sentenceofferswith an exact price when the page only shows a range or “contact us”- Using
abouton a product page instead ofmainEntity(or vice versa)
Step 5: Reinforce Entity Signals with Internal Linking
Internal links reinforce entity meaning and distribute authority safely. Design linking rules that writers and editors can follow without new tooling.
Hub-and-Spoke Architecture
Every entity needs exactly one hub page — the canonical source that defines the entity and hosts deep links to related spokes. The hub URL must be consistent across all linking. Spokes must link back to the hub using the canonical entity label as the anchor text near the top of the page.
If a hub does not yet exist for a primary entity you are recovering, create a minimal hub (even a short glossary entry) and link to it from all relevant spokes before the sprint ends.
Linking and Anchor Rules
- First mention on a spoke: link to hub using the exact canonical entity label
- Secondary anchors: use attribute qualifiers aligned to search intent (e.g., “hr software for small business,” “hris database schema”)
- Hub pages: include a Related topics or Learn more module linking to high-value spokes
- Product pages: include a “From the glossary” or “Compare to alternatives” section where relevant
- Volume limit: 1 canonical hub link near the top + 2 to 4 contextual links to related entities per page
- Avoid reciprocal spoke-to-spoke link loops unless a comparison intent exists
Checklist Before Shipping Links
- [ ] Single hub URL exists for the entity
- [ ] Each spoke links to the hub within the first 150 words
- [ ] First anchor is exactly the canonical entity label
- [ ] 2 to 4 contextual links to related entities or features per page
- [ ] Comparison pages link both ways using “compare” anchors
- [ ] No two pages competing for the same canonical label (if yes, pick a winner and adjust titles)
Guardrails
- Do not mass-insert identical anchors sitewide — vary context naturally
- Do not create orphan hubs — every hub must be reachable from global nav or a sitemap module
Step 6: Stabilize Brand Entity Signals
If Google cannot consistently identify your brand entity, page-level fixes will collide with mixed signals at the brand level. Stabilize brand signals first — these are low-lift and high-leverage.
Core Actions
Organization schema Ensure a single Organization JSON-LD on the homepage and About page with name, url, logo, and authoritative sameAs. Use the same logo URL that appears in your brand panel if one exists.
Consistent brand name Use one canonical brand string in page titles, authorship bylines, footer copyright, and social bios. A different name in Org schema versus your Wikipedia entry is one of the fastest ways to split entity signals.
Resolve lookalike conflicts If another brand shares your name, add a qualifier in the first sentence of your About page and in the description field of Org schema.
Example: Acme, Inc. is an HR software company — not the logistics brand Acme Corp.
Logo and site name Confirm the correct logo file path and site name are set consistently across all pages. Inconsistency here causes Knowledge Panel instability.
Success Criteria
Branded searches surface a single, accurate entity with the correct name, logo, official website, and authoritative sameAs. Key pages pass schema validation without critical errors.
Warning Signals
- Knowledge Panel intermittently shows another logo or wrong description
- Search results mix two different official sites for brand queries
- Org schema
namediffers from the brand string used in Wikipedia or GSC sitelinks
Step 7: Measurement, Change Log, and Rollback
You need conservative recovery estimates, a simple daily scoreboard, and a clear process to revert changes safely if volatility worsens.
Per-Page Recovery Estimates
Baseline: Last 28 days — clicks, impressions, CTR, position Loss: Delta vs. previous 28 days
Recovery rate by confidence level:
| Confidence | Rate | When to use |
|---|---|---|
| High | 35–40% of lost clicks | sameAs and on-page definitions were clearly absent; fixes are direct |
| Medium | 20–30% of lost clicks | Partial signals present; some ambiguity but not severe |
| Low | 10–15% of lost clicks | Competitors changed intent; SERP format shifted; cause uncertain |
Formula: Est. recovery clicks (28d) = Lost clicks × recovery rate Example: Page lost 1,300 clicks. Medium confidence → 1,300 × 25% = 325 clicks estimated recovery in 28 days after indexing.
These estimates are ranges for executive communication, not guarantees. Present them with confidence levels visible, not as a single number.
KPIs and Daily Checkpoints
| Checkpoint | What to check |
|---|---|
| Daily (Days 1–14) | GSC page-level impressions and average position trend |
| Days 3–5 | Schema indexed: use URL Inspection + Rich Results Test re-fetch |
| Day 7 | Impressions stabilizing vs. pre-change 7-day baseline |
| Day 14 | Directional improvement in impressions and CTR on updated anchor pages |
On indexing lag: After clicking Request Indexing, Google may take 5 to 10 days (sometimes longer) to recrawl, process schema, and update GSC data. Do not treat a flat Day 7 as a failure signal. Watch impressions as the leading indicator — position and clicks typically recover later. Panic-reverting before Day 10 is the most common avoidable mistake.
Change Log — Required Fields
Maintain one shared log for all changes across all pages.
| Field | Description |
|---|---|
| Date and time | When the change was deployed |
| Page URL | |
| Change summary | What was changed (H1 wording, schema type added, anchor text, etc.) |
| JSON-LD version | Version label if applicable |
| Validator screenshots | Link to Drive folder with validation results |
| Owner | Who deployed |
| Expected effect | What metric should move and in which direction |
| Rollback plan | Exact steps to revert this specific change |
Example entry:
Date: 2024-07-03
Page: https://acme.com/hr-software
Change: Added definition sentence to opening paragraph, updated H1, added SoftwareApplication JSON-LD with sameAs to Wikidata Q1234567 and LinkedIn
JSON-LD version: v1.0
Validator: [Drive link — Rich Results Test pass + Schema Validator pass]
Owner: Ravi
Expected effect: Impressions increase within 7–10 days post-indexing
Rollback: Remove JSON-LD block and revert H1 to previous version if CTR drops 20% sustained over 7 days post-indexing
Rollback Triggers
Monitor these signals for 5 to 7 days after confirmed indexing (not after deploy):
- Impressions −30% vs. pre-change 7-day average — with no sitewide cause (core update, crawl anomaly)
- CTR −20% while position is stable or improving
- Schema critical errors flagged in validators
Rollback action: Revert only the most recent change entry in the log. Do not roll back multiple changes at once. Request recrawl immediately after reverting and record a rollback entry in the log. If the issue persists after reverting, pause further changes to that page set and revisit the disambiguation notes — the entity hypothesis may need revision.
Step 8: Package the Plan for Executive Sign-Off
Executives approve faster when revenue math, owners, risk controls, and expected outcomes are visible on one page. Use the template below as the cover; attach the mapping sheet and change log as annexes.
One-Page Executive Summary Template
Title: 14-day entity-first recovery — [N] priority pages and expected impact
Situation (one line): Traffic dropped after core update, concentrated on [N] pages where Google is confusing [Entity A] with [Entity B].
Plan (three bullets):
- Clarify entity signals on [N] priority pages with on-page definition edits, anchor standardization, and JSON-LD
- Strengthen internal links to entity hubs and stabilize brand entity signals
- Validate all changes, monitor GSC daily with defined rollback triggers, and rollback individual changes if negative thresholds are crossed
Scope and owners: Pages: [top 5–10 URLs] Owners: [PM name], [Content name], [Dev name] with due dates
Effort and timeline:
- Week 1: Entity mapping, on-page edits, Org schema audit
- Week 2: JSON-LD deployment, internal links, validation, measurement baselines, executive package
Expected outcome (business terms): Stabilize impressions within 7–10 days. Recover [X–Y] monthly clicks on priority pages within 30–45 days. At current conversion rate of [Z%], this represents approximately [N] additional leads per month without incremental ad spend.
Risk controls: No template changes, all schema validated before deploy, change log maintained, rollback thresholds defined per page, freeze on new experiments during rollback periods.
What approval unlocks: [N] content hours, [N] dev hours, JSON-LD deploy permissions, internal link update rights.
Filled Example
Title: 14-day entity-first recovery — 12 priority pages
Situation: Post-core-update, 12 pages lost 18,500 clicks in 28 days. GSC query data confirms entity confusion between Acme’s HRIS product and generic HR consulting services — not a technical or brand navigational issue.
Plan:
- Clarify entity labels and definitions on 12 pages, add sameAs JSON-LD, standardize anchors
- Route internal links through HRIS and HR software hubs
- Validate schema, log all deployments, monitor GSC daily with rollback triggers
Scope: 12 URLs | PM: Dana | Content: Lee | Dev: Ravi
Timeline: Week 1: on-page + Org schema | Week 2: JSON-LD + links + validation
Expected outcome: Stabilize impressions by Day 10. Recover 5,000–7,000 clicks/month in 45 days. At 2% conversion, approximately 100–140 additional leads per month at zero incremental ad cost.
Risk controls: No template edits, all schema validated, rollback if CTR drops 20% for 7 days post-indexing
Approval unlocks: 24 content hours, 8 dev hours, JSON-LD permissions
Sign-Off Standard
Verbal approval is not enough. Secure written confirmation (email or doc) from each function covering: owners, hours allocated, and go-live window. If leadership questions the validation or rollback sections, that is an early warning — do not remove them. These controls are what make the plan safe to approve.
Day-by-Day Execution Timeline
| Days | Actions |
|---|---|
| 1–2 | GSC triage, validate root cause (Step 0), select 10–20 pages, start mapping sheet and draft disambiguation notes |
| 3–5 | Ship on-page edits: H1, definition sentence, image captions, first-anchor rules |
| 3–5 | Write JSON-LD drafts and validate in Rich Results Test and Schema Markup Validator |
| 6–8 | Deploy JSON-LD to 5–8 pages, request indexing, log all changes |
| 6–8 | Add internal links and related modules where trivial to implement |
| 9–12 | Complete JSON-LD for remaining pages, finalize brand Org schema |
| 9–12 | Build executive one-pager and per-page writer briefs |
| 9–12 | Begin daily GSC monitoring, capture and file validator screenshots |
| 13–14 | Package plan with owners, timelines, estimates, guardrails |
| 13–14 | Present one-pager, secure written approval |
Writer-Ready Brief Template (One Per Page)
Produce one of these for each priority page and hand to the content owner.
Page URL and type:
Primary entity:
Disambiguation sentence (copy exactly into opening paragraph):
Secondary entities to mention and define (3–5):
On-page edits:
- H1 (exact wording):
- Definition sentence (exact wording, place within first 100 words):
- Image caption (exact wording):
Anchors:
- First anchor text (exact canonical label → hub URL):
- 2 contextual anchor variants with qualifiers:
Schema:
- Type to add:
- Where it will live in the CMS:
- sameAs list (in priority order):
Internal links to add:
- Where in copy:
- Destination URL:
Owner:
Due date:
Rollback condition:
Operating Rules for the Sprint
Keep these visible for every team member working on this plan:
- No template or layout changes inside 14 days. On-page text, schema, and anchors only.
- Only add schema that reflects visible content. If the page does not show it, the schema should not claim it.
- Validate in Rich Results Test and Schema Markup Validator before every deployment — no exceptions.
- Log every change before closing the browser tab. An unlogged change cannot be safely rolled back.
- Do not roll back based on Day 3–5 data. Wait for confirmed indexing (typically 5–10 days) before evaluating impact.
- One rollback action at a time. Revert the most recent log entry only, then observe before reverting more.
- If entity ambiguity is not confirmed as the root cause, stop and revisit Step 0.
You now have a two-week, low-risk, entity-first recovery plan: root cause validated before committing resources, priority pages selected by severity, entities mapped with authoritative references, on-page and schema fixes shipped safely, internal links reinforced, and everything packaged for executive approval with forecasts, owners, and rollback controls. Keep the change log tight and signals consistent.