---
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.


<!-- factory-layer:start -->

## Factory chain (do not treat this as isolated)

- **Phase:** —
- **Importance:** 3/5 `●●●○○` — frequency 3, revenue 3, gating 3 (supporting)
- **Suggested previous station:** —
- **Suggested next station:** —
These stations are generated neighbors, not verified prerequisites or handoffs. Follow the task’s actual Inputs and Handoff sections.
- **Handoff:** Save this task’s actual output, source, date and checks where the receiving owner can read them. Follow the Inputs and Handoff sections for its next step.

## Model routing (same factory, any engine)

- **This task's lane:** `judgment` — Frontier judgment: honest scoring, entity disambiguation, the subject's voice. Claude, ChatGPT, or Grok — pick the one you have.
- **Single-engine path:** Use the capable AI app you already have. Check its required tools and access before starting. Pass the actual result and proof to the next task.
- **Optional multi-engine:** A tested local model may draft; a stronger model may review facts and voice. Use supported tools for approved actions. Pick models from observed quality and cost; a model name does not prove it can run this task.
- **Never** store the working state in one vendor's memory. Files in the Content Library are the bridge.

<!-- factory-layer:end -->
## 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.