Google Knowledge Panels: A Practical Guide

START

---
name: classify-and-offer-knowledge-panel
description: "Choose the right next step for your name on Google."
category: Personal Branding
stage: —
definitive_article: /knowledge-panel
status: needs-work
---

# Classify and offer Knowledge Panel

Choose the right work to help people find you on Google. This keeps your team from selling work you do not need. First, [check who each profile belongs to](https://local-service-spotlight.github.io/task-library/?task=establish-entity-identity#task-establish-entity-identity); that proof helps you tell your results from someone else’s.

**The path:** Live search + proof → Claim / Build / Contested → Current terms → Offer draft

**Start when:** An accepted prospective engagement needs an evidence-based panel-work recommendation and a matching draft offer.

## Inputs

- The person’s accepted public name, role, home site and existing identity evidence.
- Current search access, the approved service terms and qualification rules, and the actual commercial decision owner.
- [Current owned package page](https://localservicespotlight.com/knowledge-panel-package/) and [Google’s account of how panels work](https://support.google.com/knowledgepanel/answer/9163198?hl=en); reconcile any conflict with the accepted engagement before quoting.

## Steps

1. Run a fresh name search and record query, location or locale where known, device, date and screenshots. Inspect the result’s identity, not merely the displayed name. A signed-out search reduces some personalization but does not remove all contextual variation.
2. Classify Claim/correct only when the right panel offers the needed claim or edit route. An entity ID is a code for a named person or thing in Google’s data. It does not prove the right panel offers a claim or edit route. Classify Build as supported identity/proof work still needed; use contested review for ambiguity or a crowded name.
3. Check the person’s existing public home, verified profiles and independent evidence. State the actual gaps and the services within scope. Do not promise that a checklist, payment, name domain or schema will force Google to display a panel.
4. Read the current approved price, deposit, milestone and refund terms from their maintained source. If the public offer page omits a term, get the approved engagement or terms owner’s record; do not invent it or treat silence as a refund policy. The older skill’s dollar bands and duration ranges are historical source copy; this recipe does not set a new price or repeat them as current without that check.
5. Draft the matching recommendation with the evidence, exact deliverables, owner-controlled verification account, dependencies and accepted commercial terms. Tie each milestone to its actual contract definition. Keep proposed service work distinct from Google’s decision and from a completed claim.
6. Route ambiguous scope, conflicting terms and contested identities to the responsible commercial or entity-review function with the finished evidence packet. A named colleague’s availability is not a reason to pause safe research, nor authority to send an unapproved offer.
7. Save the decision and draft. Send only under existing authorization and record the exact sent version when it happens. The classification task is checked when its evidence and matching proposal are reviewable; a sale or a panel is a later outcome.

## Output record and acceptance

For each accepted request, save the request ID and revision; search name, date, locale and result evidence; identity match; route (`claim/correct`, `build` or `contested`); evidence gaps; approved-terms source and revision; offer-draft link and state; and next function and owner. Count the in-scope names searched and classified, and drafts backed by current terms. The check passes when every recommendation can be traced to saved evidence and each quoted term matches its approved source. The person responsible for commercial terms records accept or return against the exact draft revision, with reviewer and date; contested identity goes to the identity reviewer. Keep these records in the approved private project space.

## Definition of done (QA checklist)

Quality assurance (QA) means checking the actual result against its agreed requirements. Follow the [Article Guidelines](https://localservicespotlight.com/article-guidelines/).

- [ ] The recommendation distinguishes identity evidence from an actual claim/edit route.
- [ ] All quoted commercial terms match the current approved source; unsupported timing promises are absent.
- [ ] The evidence-backed offer remains accurately labeled draft or sent, with the next owner named.
- [ ] The exact output, source revision, reviewer evidence and remaining owner action are saved.
- [ ] For any reader-facing output, the short grade-five opening states the reader’s useful outcome and supporting method or proof. The body delivers that promise; a useful authentic visual appears in the first screen. Retain exact text and quoted reviewer evidence.

## Example(s)

**Fictional teaching example. This is not a client result or proof of a completed run.**

A fictional accountant has a name shared by a musician. The visible card belongs to the musician. The team prepares a contested-identity review with the accountant’s true work and site. It does not sell a ready-to-claim service or borrow an old price; the current offer owner must supply the actual terms.

## Handoff and Content Factory context

The person responsible for commercial terms receives the exact proposal for acceptance. The identity reviewer receives a contested case before an offer is sent. After scope approval, [resolve identity facts](https://local-service-spotlight.github.io/task-library/?task=establish-entity-identity#task-establish-entity-identity) or [claim an available panel](https://local-service-spotlight.github.io/task-library/?task=claim-and-verify-knowledge-panel-when-it-appears#task-claim-and-verify-knowledge-panel-when-it-appears) receives the supported route.

This is a qualification gate before the [Content Factory](https://blitzmetrics.com/content-factory/) starts. Once work is accepted, [Establish entity identity](https://local-service-spotlight.github.io/task-library/?task=establish-entity-identity#task-establish-entity-identity) supplies checked facts for later site or schema work. This task produces a sourced route and offer draft; it does not make a content asset.

## Start with an agent

Give the [AI worker](https://blitzmetrics.com/build-agents/) this recipe, the real inputs, desired result and actions already authorized. Ask for the saved output, sources, checks and next owner. A [skill is a written recipe](https://localservicespotlight.com/plugin/); loading one does not prove account access or perform the task. Use the [installation guide](https://localservicespotlight.com/install/) if reusable setup is needed. A ZIP is a source snapshot, not an access grant or automatic update.

Use the app’s actual supported tools and verified file/account access. Keep a missing human verification step with its real owner. Recurring work needs its own configured job, trigger, timezone and observed result; this guide creates no schedule. Before any media playback, mute the player and set its volume to zero. If silence cannot be verified first, use captions, frames, metadata or another silent check.

## Record the real execution

Open the run record when work begins. Keep one execution ID, starting recipe revision, real inputs and current state. Write the [meta article, the record of this execution](https://blitzmetrics.com/meta-article-prompt/) with actual steps, results, checks, failures and next owner. Writing is required; public release follows existing authority. Link it to this recipe and the [Task Library](https://local-service-spotlight.github.io/task-library/).

Reuse the same execution ID for internal checks, revisions, retries and meta writing. A blocked run stays open with its dependency and owner, without an invented finish time. Dated public examples and distinct verified execution counts remain separate. Propose the smallest source-backed recipe improvement when the actual evidence reveals a defect.

## Definitive article & links

- [Maintained source guide](https://blitzmetrics.com/knowledge-panel/)
- [This task in the Task Library](https://local-service-spotlight.github.io/task-library/?task=classify-and-offer-knowledge-panel#task-classify-and-offer-knowledge-panel)
- [Article Guidelines](https://localservicespotlight.com/article-guidelines/)
- [Definitive article and task recipe standard](https://blitzmetrics.com/definitive-article-guide/)
- [How recipes and run records fit together](https://localservicespotlight.com/meta-articles/)

### Primary method references

- [Google panel explanation](https://support.google.com/knowledgepanel/answer/9163198?hl=en)

## Review and evidence still needed

The inherited contributor status is `needs-work`. It is preserved, not promoted by this rewrite. That label alone does not prove document readiness, account access, an actual execution or a client result.

The fictional example teaches the method and does not fill a real-run evidence gap. A named semantic reviewer must check the actual opening, full method, sources and handoff. Check the useful opening visual in the normal rendered guide at the current required desktop and mobile sizes, including 1280 × 800 and 390 × 844. Source readability checks do not prove public presentation or task execution.

END

START

---
name: establish-entity-identity
description: "Make it clear which person a page is about."
category: Personal Branding
stage: Process
definitive_article: /knowledge-panel
status: needs-work
---

# Establish entity identity

Check which web pages are about you. This helps your team keep your facts apart from those of someone with the same name. Pass the checked facts to [the site code setup](https://local-service-spotlight.github.io/task-library/?task=implement-person-schema-with-sameas-links#task-implement-person-schema-with-sameas-links) so search tools can read the same facts as your readers.

**The path:** Known person → Profile inventory → Fact and identity checks → Corrected source map

**Start when:** An identity audit or panel project needs one verified record of the person and known naming conflicts.

## Inputs

- [Align photos and bio facts](https://local-service-spotlight.github.io/task-library/?task=add-consistent-headshots-and-bios-across-profiles#task-add-consistent-headshots-and-bios-across-profiles) with the approved name, real photo and current role facts.
- The person’s home site, known profiles, outside sources and current structured markup.
- Actual edit rights and a defined research scope; prior collisions and rejected identity matches.

## Steps

1. Create or update the existing identity record. Include the accepted professional name, valid alternate names, home URL, role and organization with source evidence. A person may have legitimate historic names and photos; consistency means resolving facts, not deleting their history.
2. Inventory the in-scope owned and outside pages. Record URL, source type, name used, current role, image, website target and evidence date. Search known variants and useful languages; record coverage limits rather than claiming to find every page on the web.
3. Resolve each page to this person using its actual role, organization, context and sources. A matching name, a search snippet or a photo with another person is insufficient. Keep wrong-person and uncertain matches excluded from accepted identity links.
4. Compare current owned fields with the approved record. Prepare corrections for factual drift and broken links. Preserve valid older credits with their dates. Retiring profiles, redirecting URLs or changing another publisher’s page requires its actual owner and existing authority.
5. Inspect the live website’s Person markup, meaning structured facts identifying the person. Reuse one stable identity ID for that person across relevant blocks. Person and business remain separate entities; do not merge the person with a company profile simply because they own it.
6. After authorized corrections, reopen affected pages and check saved facts and destinations. Pass verified identity pages to [Add verified Person markup](https://local-service-spotlight.github.io/task-library/?task=implement-person-schema-with-sameas-links#task-implement-person-schema-with-sameas-links). An inaccessible source stays unresolved until a supported inspection proves its identity; a response code alone is insufficient.
7. Save accepted aliases, rejected matches, checked sources and next actions. Review when a role, domain or profile changes. Any quarterly schedule needs its real owner and observed configuration; clean identity evidence does not guarantee a [Knowledge Panel, Google’s information box for an entity](https://blitzmetrics.com/knowledge-panel/).

## Output record and acceptance

Save one versioned identity map with a row for each in-scope source: URL, source type and check date; displayed name and role; match state (`accepted`, `rejected` or `unknown`); evidence links; conflict; proposed correction and owner. Report the number of rows checked in each state. The map passes when every accepted row has supporting evidence and names the person separately from any company; unresolved sources stay `unknown` and out of accepted links. The person responsible for checking identity evidence records accept or return against the exact map revision, reviewer and date. Only accepted URLs and facts go to the Person schema task.

## Definition of done (QA checklist)

Quality assurance (QA) means checking the actual result against its agreed requirements. Follow the [Article Guidelines](https://localservicespotlight.com/article-guidelines/).

- [ ] Accepted pages unambiguously describe the intended person; aliases and collisions remain documented.
- [ ] Corrected owned facts are read back and outside corrections have their actual state.
- [ ] The identity map distinguishes Person and company and supplies verified sources to schema work.
- [ ] The exact output, source revision, reviewer evidence and remaining owner action are saved.
- [ ] For any reader-facing output, the short grade-five opening states the reader’s useful outcome and supporting method or proof. The body delivers that promise; a useful authentic visual appears in the first screen. Retain exact text and quoted reviewer evidence.

## Example(s)

**Fictional teaching example. This is not a client result or proof of a completed run.**

A fictional designer shares her name with an actor. A podcast page names her design firm, while a film page belongs to the actor. The team accepts the podcast profile and excludes the film page. An old employer bio stays as dated career history, with only its broken current-site link proposed for repair.

## Handoff and Content Factory context

The person responsible for checking identity evidence accepts or returns the exact map revision. After acceptance, [Person schema setup](https://local-service-spotlight.github.io/task-library/?task=implement-person-schema-with-sameas-links#task-implement-person-schema-with-sameas-links) receives only accepted URLs and facts. [Check outside proof](https://local-service-spotlight.github.io/task-library/?task=build-third-party-validation#task-build-third-party-validation) receives unresolved source questions when independent proof is still needed.

**Content Factory stage: Process.** This task turns supplied profile and site evidence into a checked identity map for later page and schema work. The [Content Factory](https://blitzmetrics.com/content-factory/) uses this checked record before Post. This recipe may correct owned fields within existing authority; outside corrections remain with their owner.

## Start with an agent

Give the [AI worker](https://blitzmetrics.com/build-agents/) this recipe, the real inputs, desired result and actions already authorized. Ask for the saved output, sources, checks and next owner. A [skill is a written recipe](https://localservicespotlight.com/plugin/); loading one does not prove account access or perform the task. Use the [installation guide](https://localservicespotlight.com/install/) if reusable setup is needed. A ZIP is a source snapshot, not an access grant or automatic update.

Use the app’s actual supported tools and verified file/account access. Keep a missing human verification step with its real owner. Recurring work needs its own configured job, trigger, timezone and observed result; this guide creates no schedule. Before any media playback, mute the player and set its volume to zero. If silence cannot be verified first, use captions, frames, metadata or another silent check.

## Record the real execution

Open the run record when work begins. Keep one execution ID, starting recipe revision, real inputs and current state. Write the [meta article, the record of this execution](https://blitzmetrics.com/meta-article-prompt/) with actual steps, results, checks, failures and next owner. Writing is required; public release follows existing authority. Link it to this recipe and the [Task Library](https://local-service-spotlight.github.io/task-library/).

Reuse the same execution ID for internal checks, revisions, retries and meta writing. A blocked run stays open with its dependency and owner, without an invented finish time. Dated public examples and distinct verified execution counts remain separate. Propose the smallest source-backed recipe improvement when the actual evidence reveals a defect.

## Definitive article & links

- [Maintained source guide](https://blitzmetrics.com/knowledge-panel/)
- [This task in the Task Library](https://local-service-spotlight.github.io/task-library/?task=establish-entity-identity#task-establish-entity-identity)
- [Article Guidelines](https://localservicespotlight.com/article-guidelines/)
- [Definitive article and task recipe standard](https://blitzmetrics.com/definitive-article-guide/)
- [How recipes and run records fit together](https://localservicespotlight.com/meta-articles/)

### Primary method references

- [Google: how panels work and who can suggest edits](https://support.google.com/knowledgepanel/answer/9163198?hl=en)
- [Google: accurate, visible structured data](https://developers.google.com/search/docs/appearance/structured-data/sd-policies)

## Review and evidence still needed

The inherited contributor status is `needs-work`. It is preserved, not promoted by this rewrite. That label alone does not prove document readiness, account access, an actual execution or a client result.

The fictional example teaches the method and does not fill a real-run evidence gap. A named semantic reviewer must check the actual opening, full method, sources and handoff. Check the useful opening visual in the normal rendered guide at the current required desktop and mobile sizes, including 1280 × 800 and 390 × 844. Source readability checks do not prove public presentation or task execution.

END

START

---
name: build-third-party-validation
description: "Help people check your work with proof from other sources."
category: Personal Branding
stage: —
definitive_article: /knowledge-panel
status: needs-work
---

# Build third-party validation

Help people check your work with proof from other sources. This guide sorts press, talks and interviews into a clear record. Start with the real links you already have, then find what each one shows.

**The path:** Existing coverage → Identity and source checks → Proof inventory → Public use proposal

**Start when:** Identity facts are established and the team needs a checked inventory of outside evidence and gaps.

## Inputs

- [Check the person’s identity](https://local-service-spotlight.github.io/task-library/?task=establish-entity-identity#task-establish-entity-identity) with the accepted name, role, home site and known collisions.
- Existing press, podcast, talk, book and directory records, plus their source URLs, dates and use permissions.
- The actual claim to support and approved research scope; [Collect and classify positive mentions](https://local-service-spotlight.github.io/task-library/?task=positive-mentions-harvester#task-positive-mentions-harvester) classification rules.

## Steps

1. Read the current proof inventory and append there. Record the source title, URL, date, author, named subject, exact supported fact and whether the material is independent, self-published, paid or a simple appearance. Avoid counting syndicated copies as independent coverage.
2. Search the accepted names, useful variants and the languages in which the person has lived and worked. Inspect the primary page or supplied source, not just a search summary. Record sources or languages that remain inaccessible so a thin search is not labeled a thin career.
3. Resolve same-name people with role, organization, location and the source’s actual context. Keep the narrowest true claim: a speaker listing proves a scheduled role; a recorded delivered talk proves participation; praise requires actual attributable positive language.
4. Build the gap list around the reader’s needed proof. Use the podcast, speaking and press tasks to propose suitable opportunities. A missing type of proof is not permission to purchase a placement or manufacture a book credit.
5. Consider Wikidata only after checking its current notability rules, existing items, reliable references and identity fit. Wikipedia has separate notability and conflict-of-interest rules. Document the route and disclose relevant interests; neither platform is a compulsory branding checkbox or a guaranteed Google panel source.
6. Select the strongest relevant public-safe proof for the site with a short account of what it establishes. Keep permissions and private locators in the governed record. Pass only true identity pages to the schema task; an ordinary press story is a citation, not automatically a sameAs identity.
7. Save the covered scope, accepted and held records, changed facts and next owner. A bounded inventory pass can finish with honest gaps; new placements, a growing quarterly count or a Knowledge Panel are separate outcomes.

## Definition of done (QA checklist)

Quality assurance (QA) means checking the actual result against its agreed requirements. Follow the [Article Guidelines](https://localservicespotlight.com/article-guidelines/).

- [ ] Every accepted item identifies the right subject and the exact fact its source supports.
- [ ] Independent coverage, appearances, praise and duplicates are classified separately.
- [ ] The source-backed inventory and gap plan are saved; no new public placement or panel is invented.
- [ ] The exact output, source revision, reviewer evidence and remaining owner action are saved.
- [ ] For any reader-facing output, the short grade-five opening states the reader’s useful outcome and supporting method or proof. The body delivers that promise; a useful authentic visual appears in the first screen. Retain exact text and quoted reviewer evidence.

## Example(s)

**Fictional teaching example. This is not a client result or proof of a completed run.**

A fictional trainer has two interviews and a shared event photo. One interview contains a named client’s praise; the other is a neutral Q&A. The photo shows attendance only. The inventory keeps those three meanings separate and proposes a topic-specific speaking pitch, without presenting all three items as endorsements.

## Handoff and Content Factory context

[Review identity markup](https://local-service-spotlight.github.io/task-library/?task=implement-technical-schema-markup#task-implement-technical-schema-markup) receives verified identity pages. The site owner receives approved proof cards; press and podcast tasks receive scoped gaps.

This task supports the [Content Factory: Produce, Process, Post and Promote](https://blitzmetrics.com/content-factory/). Identity, proof, access or coordination can support several stages. Use the real inputs and receiving owner above; this task does not create unrelated transcripts, clips or ads merely because the diagram has four stages.

## Start with an agent

Give the [AI worker](https://blitzmetrics.com/build-agents/) this recipe, the real inputs, desired result and actions already authorized. Ask for the saved output, sources, checks and next owner. A [skill is a written recipe](https://localservicespotlight.com/plugin/); loading one does not prove account access or perform the task. Use the [installation guide](https://localservicespotlight.com/install/) if reusable setup is needed. A ZIP is a source snapshot, not an access grant or automatic update.

Use the app’s actual supported tools and verified file/account access. Keep a missing human verification step with its real owner. Recurring work needs its own configured job, trigger, timezone and observed result; this guide creates no schedule. Before any media playback, mute the player and set its volume to zero. If silence cannot be verified first, use captions, frames, metadata or another silent check.

## Record the real execution

Open the run record when work begins. Keep one execution ID, starting recipe revision, real inputs and current state. Write the [meta article, the record of this execution](https://blitzmetrics.com/meta-article-prompt/) with actual steps, results, checks, failures and next owner. Writing is required; public release follows existing authority. Link it to this recipe and the [Task Library](https://local-service-spotlight.github.io/task-library/).

Reuse the same execution ID for internal checks, revisions, retries and meta writing. A blocked run stays open with its dependency and owner, without an invented finish time. Dated public examples and distinct verified execution counts remain separate. Propose the smallest source-backed recipe improvement when the actual evidence reveals a defect.

## Definitive article & links

- [Maintained source guide](https://blitzmetrics.com/knowledge-panel/)
- [This task in the Task Library](https://local-service-spotlight.github.io/task-library/?task=build-third-party-validation#task-build-third-party-validation)
- [Article Guidelines](https://localservicespotlight.com/article-guidelines/)
- [Definitive article and task recipe standard](https://blitzmetrics.com/definitive-article-guide/)
- [How recipes and run records fit together](https://localservicespotlight.com/meta-articles/)

### Primary method references

- [Wikidata notability](https://www.wikidata.org/wiki/Wikidata:Notability)
- [Wikipedia conflict of interest](https://en.wikipedia.org/wiki/Wikipedia:Conflict_of_interest)

## Review and evidence still needed

The inherited contributor status is `needs-work`. It is preserved, not promoted by this rewrite. That label alone does not prove document readiness, account access, an actual execution or a client result.

The fictional example teaches the method and does not fill a real-run evidence gap. A named semantic reviewer must check the actual opening, full method, sources and handoff. Check the useful opening visual in the normal rendered guide at the current required desktop and mobile sizes, including 1280 × 800 and 390 × 844. Source readability checks do not prove public presentation or task execution.

END

START

---
name: implement-technical-schema-markup
description: "Keep the facts on your site clear as your work changes."
category: Personal Branding
stage: —
definitive_article: /knowledge-panel
status: needs-work
---

# Implement technical schema markup

Keep the facts on your site clear as your work changes. This guide checks your existing identity data and adds only what the sources support. Start with the live page and the last checked version of its facts.

**The path:** Existing graph + new proof → Verified fact changes → Source patch → Live graph check

**Start when:** A verified role, profile or source change requires maintenance of the existing identity graph.

## Inputs

- [Add verified Person markup](https://local-service-spotlight.github.io/task-library/?task=implement-person-schema-with-sameas-links#task-implement-person-schema-with-sameas-links) with the stable Person ID, source owner and prior validation receipt.
- The current identity/proof inventory and evidence for changed roles or new identity pages.
- Actual site source access, visible page copy and the supported markup editor.

## Steps

1. Read the complete current graph from the live page and its maintained source. Identify which component emits each node. Record existing Person, Organization, WebPage and other IDs before editing so one task cannot silently overwrite unrelated structured content.
2. Compare the new facts with current visible copy and source evidence. Confirm a role change is current, not an old biography, and distinguish the person’s identity from an employer or business. Use separate nodes and a supported relationship such as worksFor only when it is true.
3. Assess each proposed identity link under [Schema.org’s sameAs definition](https://schema.org/sameAs). A durable speaker profile may qualify when it clearly identifies the same person; a press article or an organization’s GBP is not automatically that person’s identity. Exclude missing, wrong-person or unresolved targets and retain the review reason.
4. Add only supported fields such as current jobTitle, worksFor, alumniOf or knowsAbout. An expertise claim needs real visible evidence; an unearned title in machine-readable form is still a false claim. Update the visible page when an authorized fact correction requires it.
5. Prepare a focused source change that preserves the stable Person ID and other valid nodes. Check JSON syntax, Schema.org properties and any actually applicable Google feature requirements. “Knowledge Panel grade” is not a validator outcome or a published Google certification.
6. After authorized save, inspect the normal public page and its rendered markup. Verify the changed fields, one identity for the person, retained graph nodes and accepted profile links. Save exact source revision and validation results; a stale cached body is not a fresh readback.
7. Record a Google entity ID only when independently observed for the correct person. Panel appearance, claim state and commercial milestones stay in their own records. Set a named review trigger for future fact changes; do not claim that a skill file automatically maintains the graph.

## Definition of done (QA checklist)

Quality assurance (QA) means checking the actual result against its agreed requirements. Follow the [Article Guidelines](https://localservicespotlight.com/article-guidelines/).

- [ ] The focused graph change preserves the existing source owner, stable person identity and unrelated nodes.
- [ ] Every added field or identity link is current and evidence-backed.
- [ ] Live readback and validation are retained; panel and payment states are not inferred.
- [ ] The exact output, source revision, reviewer evidence and remaining owner action are saved.
- [ ] For any reader-facing output, the short grade-five opening states the reader’s useful outcome and supporting method or proof. The body delivers that promise; a useful authentic visual appears in the first screen. Retain exact text and quoted reviewer evidence.

## Example(s)

**Fictional teaching example. This is not a client result or proof of a completed run.**

A fictional analyst joins a new firm. The current site names the new firm but markup still names the old one. The developer changes the supported employer link under the existing Person ID and checks the public graph. A recent news story is added as visible proof, not as a second person identity or guaranteed panel trigger.

## Handoff and Content Factory context

[Check the actual claim opportunity](https://local-service-spotlight.github.io/task-library/?task=claim-and-verify-knowledge-panel-when-it-appears#task-claim-and-verify-knowledge-panel-when-it-appears) receives verified identity evidence when applicable; [Review search and real inquiries](https://local-service-spotlight.github.io/task-library/?task=measure-search-impressions-traffic-inbound-opportunities#task-measure-search-impressions-traffic-inbound-opportunities) receives the observed search state.

This task supports the [Content Factory: Produce, Process, Post and Promote](https://blitzmetrics.com/content-factory/). Identity, proof, access or coordination can support several stages. Use the real inputs and receiving owner above; this task does not create unrelated transcripts, clips or ads merely because the diagram has four stages.

## Start with an agent

Give the [AI worker](https://blitzmetrics.com/build-agents/) this recipe, the real inputs, desired result and actions already authorized. Ask for the saved output, sources, checks and next owner. A [skill is a written recipe](https://localservicespotlight.com/plugin/); loading one does not prove account access or perform the task. Use the [installation guide](https://localservicespotlight.com/install/) if reusable setup is needed. A ZIP is a source snapshot, not an access grant or automatic update.

Use the app’s actual supported tools and verified file/account access. Keep a missing human verification step with its real owner. Recurring work needs its own configured job, trigger, timezone and observed result; this guide creates no schedule. Before any media playback, mute the player and set its volume to zero. If silence cannot be verified first, use captions, frames, metadata or another silent check.

## Record the real execution

Open the run record when work begins. Keep one execution ID, starting recipe revision, real inputs and current state. Write the [meta article, the record of this execution](https://blitzmetrics.com/meta-article-prompt/) with actual steps, results, checks, failures and next owner. Writing is required; public release follows existing authority. Link it to this recipe and the [Task Library](https://local-service-spotlight.github.io/task-library/).

Reuse the same execution ID for internal checks, revisions, retries and meta writing. A blocked run stays open with its dependency and owner, without an invented finish time. Dated public examples and distinct verified execution counts remain separate. Propose the smallest source-backed recipe improvement when the actual evidence reveals a defect.

## Definitive article & links

- [Maintained source guide](https://blitzmetrics.com/knowledge-panel/)
- [This task in the Task Library](https://local-service-spotlight.github.io/task-library/?task=implement-technical-schema-markup#task-implement-technical-schema-markup)
- [Article Guidelines](https://localservicespotlight.com/article-guidelines/)
- [Definitive article and task recipe standard](https://blitzmetrics.com/definitive-article-guide/)
- [How recipes and run records fit together](https://localservicespotlight.com/meta-articles/)

### Primary method references

- [Schema.org sameAs](https://schema.org/sameAs)
- [Google structured data policies](https://developers.google.com/search/docs/appearance/structured-data/sd-policies)

## Review and evidence still needed

The inherited contributor status is `needs-work`. It is preserved, not promoted by this rewrite. That label alone does not prove document readiness, account access, an actual execution or a client result.

The fictional example teaches the method and does not fill a real-run evidence gap. A named semantic reviewer must check the actual opening, full method, sources and handoff. Check the useful opening visual in the normal rendered guide at the current required desktop and mobile sizes, including 1280 × 800 and 390 × 844. Source readability checks do not prove public presentation or task execution.

END

START

---
name: claim-and-verify-knowledge-panel-when-it-appears
description: "Check the facts people see about you on Google."
category: Personal Branding
stage: —
definitive_article: /knowledge-panel
status: needs-work
---

# Claim and verify Knowledge Panel when it appears

Check the facts people see about you on Google. This guide helps you claim a panel when Google offers that option. Start with the live panel for the right person and the account that person controls.

**The path:** Correct panel → Offered claim flow → Owner verification → Checked claim and edits

**Start when:** Google displays the correct person’s panel and offers a claim flow, or an existing claim needs correction.

## Inputs

- [Classify the current panel state](https://local-service-spotlight.github.io/task-library/?task=classify-and-offer-knowledge-panel#task-classify-and-offer-knowledge-panel) with dated search evidence.
- The person’s authorized Google account and access to the official sites/profiles Google offers for verification.
- Accurate identity facts and evidence for requested corrections; [Google’s panel claim instructions](https://support.google.com/knowledgepanel/answer/7534902?hl=en).

## Steps

1. Find the correct panel in a current search and record the query, date, device and observed identity. An entity ID, sometimes called a KGMID, or a thin card does not by itself prove a claim flow exists. Keep not claimable as the current state.
2. Confirm the account and representative authority before taking the claim action. Use the person’s owner-controlled account and the verified public profiles requested by the offered flow. Helpers need their actual permitted role; the recipe does not grant account access.
3. Open the displayed claim control and follow [Google’s panel claim instructions](https://support.google.com/knowledgepanel/answer/7534902?hl=en). Google may request a connected official profile or more evidence. Let the account owner complete identity or recovery steps that require them, and keep sensitive verification material out of public run notes.
4. Read the result after submission. Submitted, pending, verified and already managed are distinct states. If the panel belongs to a different person or the account is already managed, use the documented support path rather than creating another identity or repeating blind submissions.
5. After verification, compare visible panel facts with current reliable sources. Correct owned source errors first, then suggest only supported panel changes through the offered control. A suggested edit is not an accepted edit; save each result separately.
6. Save the claim evidence, date, current facts, unresolved edits and next check owner. Use the existing review cadence only if it is actually assigned. A payment milestone is governed by the accepted engagement terms, not inferred from a search card or this checklist.

## Definition of done (QA checklist)

Quality assurance (QA) means checking the actual result against its agreed requirements. Follow the [Article Guidelines](https://localservicespotlight.com/article-guidelines/).

- [ ] The correct person’s claim state has direct current evidence; pending is not called verified.
- [ ] Requested and accepted fact changes are separate, supported and checked.
- [ ] Ownership, remaining human action and the next review are recorded without private verification data.
- [ ] The exact output, source revision, reviewer evidence and remaining owner action are saved.
- [ ] For any reader-facing output, the short grade-five opening states the reader’s useful outcome and supporting method or proof. The body delivers that promise; a useful authentic visual appears in the first screen. Retain exact text and quoted reviewer evidence.

## Example(s)

**Fictional teaching example. This is not a client result or proof of a completed run.**

A fictional founder’s information card shows her name but no claim button. The team records that card and its date, then continues the identity work. A later search offers claiming, so the owner completes the offered check. Until Google confirms that result, the record says pending rather than claimed.

## Handoff and Content Factory context

[Review search and real inquiries](https://local-service-spotlight.github.io/task-library/?task=measure-search-impressions-traffic-inbound-opportunities#task-measure-search-impressions-traffic-inbound-opportunities) receives the observed panel state. [Check identity facts](https://local-service-spotlight.github.io/task-library/?task=establish-entity-identity#task-establish-entity-identity) receives source corrections; the owner retains any pending verification step.

This task supports the [Content Factory: Produce, Process, Post and Promote](https://blitzmetrics.com/content-factory/). Identity, proof, access or coordination can support several stages. Use the real inputs and receiving owner above; this task does not create unrelated transcripts, clips or ads merely because the diagram has four stages.

## Start with an agent

Give the [AI worker](https://blitzmetrics.com/build-agents/) this recipe, the real inputs, desired result and actions already authorized. Ask for the saved output, sources, checks and next owner. A [skill is a written recipe](https://localservicespotlight.com/plugin/); loading one does not prove account access or perform the task. Use the [installation guide](https://localservicespotlight.com/install/) if reusable setup is needed. A ZIP is a source snapshot, not an access grant or automatic update.

Use the app’s actual supported tools and verified file/account access. Keep a missing human verification step with its real owner. Recurring work needs its own configured job, trigger, timezone and observed result; this guide creates no schedule. Before any media playback, mute the player and set its volume to zero. If silence cannot be verified first, use captions, frames, metadata or another silent check.

## Record the real execution

Open the run record when work begins. Keep one execution ID, starting recipe revision, real inputs and current state. Write the [meta article, the record of this execution](https://blitzmetrics.com/meta-article-prompt/) with actual steps, results, checks, failures and next owner. Writing is required; public release follows existing authority. Link it to this recipe and the [Task Library](https://local-service-spotlight.github.io/task-library/).

Reuse the same execution ID for internal checks, revisions, retries and meta writing. A blocked run stays open with its dependency and owner, without an invented finish time. Dated public examples and distinct verified execution counts remain separate. Propose the smallest source-backed recipe improvement when the actual evidence reveals a defect.

## Definitive article & links

- [Maintained source guide](https://blitzmetrics.com/knowledge-panel/)
- [This task in the Task Library](https://local-service-spotlight.github.io/task-library/?task=claim-and-verify-knowledge-panel-when-it-appears#task-claim-and-verify-knowledge-panel-when-it-appears)
- [Article Guidelines](https://localservicespotlight.com/article-guidelines/)
- [Definitive article and task recipe standard](https://blitzmetrics.com/definitive-article-guide/)
- [How recipes and run records fit together](https://localservicespotlight.com/meta-articles/)

### Primary method references

- [Google panel claim](https://support.google.com/knowledgepanel/answer/7534902?hl=en)

## Review and evidence still needed

The inherited contributor status is `needs-work`. It is preserved, not promoted by this rewrite. That label alone does not prove document readiness, account access, an actual execution or a client result.

The fictional example teaches the method and does not fill a real-run evidence gap. A named semantic reviewer must check the actual opening, full method, sources and handoff. Check the useful opening visual in the normal rendered guide at the current required desktop and mobile sizes, including 1280 × 800 and 390 × 844. Source readability checks do not prove public presentation or task execution.

END

START

---
name: measure-search-impressions-traffic-inbound-opportunities
description: "See whether people find your work and get in touch."
category: Personal Branding
stage: —
definitive_article: /knowledge-panel
status: needs-work
---

# Measure: search impressions, traffic, inbound opportunities

See whether people find your work and get in touch. This guide checks search, site visits and real inquiries in one report. Start with the same date range and a clear meaning for each number.

**The path:** Same date range → Checked sources → Supported meaning → Owned next step

**Start when:** The agreed reporting window has closed and the brand owner needs an evidence-based performance review.

## Inputs

- Actual read access or named exports from Search Console, site analytics and the inquiry record.
- Accepted metric definitions, timezones, current and comparison periods, relevant targets and earlier reports.
- The content/appearance timeline, actual panel observations and [Metrics, Analysis, Action: what happened, why and what to do](https://blitzmetrics.com/maa/).

## Steps

1. Define name-search impressions and clicks, organic site traffic and inbound opportunities separately. Record source, account/property, filter, timezone and comparison window. Search Console counts and analytics sessions measure different things and need not match one for one.
2. Pull the accepted current and comparable prior windows. For name searches use verified name variants and record the exact query filters. [Search Console’s performance guide](https://support.google.com/webmasters/answer/7576553?hl=en) explains available report controls; omitted query rows or unavailable access do not establish zero demand.
3. Reconcile the inquiry log by distinct real contacts or opportunities under the agreed definition. Separate speaking asks, partnership discussions and qualified sales leads. Retain date, source evidence and stage; a reported source such as “heard your interview” is an attribution statement with limits.
4. Compare results with the baseline and target, noting sample size, time lag and tracking changes. Mark unconnected sources unknown. A rise after a podcast or a new panel is correlation unless additional evidence supports the claimed contribution.
5. Explain the strongest supported finding before recommending action. Write two or three grade-five sentences that name the decision and why it matters, paired with a useful chart or evidence diagram. Save the exact opening and quoted reviewer evidence under [Review the report’s reader value](https://local-service-spotlight.github.io/task-library/?task=step-7-write-hook-and-establish-context#task-step-7-write-hook-and-establish-context).
6. Propose a small set of next actions tied to that evidence, with owner and review date. Keep insufficient-data items unresolved; do not automatically kill every activity without a measured inquiry. Reconcile the previous report’s actions as proposed, accepted, in progress or actually completed.
7. Save the report with source links and checked calculations, including any observed panel state and new proof. Deliver only under the existing authority and retain the actual receipt. A monthly cadence is followed only when agreed; it is not created by this guide.

## Definition of done (QA checklist)

Quality assurance (QA) means checking the actual result against its agreed requirements. Follow the [Article Guidelines](https://localservicespotlight.com/article-guidelines/).

- [ ] Each metric has a source, definition, period and honest missing-data state.
- [ ] The report’s conclusions respect attribution and sample limits and lead to an owned next step.
- [ ] Draft, delivered and acted-on states are recorded separately, with exact reader-value review.
- [ ] The exact output, source revision, reviewer evidence and remaining owner action are saved.
- [ ] For any reader-facing output, the short grade-five opening states the reader’s useful outcome and supporting method or proof. The body delivers that promise; a useful authentic visual appears in the first screen. Retain exact text and quoted reviewer evidence.

## Example(s)

**Fictional teaching example. This is not a client result or proof of a completed run.**

A fictional consultant has 400 name-search impressions and three qualified inquiries this month. One person says they heard a podcast; the other two sources are unknown. The report records those facts and proposes checking the contact form. It does not credit all three inquiries to the podcast or call search impressions revenue.

## Handoff and Content Factory context

[Record real customer answers](https://local-service-spotlight.github.io/task-library/?task=record-one-minute-videos-answering-customer-questions#task-record-one-minute-videos-answering-customer-questions) receives supported content needs; the relevant web or relationship function receives the next action. Later results return to the existing [Metrics, Analysis, Action: what happened, why and what to do](https://blitzmetrics.com/maa/) record.

This task supports the [Content Factory: Produce, Process, Post and Promote](https://blitzmetrics.com/content-factory/). Identity, proof, access or coordination can support several stages. Use the real inputs and receiving owner above; this task does not create unrelated transcripts, clips or ads merely because the diagram has four stages.

## Start with an agent

Give the [AI worker](https://blitzmetrics.com/build-agents/) this recipe, the real inputs, desired result and actions already authorized. Ask for the saved output, sources, checks and next owner. A [skill is a written recipe](https://localservicespotlight.com/plugin/); loading one does not prove account access or perform the task. Use the [installation guide](https://localservicespotlight.com/install/) if reusable setup is needed. A ZIP is a source snapshot, not an access grant or automatic update.

Use the app’s actual supported tools and verified file/account access. Keep a missing human verification step with its real owner. Recurring work needs its own configured job, trigger, timezone and observed result; this guide creates no schedule. Before any media playback, mute the player and set its volume to zero. If silence cannot be verified first, use captions, frames, metadata or another silent check.

## Record the real execution

Open the run record when work begins. Keep one execution ID, starting recipe revision, real inputs and current state. Write the [meta article, the record of this execution](https://blitzmetrics.com/meta-article-prompt/) with actual steps, results, checks, failures and next owner. Writing is required; public release follows existing authority. Link it to this recipe and the [Task Library](https://local-service-spotlight.github.io/task-library/).

Reuse the same execution ID for internal checks, revisions, retries and meta writing. A blocked run stays open with its dependency and owner, without an invented finish time. Dated public examples and distinct verified execution counts remain separate. Propose the smallest source-backed recipe improvement when the actual evidence reveals a defect.

## Definitive article & links

- [Maintained source guide](https://blitzmetrics.com/knowledge-panel/)
- [This task in the Task Library](https://local-service-spotlight.github.io/task-library/?task=measure-search-impressions-traffic-inbound-opportunities#task-measure-search-impressions-traffic-inbound-opportunities)
- [Article Guidelines](https://localservicespotlight.com/article-guidelines/)
- [Definitive article and task recipe standard](https://blitzmetrics.com/definitive-article-guide/)
- [How recipes and run records fit together](https://localservicespotlight.com/meta-articles/)

### Primary method references

- [Search Console performance report](https://support.google.com/webmasters/answer/7576553?hl=en)

## Review and evidence still needed

The inherited contributor status is `needs-work`. It is preserved, not promoted by this rewrite. That label alone does not prove document readiness, account access, an actual execution or a client result.

The fictional example teaches the method and does not fill a real-run evidence gap. A named semantic reviewer must check the actual opening, full method, sources and handoff. Check the useful opening visual in the normal rendered guide at the current required desktop and mobile sizes, including 1280 × 800 and 390 × 844. Source readability checks do not prove public presentation or task execution.

END