The panel appears with no notification. Then you have one job that nobody can do for you, and a form with a single question that decides most outcomes. This is that entire process, including the setting that silently blocks it for people on work email accounts.
Opens your assistant with this page's address and a prompt asking what the claim process involves and where it usually goes wrong.
There is no email, no dashboard notification and no status change anywhere. A Knowledge Panel simply begins appearing for some searchers, then for more, then reliably. The first several days are frequently inconsistent, which is normal and is the reason a single check proves very little.
Most people find out by accident. A client mentions it, or somebody sends a screenshot from their phone. That lag matters, because an unclaimed panel is one anybody can suggest edits to and nobody has standing to defend. It is not a crisis, and it is a reason to check rather than wait.
The check itself takes about a minute: a private browsing window, your full name, and a look at whether a card appears beside the results. Do it from a phone as well as a desktop, because the two surfaces roll out changes at slightly different rates and a panel visible on one may not yet be visible on the other.
Check on a fixed schedule rather than hoping to be told. Weekly is plenty during the months when it becomes plausible, and a private window is the only view that means anything.
One thing worth understanding before going further: what appears first is often not the full panel. A name may start returning a small card with nothing but a title, or an image cluster with no description, or a panel that appears on your name plus your city but not on your name alone. These are all the same phenomenon at different strengths, and all of them are claimable. Waiting for it to look complete before claiming is a common and costly mistake, because claiming is precisely what gives you the standing to improve it.
A rejected claim is not fatal, and it is not free either: it costs time, and a second attempt on an unchanged entity almost always produces the same answer. This gate exists so that the first attempt is the only one needed.
The account. It is genuinely common for a website to have been verified under a developer's Google account years ago and forgotten. If that person has left, or the agency relationship ended, this becomes an administrative problem at exactly the moment you least want one. Check it before the panel appears rather than after.
The flow times out and loses answers if you go hunting for things mid-way. Assemble all of it first. It takes about twenty minutes and it is the difference between a clean submission and three abandoned attempts.
| Item | Why it is needed | Watch out for |
|---|---|---|
| One Google account | The account you sign in with becomes the account permanently associated with the claim and with every future edit. | Use a personal address you will keep. Not a work account you would lose on changing jobs, and not a shared team inbox. |
| The panel link and the entity identifier | Documentation, and necessary if you ever need to resubmit or request a merge. | Save both before starting. The identifier sits in the address of the page the panel's own link opens. |
| Your official website address | Google checks it against the property you control in Search Console. | It must match the verified property exactly, including whether it uses www. |
| Four or five profile addresses | Supporting evidence that the accounts describing you are yours. | These should already be linked from your entity home. If they are not, link them first and wait a few days. |
| Government identification | Only if the flow asks for it, which depends on which route Google offers you. | Both face and document clearly visible, all text legible. Blurred or cropped images are a leading rejection cause. A passport has historically cleared most smoothly. |
| Logged-in screenshots | Occasionally requested as proof you control the accounts you listed. | Capture them fresh at the moment of asking. Never store them anywhere afterwards, and never send them to a consultant. |
| Your claim statement | The written answer to the question that decides most outcomes. | Draft it before you begin. Writing it live inside the form is how people end up writing the wrong thing. |
Identity documents, verification selfies, passwords and recovery codes go into Google's flow and nowhere else. Not into an email to a consultant, not into a shared folder, not into an AI chat, not into a project management tool. Any supplier who asks you to send them a photograph of your passport for this has misunderstood the process, and you should treat that as disqualifying rather than as a minor irregularity.
Eleven steps, about fifteen minutes if the packet is ready. The interface changes wording occasionally, so treat the labels as approximate and the sequence as reliable.
Steps three and eight carry almost all the risk. One signed-in account in a private window, and a claim statement drafted before you open the form. Everything else is data entry.
The question reads as though it is asking about your motivation. It is not. It is asking why you are entitled to it, and the difference between those two readings is the difference between approval and a polite refusal.
Almost every rejected claim contains a version of the same answer: some combination of wanting accurate information online, being the person in question, and caring about the brand. All true, all irrelevant. A reviewer cannot verify how much you care. They can verify a conference bio in thirty seconds.
The structure that works is unglamorous and it is three parts. Open with the identity line you have used everywhere else, so the claim matches the entity. Follow with the proof points, each one a thing a reviewer could open in a new tab and confirm. Close with a single sentence about accuracy: that you want anyone searching to find correct information and the official profiles.
No adjectives. No superlatives. No history of your career. Evidence only, and only evidence that already exists inside Google's index, because a reviewer is not going to take your word for something they cannot find.
Claiming proof points that are real but invisible. A talk you gave that was never published online, a client engagement covered by confidentiality, a mention in a print magazine with no digital edition. All genuine, none checkable, and each one weakens the statement by diluting the parts that can be verified. Include only what somebody else can open.
The claim statement stands or falls on whether its proof points are checkable at speed. Below are the same five achievements written twice: once as most people write them, and once as something a reviewer can verify without effort.
The second column is not more impressive. In several cases it is less impressive. It is simply findable, and findable beats impressive every time in a process built around verification.
| The achievement | How it usually gets written | What works instead |
|---|---|---|
| Press coverage | "Featured in leading industry publications." Nothing to open, nothing to confirm, and it reads as though the specifics are being avoided. | The publication named, the article title, and the approximate date. A reviewer types the title and finds it. That is the entire bar. |
| Speaking | "Regular keynote speaker at international conferences." Plural, vague and unverifiable, which makes even the true part look inflated. | One named conference, one year, and the fact that the event's own site carries a speaker page. Singular and checkable beats plural and hollow. |
| A book | "Bestselling author." A claim about sales rankings that a reviewer cannot check and that means very different things in different contexts. | The title and the identifier. A book with an ISBN resolves instantly in catalogues worldwide, which makes it the strongest single line available to most people. |
| The company | "Founder of a fast-growing agency." Adjectives doing work that facts should be doing, and no way to tie the person to the organisation. | The company name, your exact role, and the fact that the company's own site names you. The tie between person and organisation is what is being verified. |
| Teaching or advisory | "Advises universities and startups." Broad, unnamed, and impossible to distinguish from an aspiration. | One named institution with a page that lists you. A single faculty or advisory listing carries more weight than a paragraph of unnamed relationships. |
Three checkable proof points beat ten unverifiable ones, and mixing the two actively harms you, because the unverifiable lines invite scepticism about the verifiable ones sitting beside them.
Two opposite mistakes are common here and they pull in different directions, which is why the advice sounds contradictory until you separate them.
The first is waiting for the panel to look finished. People see a card with no description, no photograph and no facts, decide it is not ready, and leave it unclaimed for months. That is backwards. A thin panel is exactly the one that most needs an owner, because claiming is what earns the standing to improve it, and an unclaimed panel is one that strangers can suggest edits to while you have no formal position at all.
The second is claiming a panel that is genuinely about somebody else, or about two people blended together. Claiming a confused entity does not clarify it. It attaches your verified identity to the confusion, and unpicking that afterwards is considerably harder than strengthening the entity for another two months and claiming a clean one.
Where it is genuinely borderline, the tie-breaker is simple: would a stranger looking at this card conclude it is one person, and would that person be you? If yes, claim it and improve from a position of standing. If no, the work to do is corroboration, not paperwork.
These are the failures that make people conclude they were rejected when in fact they never reached a reviewer. All four are fixable in under an hour.
The claim runs on Google's brand accounts system underneath. On a managed work domain, an administrator can disable the additional Google services that system depends on, usually years earlier and for unrelated security reasons. The result is a flow that offers you no verification options at all and gives no useful explanation.
It reads exactly like rejection and it is not rejection. Nobody has assessed you. The fastest fix is a private window and a single personal Google address, which lowers no bar because verification still depends on properties you genuinely control. The alternative is asking your administrator to enable the relevant additional services for your organisational unit, then signing out and back in.
If you have already burned an attempt this way, it does not count against you. There was no submission to count.
The single worst response to a rejection is to resubmit the same thing immediately. The second worst is to conclude the whole exercise was a fraud. The useful response is diagnostic, and it starts with a record you should have kept before submitting.
Resubmit once, deliberately, having changed something specific. If the second attempt also fails on an unchanged entity, the answer is not in the form.
Approval is not the finish line. A panel passes through recognisable stages, and knowing which one you are in prevents both premature celebration and unnecessary panic.
Four questions, and two or more failures means you are at level two however good it looks. Does the panel appear on your name alone, not just your name plus a qualifier? Do verified edits go live in days rather than weeks? Have off-brand images stopped reappearing? Do you consistently outrank people who share your name?
Level two is a perfectly acceptable place to be, and it is worth knowing you are there, because the remedy is more corroboration rather than more edit requests. People at level two who keep submitting edits get frustrated. People at level two who add two more independent sources get to level three.
Once claimed, you can suggest edits. Whether they land depends almost entirely on one habit, and it is the opposite of what most people do.
Fix the source first, then submit the edit. An edit request that contradicts what your own website says will be ignored, and rightly so, because the request is one voice against every other surface. Update the entity home, then the profiles, then wait a few days, then submit. The request then reads as a correction to a stale cache rather than as a claim in dispute with the evidence.
| Symptom | What is actually wrong | The fix |
|---|---|---|
| Wrong photograph | Google is pulling from a source it trusts more than the one you prefer, usually because the preferred image appears in fewer places. | Put the correct headshot on the site and every major profile, then request the change. Consistency beats a single request. |
| Wrong or outdated job title | The old title still appears on more surfaces than the new one. | Update every profile and any third-party bio you can reach, then submit. Expect it to take longer than you think reasonable. |
| Missing social profiles | Google mirrors only what it can verify from several trusted surfaces. | List them publicly on the entity home and ensure each links back. Then request. |
| A namesake's information bleeding in | Two entities Google has not fully separated. | Strengthen the distinguishing context: city, field, organisation, beside your name everywhere. This is corroboration work, not an edit. |
| Edits consistently ignored | Not a form problem. The corroboration underneath is too thin to support the assertion. | Add independent sources. Then the same edit, unchanged, will often go through. |
Keep a log. What was edited, when, which proof addresses were cited, and a screenshot before and after. It feels bureaucratic until the first time something silently reverts, at which point it is the only way to tell whether you are dealing with a rollback, a competing source, or your own memory.
Duplicate panels happen, usually to people who changed name, role or country at some point, or who have been written about under two spellings. The symptoms are distinctive: confidence drops, edits stop sticking, and the panel wobbles between two versions of the truth.
There is an official merge route and it works considerably better than the general feedback link, which is where most people waste their first attempt.
Before requesting anything, make sure your entity home, your structured data and your profiles all point at one canonical identity. If the underlying evidence still describes two people, merging the panels treats the symptom and the split will reassert itself. The merge request is the last step of the fix, not the first.
Everything above describes what happens when a panel already exists. It is deliberately complete, because a client walking into an identity verification flow half-informed is a client who wastes an attempt, and there is no commercial advantage in that for anybody.
What this guide does not contain is how to get to the point where a panel exists at all. Which sources are worth pursuing in a given field, in what order, how a pitch is framed so it lands, and the structural work that makes a machine resolve one person out of several fragments. That is the part being paid for, and publishing it would convert paying clients into unpaid authors of their competitors' manual.
The line we draw is this: anything you need in order to not be taken advantage of is published. Anything that is purely operational advantage is not. If a supplier reverses that, and hides the process while giving away the method, ask what they are actually selling.
Everything here assumes a panel eventually appears. Whether one will, for you, is a separate and more important question, and it is answerable before you spend anything.
Start with the free diagnosis →