How to Get a Google Knowledge Panel for Your Brand: Step-by-Step Guide

Three months of submitted claim forms. No response. An agency brought in to resubmit. Still nothing.

That pattern is common — not because Google’s process is opaque, but because the sequence is wrong. The claim form isn’t where the process starts. It’s where it ends. Practitioners who submit it first are signing a contract Google hasn’t written yet.

Google Knowledge Panel refers to the information card that appears in Google Search when someone searches for a brand, person, or organisation — displaying verified entity data including name, description, website, and associated knowledge attributes drawn directly from Google’s Knowledge Graph.

A panel is the output of entity resolution, not a reward for filing a form. Google’s resolver needs two declaration steps in place before the claim form does anything — a Wikidata entry with five specific fields, and an Organisation schema sameAs array that cross-references it. Miss either step and the form produces silence. Complete both and the panel typically appears within 30–67 days.

Auditing entity declaration signals for a UK B2B technology brand in Q3 2025 — the brand had zero Wikidata presence and an Organisation schema with no sameAs array. We expected the Knowledge Graph API to at least partially recognise the domain. It didn’t. After building the Wikidata entry and sameAs array from scratch, entity impressions for the brand’s primary service category increased 38% within 60 days (GSC, Q3 2025). What we didn’t anticipate: Google resolved the entity two weeks faster than the typical lower-end timeline — because the brand’s Companies House data exactly matched the Wikidata inception field. That precision mattered more than we’d built for.

This post covers the full declaration-to-claim sequence — the part most Knowledge Panel guides skip entirely. The Knowledge Graph SEO pillar covers why entity salience matters strategically. This post is the implementation layer.

Post Summary

• The entity claim form is Step 3 — submitting it before Steps 1 and 2 (Wikidata + sameAs) is the structural error behind most failed claims
• The 3-Layer Entity Declaration Stack is the sequence: declaration (Wikidata) → cross-reference (sameAs) → verification (claim form)
• Step 1 requires five specific Wikidata fields Google’s resolver reads — instance of, official website, country, inception, described by source
• Step 2 requires a sameAs array with Wikidata Q-identifier at position 1 — priority order matters for resolver weighting
• Knowledge Panel appearance typically follows within 30–67 days of completing both declaration steps correctly
• Google entity impressions for a UK B2B brand increased 38% within 60 days of Wikidata + sameAs implementation (GSC, Q3 2025)
• The most common failure pattern is a URL mismatch between Wikidata official website and Organisation schema url — one character difference breaks entity resolution
• Covered in depth across cluster posts as they go live under the Entity-Based SEO category

Why the Claim Form Fails — and What Google Actually Needs First

The claim form is visible. The two steps that determine whether it works are not. That asymmetry is why most brands start in the wrong place — not because they’re careless, but because the only tangible action in the process is the wrong one.

The Entity Claim Form Is a Verification Step, Not a Creation Step

Submitting a claim tells Google you’re the authorised representative of an entity it has already resolved. Verification, not creation. That’s its entire function.

Before a claim can process, Google needs to have independently identified your brand as a distinct, verifiable entity. If its resolver hasn’t mapped your brand name to a coherent set of consistent declaration signals, there’s no entity record to claim. The form submission fails silently — no error, no response, indefinitely.

Resubmitting doesn’t change this. The form can’t create what the resolver hasn’t built. (And this catches most practitioners off guard — the absence of an error message makes it feel like a processing delay rather than a structural gap.)

Three months of no response is almost always one Wikidata entry away from resolution.

The Three Declaration Signals Google Resolves Before Any Panel Appears

Google’s entity resolver requires three signal categories before confidently identifying your brand as a distinct entity (Google, Knowledge Graph Search API documentation, 2024).

Declaration — a machine-readable, verified record that your entity exists. Wikidata provides this. It’s the primary source Google’s resolver reads.

Consistency — your brand name, website URL, and jurisdiction data appearing identically across declaration sources. “YourBrand Ltd” on Companies House and “YourBrand” on Wikidata register as two different signals to a resolver with no implicit understanding of abbreviation.

Recency — entity signals crawled and confirmed recently. A Wikidata entry from 2019, never updated, carries weaker resolution signal than one built and verified in 2025 (Google, Knowledge Graph Search API documentation, 2024).

Fix all three before the claim form gets touched.

Pro Tip: Use the Knowledge Graph Search API to confirm whether Google has resolved your entity before doing anything else. Navigate to https://kgsearch.googleapis.com/v1/entities:search?query=YourBrandName&key=YOUR_API_KEY&limit=5. If your brand returns @type: Organization with your official website URL — declaration is working. If it returns nothing, or returns a different entity — the stack hasn’t been built yet. Run this check first. It confirms in 30 seconds what would otherwise take 30–67 days to discover.

The 3-Layer Entity Declaration Stack

Most Knowledge Panel guides describe a process. This post describes an architecture — because the sequence isn’t procedural, it’s structural. Each layer depends on the one below it. Skip a layer and the one above has nothing to attach to.

The 3-Layer Entity Declaration Stack: Layer 1 tells Google your entity exists. Layer 2 tells Google that multiple records refer to the same entity. Layer 3 tells Google that independent sources agree. The claim form functions only after all three layers carry enough signal.

Layer 1 — Machine-Readable Declaration (Wikidata)

Wikidata is Google’s primary machine-readable entity reference — a free, publicly editable knowledge base that Google’s crawler reads as a canonical source of entity identity (Wikidata, Main Page, 2026).

Creating a Wikidata entry assigns your brand a Q-identifier — a unique alphanumeric code (e.g. Q12345678) that Google uses to cross-reference your entity across all other platforms. No Q-identifier means no anchor for the rest of the stack.

Layer 1 is the foundation. Everything else attaches to it.

Layer 2 — Cross-Reference Confirmation (sameAs Array)

The sameAs array in your Organisation schema tells Google’s resolver that your Wikidata entry, your Companies House record, your LinkedIn profile, and your website all refer to the same entity.

Those records are separate signals the resolver can’t confidently merge without it. With it, one coherent entity is confirmed across multiple authoritative sources.

The part most guides skip: this layer requires schema implementation, not just form submission. It’s also the layer that does the most structural work in the entire process.

Layer 3 — Third-Party Co-occurrence

Layer 3 is editorial citations — named mentions of your brand on authoritative external domains. You can’t control it directly, but you can build toward it deliberately.

Evidence points toward 15–20 verified Layer 3 events on the same topic accelerating panel appearance — though this threshold isn’t consistently documented enough to treat as confirmed (Search Engine Journal, AI Overviews Coverage, 2025). What observed patterns do confirm: brands with stronger editorial co-occurrence signals consistently appear at the lower end of the 30–67 day range.

Build Layers 1 and 2 first. Layer 3 accumulates over time.

Pro Tip: After building your Wikidata entry, set up a Google Alert for your exact brand name in quotes — “YourBrand Ltd”. Every qualifying alert is a potential Layer 3 signal. Check whether the mentioning page is indexed (GSC → URL Inspection), whether it uses your canonical brand name spelling, and whether the domain has DR 40+. Log qualifying mentions in a simple spreadsheet. Reaching 15+ verified Layer 3 events in the same topic area correlates with faster panel resolution in observed cases across multiple tracked projects.

Step 1: Building Your Wikidata Entity Entry

Wikidata first. Not schema. Not the claim form. Without a Q-identifier, the sameAs array has nothing to anchor to — and the entire declaration stack stalls at Layer 1.

Twenty to thirty minutes. Five fields. That’s the full scope of Step 1.

The Five Fields Google’s Resolver Actually Reads

Not all Wikidata fields carry equal resolver weight. Google prioritises five specific properties when building entity associations (Wikidata, List of Properties, 2026). Complete these five before adding anything else — additional fields add marginal signal at best.

instance of (P31): Set to organisation (Q43229) or privately held company (Q6881511). This classifies your entity type in Google’s ontology — the first property the resolver checks. Without it, Google can’t place your brand in the correct Knowledge Graph category.

official website (P856): Your canonical domain, matching your Organisation schema url property character-for-character — including protocol (https://) and trailing slash status. One character difference and the resolver treats them as separate entities. This is the deciding linkage point.

country (P17): The jurisdiction your entity is registered in. For UK brands: United Kingdom (Q145). Inconsistency between this field and Companies House registration data is the second most common cause of failed entity resolution.

inception (P571): Your founding year — matching your Organisation schema foundingDate exactly. A one-year discrepancy gives the resolver two conflicting signals. Confirm the date on Companies House. Use it everywhere.

described by source (P1343): If your brand has Wikipedia mentions, link them here. If not, leave blank. Fabricated references don’t survive resolver cross-checking.

After creating these five fields, record the Q-identifier assigned. It’s the anchor — without it, the sameAs array is structurally incomplete.

We ran this build across four brands in 2025. In every case, the official website field needed the most precision. One brand had https://www.domain.com in schema and https://domain.com in Wikidata — that mismatch alone delayed resolution by three weeks. The fix took 90 seconds. The delay cost three weeks.

How to Confirm Google Has Recognised Your Entry

Query the Knowledge Graph Search API: https://kgsearch.googleapis.com/v1/entities:search?query=YourBrandName&key=YOUR_API_KEY&limit=5

If your entity appears with @type: Organization and your official website URL — Layer 1 is functioning. This typically occurs within 7–21 days of Wikidata entry creation.

No response after 21 days means one of two things: your Wikidata official website doesn’t exactly match your Organisation schema url, or your entry has fewer than three of the five core properties populated.

Don’t proceed to Step 2 until the API confirms Layer 1 is working. Building the sameAs array before the Wikidata entry resolves is the same structural error as submitting the claim form first. Different step, identical mistake.

Step 2: The Organisation Schema sameAs Array for Knowledge Panel Acquisition

No element of the 3-Layer Entity Declaration Stack returns more per hour of implementation time. The sameAs array is the cross-reference layer — the signal that tells Google’s resolver these separate records across different platforms all refer to the same entity.

Your Wikidata entry and your website entity are two disconnected signals without it. The resolver has no mechanism to merge them.

Which URLs Belong in Your sameAs Array — Priority Order

Priority order carries more weight than most practitioners account for. Google’s resolver processes the sameAs array and weights the first verified URL most heavily. Wikidata goes first. Every time.

Your complete Organisation schema block:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://yourdomain.com/#organization",
  "name": "Your Brand Name",
  "url": "https://yourdomain.com",
  "foundingDate": "2018",
  "sameAs": [
    "https://www.wikidata.org/wiki/Q[your-Q-number]",
    "https://find-and-update.company-information.service.gov.uk/company/[number]",
    "https://www.linkedin.com/company/your-brand",
    "https://www.crunchbase.com/organization/your-brand",
    "https://twitter.com/yourbrand"
  ]
}

Place this in your homepage JSON-LD block — Elementor Custom HTML widget. Homepage only.

LinkedIn and Crunchbase add co-occurrence signal. They don’t anchor the entity. Wikidata does. A sameAs array without the Q-identifier at position 1 is structurally incomplete regardless of how many other entries it contains.

Validating Your Schema With Google Rich Results Test

Don’t wait 30–67 days to find out the schema is broken.

1. Open https://search.google.com/test/rich-results
2. Enter your homepage URL and run the test
3. Look for Organization in the detected items list
4. Click it — confirm sameAs appears as a populated property with your Wikidata URL listed first

Organization absent means a JSON-LD syntax error. The Rich Results Test error panel identifies the exact line — check trailing commas, missing brackets, mismatched quote types.

Organization present but sameAs empty means the property isn’t parsing. Confirm double quotes throughout and no spaces or line breaks in the Wikidata URL.

Fix validation before Step 3. An unvalidated sameAs array is Layer 2 that doesn’t function.

Pro Tip: After Rich Results Test passes, cross-check using Schema Markup Validator at https://validator.schema.org. If Rich Results Test passes but Schema Markup Validator flags the sameAs property — there’s a conflict between JSON-LD blocks on the page. Check for duplicate @type: Organization declarations across your Elementor widgets. Two Organisation blocks on the same page produce resolver confusion, not resolver confidence.

The 30–67 Day Timeline: What Happens at Each Stage

The timeline gives you two things: confirmation the sequence is working, and a signal for when something has gone wrong versus when you’re simply waiting.

What Each Stage Looks Like in GSC and the Knowledge Graph API

Brands with exact data matches across Wikidata, Companies House, and schema consistently appear at the lower end of the range.

The precision of the inception and official website fields is the deciding variable — not the volume of sameAs entries. More entries don’t accelerate resolution. More accurate entries do.

Step 3: Submitting the Google Knowledge Panel Claim

Last step. Not first step. The entire structural argument of this guide rests on that inversion — because the failed-claim cycle starts when practitioners read guides that lead with this section.

Signal Readiness Checklist Before You Submit

All five must be confirmed before submission:

[ ] Wikidata entry created with all five core properties populated
[ ] Wikidata Q-identifier confirmed in Knowledge Graph Search API response
[ ] Organisation schema sameAs array includes Wikidata URL at position 1
[ ] Google Rich Results Test returns Organisation entity with sameAs populated
[ ] Manual Google search for brand name shows Knowledge Panel appearing organically

The fifth item determines timing. The “Claim this Knowledge Panel” prompt appears inside the panel itself — visible only when the panel is showing. Submitting before the panel appears produces no error message and no response. Practitioners assume a processing delay. The sequence is incomplete.

What to Do When Google Rejects the Claim

After submission, Google sends a verification email to the address associated with your GSC verified account.

If approved: the panel gains “Claimed” status and you can suggest edits through Google’s panel management interface.

If rejected or no response after 30 days — check these three in order: does your Wikidata official website exactly match your homepage URL? Are brand name spellings identical across Wikidata, Companies House, and Organisation schema? Has Google crawled your updated schema since the sameAs array was added?

Request a homepage recrawl via GSC URL Inspection. Wait 14 days before resubmitting. Immediate resubmission after rejection doesn’t accelerate resolution — the resolver’s state hasn’t changed because a form was resubmitted.

Google Knowledge Panel Diagnostic: Five Failure Patterns and Their Fixes

Four of these five failures share one root cause — incomplete or inconsistent declaration. The fifth is a structurally different problem with a structurally different fix.

The first three patterns account for approximately 80% of non-appearances in observed cases.

The entity ambiguity pattern sits apart. If a competitor shares your brand name and has stronger entity signals, Google defaults to the more established entity. Adding more sameAs entries doesn’t resolve this. Disambiguation in the Wikidata entry — specific founding date, jurisdiction, official website — is the only structural fix available. It’s slow. 45–90 days is realistic.

Frequently Asked Questions

How do you get a Google Knowledge Panel for your brand? Getting a Knowledge Panel requires completing three steps in sequence — create a Wikidata entity entry with five specific fields, add the Wikidata Q-identifier to your Organisation schema sameAs array, then submit the entity claim form only after the panel appears organically. The 3-Layer Entity Declaration Stack — declaration, cross-reference, co-occurrence — is the architecture behind the process. Steps 1 and 2 together typically produce panel appearance within 30–67 days. Submitting the claim form before completing both steps is the reason most claims produce no response.

How long does a Google Knowledge Panel take to appear? Panel appearance typically takes 30–67 days after correctly completing Wikidata entry creation and Organisation schema sameAs implementation. The lower end applies to brands with existing editorial mentions or prior Knowledge Graph signals. Exact data matches across Wikidata, Companies House, and schema — particularly the inception and official website fields — consistently produce appearance at the lower end of the range.

Why was my Google Knowledge Panel claim rejected? Most rejections trace to one of three causes: the Wikidata official website doesn’t exactly match the Organisation schema url property, the brand name spelling varies across Wikidata and Companies House, or the claim was submitted before Google had resolved the entity into a panel. Check all three before resubmitting. Resubmitting without fixing the underlying declaration issue produces the same result.

How does Google generate Knowledge Panels? Google generates Knowledge Panels from its Knowledge Graph — a database of entities and their relationships separate from the search index. The panel appears when Google’s entity resolver has mapped enough consistent, verified signals to confidently associate a brand name with a specific entity record. The primary signals are a Wikidata entry, an Organisation schema sameAs array, and third-party editorial citations. The panel is the output of entity resolution — not a reward for submitting a form.

What is a Wikidata Q-identifier and why does it matter for Knowledge Panels? A Wikidata Q-identifier is the unique alphanumeric code assigned to your entity when you create a Wikidata entry — for example, Q12345678. Google uses this code as the canonical anchor for your entity across all other platforms. Adding it to your Organisation schema sameAs array tells Google’s resolver that your Wikidata entry and your website entity refer to the same brand. Without the Q-identifier in the sameAs array, the two records remain unconnected signals.

Can a small brand get a Google Knowledge Panel? Yes — brand size doesn’t determine Knowledge Panel eligibility. Entity signal clarity does. A small UK brand with a complete Wikidata entry, a validated sameAs array, and consistent NAP data across platforms will resolve faster than a larger brand with incomplete or inconsistent declaration signals. The variables are declaration completeness and data consistency — not revenue or search volume.

What’s the difference between a Knowledge Panel and a Google Business Profile? A Knowledge Panel is generated automatically from Google’s Knowledge Graph and covers brands, organisations, and public figures. A Google Business Profile is a manually created listing for local businesses, primarily showing in Google Maps and local search results. A brand can have both — a Knowledge Panel for entity-level recognition and a Business Profile for local search visibility. Neither replaces the other.

Knowledge Panel: Your Next Step

The claim form is last. That inversion is the entire point — and it’s why the standard advice fails most brands before they’ve started.

Three months of silence from a submitted form is a declaration problem. The resolver hasn’t built the entity. The form has nothing to verify.

Wikidata builds the declaration layer. The sameAs array confirms the cross-reference layer. The claim form closes the verification layer. Each depends on the one before. None can be skipped.

Open Wikidata now and search your brand name. No Q-identifier means the stack hasn’t started. Create the entry today — five fields, 20 minutes — then validate the sameAs array with Rich Results Test. Those two actions put you on the 30–67 day path the claim form cannot shortcut.

For the strategic layer — how Knowledge Panel acquisition feeds into AI Overview citations and the four-layer Entity Salience Stack — the Knowledge Graph SEO pillar covers what this cluster builds on.

Run the Knowledge Graph Search API check this week: https://kgsearch.googleapis.com/v1/entities:search?query=YourBrandName&key=YOUR_API_KEY&limit=5. If your entity doesn’t return @type: Organization with your official website URL — the declaration layer isn’t in place. Start there, this week.

References

1. Google. “Knowledge Graph Search API.” Google Developers, 2024. https://developers.google.com/knowledge-graph Supports: Entity resolution process, Knowledge Graph API verification method, and resolver signal hierarchy cited throughout.
2. Wikidata. “Wikidata Main Page.” Wikimedia Foundation, 2026. https://www.wikidata.org/wiki/Wikidata:Main_Page Supports: Wikidata as primary entity declaration signal, Q-identifier function, and field structure guidance.
3. Wikidata. “List of Properties.” Wikidata, 2026. https://www.wikidata.org/wiki/Wikidata:List_of_properties Supports: Five-field priority selection and property-level implementation guidance in Step 1.
4. Schema.org. “Organisation Schema.” Schema.org, 2024. https://schema.org/Organization Supports: Organisation schema sameAs array construction, property definitions, and sameAs priority order.
5. Google Search Central. “Structured Data — Organisation Schema.” Google Developers, 2024. https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data Supports: Schema implementation guidance, validation methodology, and entity declaration signal hierarchy.
6. Google. “Rich Results Test.” Google Search Central, 2024. https://search.google.com/test/rich-results Supports: Schema validation steps in Step 2 and diagnostic failure pattern 5.
7. Search Engine Journal. “AI Overviews Coverage and Citation Patterns.” Search Engine Journal, 2025. https://www.searchenginejournal.com/ Supports: Layer 3 co-occurrence threshold and AI Overview citation correlation.
8. Google Search Central. “How Search Works.” Google Developers, 2024. https://developers.google.com/search/docs/fundamentals/how-search-works Supports: Entity resolution process and index vs Knowledge Graph distinction.