Your knowledge panel description almost always comes from a third party, most often the opening lines of a Wikipedia article, quoted by Google with a small “Wikipedia” link underneath. Google does not write it, you cannot edit it directly, and the only durable way to change it is to fix the source it was copied from.
That second sentence frustrates every founder who has claimed a panel: you see the “Suggest edits” button, yet the paragraph people read first is locked. This guide explains where that paragraph originates, why it drifts out of date or vanishes, what Google’s own help documentation says you can and cannot change, and how the same source material ends up inside AI answers.
Where does the knowledge panel description come from?
Google’s help page “About knowledge panels” says panel information “comes from various sources across the web,” with some data supplied by partners holding authoritative data. Its companion page on how the Knowledge Graph works adds that facts come from “a variety of sources that compile factual information,” including licensed data and information received directly from content owners.
For the description snippet specifically, the dominant source is Wikipedia. When an entity has a Wikipedia article, Google typically lifts the first sentence or two of the lead section and credits it with a link.
When no Wikipedia article exists, Google looks elsewhere. You will see descriptions attributed to other reference sites, official websites, or databases Google trusts for a particular category, such as music, film, or sports. Some panels skip a long description entirely and rely on a short subtitle under the name (“American entrepreneur,” “Software company”). Google’s help documentation says that when it removes a problematic subtitle, its system picks a replacement automatically, which tells you subtitles are machine-selected rather than hand-written.
Then there is Wikidata, the structured sister project of Wikipedia. Every Wikidata item carries a label and a one-line description, and those short descriptions feed many systems that need a compact identity line. Wikipedia itself relied on Wikidata descriptions for years: its mobile interface displayed them beneath article titles until editors raised concerns about accuracy and vandalism. English Wikipedia now stores its own short descriptions locally through the {{short description}} template, with a suggested target of about 40 characters. Both layers matter, because both are public, structured, and easy for machines to read.
So the honest answer has three tiers. The long panel snippet is usually a Wikipedia excerpt. The short subtitle is algorithmically chosen and often mirrors a Wikidata or Wikipedia short description. And when neither source exists, Google falls back to whatever trusted reference it can attribute, or shows nothing.
Why the description goes wrong, stale, or missing
A Wikipedia-sourced description inherits every weakness of the article underneath it. If the lead was written five years ago, your panel describes the company you were five years ago. If an editor trimmed your founding story to one clumsy clause, that clause is now your public introduction. If someone vandalizes the lead, Google can quote the vandalism.
That last scenario is not hypothetical. In late May 2018, Google’s knowledge panel for the California Republican Party listed “Nazism” among the party’s ideologies. Vice News first reported it, House Majority Leader Kevin McCarthy criticized Google publicly, and a Google spokeswoman explained that “people vandalize public information sources, like Wikipedia, which can impact the information that appears in search,” according to The Daily Signal’s June 1, 2018 coverage. Google removed it after processing the Wikipedia fix. The lesson for everyone else: the panel faithfully mirrors its source, including the source’s worst moment.
Staleness is the more common problem. Companies rebrand, founders change roles, products get discontinued, and nobody updates the encyclopedia.
Missing descriptions have a different cause. Google creates panels automatically “when there is enough information,” in the words of its Knowledge Graph help page, but a panel can exist without a quotable description. If your only coverage is your own website, a few directory listings, and social profiles, Google has an entity to show but no independent source it is willing to quote. The result is a panel with your name, photo, and links, and an empty space where the narrative should be.
Ambiguity causes the strangest failures. When two people share a name, or a brand name collides with a common word, Google can attach the wrong description to the right panel. These merges usually trace back to a Wikidata item or Wikipedia article that conflates the two entities, which brings us back to the source.
Trace it with the TRACE method
Most people try to fix a knowledge panel description by complaining to Google first. That is backward. Google has told you, in writing, that it will not write a custom description, so every fix runs through the source. We call the diagnostic sequence the TRACE method: Text-match, Read the attribution, Audit the structured layer, Correct at the source, Escalate with evidence. Run the five steps in order and you will know exactly where the problem lives before you touch anything.
Text-match. Copy the exact wording of your panel snippet and search for it in quotation marks. A verbatim match on Wikipedia, a reference site, or an old press bio tells you the origin within seconds. If the wording matches nothing, the description is probably a light paraphrase or a machine-selected subtitle, and you shift your attention to the structured layer in step three.
Read the attribution. Look directly below the description in the panel. Google usually links the source by name. Note it, open it, and confirm that the cited page still contains the quoted text. If the page changed and the panel has not, you are waiting on a recrawl.
Audit the structured layer. Search Wikidata for your entity and open its item. Check the label, the description, the “instance of” statement, official website, and any identifiers. Then check the Wikipedia article’s short description in the page source. A wrong subtitle, a confused entity type, or two people merged into one item will show up here faster than anywhere else.
Correct at the source. Fix the underlying record through the proper channel for that source, which the section on Wikipedia and Wikidata below covers in detail. For a reference site or directory, contact its editors with documentation. For your own site, update the About page and your Organization or Person schema markup so they match the facts you want repeated.
Escalate with evidence. Only after the source is fixed, or after the source has refused a valid correction, go to Google. A verified entity uses the Suggest edits flow; everyone else uses the Feedback link. Attach public URLs that prove the point.
The TRACE method works because it matches how Google says it evaluates feedback: by “comparing it with other public web information.” If the public web still contradicts you, Google will side with the public web.
What Google will and won’t change for verified entities
Google’s help article “Submit feedback on content about you” lays out the verified flow precisely. Sign in to the Google Account you used to verify, with Web and App Activity turned on. Search for your name or entity. Click “Suggest edits” at the top of the panel. Click the edit icon beside the specific item you want changed, submitting each item separately. Describe what is wrong, what to remove, and the public URLs that support you, then click Send. Google says it reviews feedback within a few days and emails you the resolution.
On descriptions, the same page is blunt. Descriptions “come from various data sources and can’t be edited directly.” To change one, Google tells you to contact the source and request a correction, noting that changing the source usually changes the panel too. If the source will not correct it, you can submit feedback explaining that you contacted them, with strong evidence. Google may then remove the description. It will not write a replacement, and the page warns that the panel often has no description afterward.
Removal is a last resort that trades a bad description for a blank space. For a public figure or a company that depends on credibility at first glance, a blank space is rarely an upgrade unless the existing text is false or damaging.
The verified flow is more useful for the surrounding elements. Google lets verified representatives correct social profile links directly, suggest a replacement featured image when one already exists, and ask to remove personal details such as date of birth, relationships, children, and marital status. Title changes get considered only with “substantial evidence” that the automated choice was not the most representative. Google states that it does not manually create or delete knowledge panels, cannot add an image if the panel has none, and does not take suggestions for “People also search for.”
Unverified users can still act. The Knowledge Graph help page says anyone can send feedback about panel issues using the Feedback link at the bottom of the panel. That route works best for clear factual errors on well-documented entities.
Fix the source: Wikipedia, Wikidata, and your own site
Wikipedia is where most description problems get solved, and also where most get made worse. The site’s conflict of interest guideline says editing with a COI is “strongly discouraged,” and paid advocates are “very strongly discouraged from direct article editing.” If you work for the company, are the person in question, or are paid to represent them, you should not rewrite the lead yourself.
The guideline gives you a legitimate path instead. Propose the change on the article’s talk page using the {{request edit}} template, disclose your connection, and cite reliable, independent sources for every claim. Volunteer editors review requests with the same scrutiny as any other change and may decline them. Paid editors face an additional rule: the Wikimedia Foundation’s Terms of Use require you to disclose your employer, client, and affiliation for any contribution you are compensated for, on your user page, the talk page, or in the edit summary. The guideline does allow a narrow set of direct fixes from COI editors, such as reverting obvious vandalism or correcting spelling, but anything an editor objects to belongs back on the talk page.
What gets an edit request accepted is sourcing. “Our CEO changed in March” persuades nobody; a link to a Reuters or trade publication story announcing the change does. This is where earned media stops being a vanity metric. Independent coverage in recognized outlets is the raw material Wikipedia editors need before they will update an article, and the raw material Google needs before it trusts a fact.
Wikidata works differently. It is more permissive about who edits, and its descriptions are short, lowercase identity phrases rather than prose. Log in, open your item, and correct the description, statements, and identifiers, adding references to published sources wherever a statement allows. Keep the description neutral and factual; promotional phrasing gets reverted. If two entities are merged, raise it on the item’s discussion page rather than splitting it yourself without explanation.
Your own website is the third leg. Google’s help docs note that it receives factual information “directly from content owners in various ways,” and your official site is the obvious channel. Keep your About page’s first paragraph aligned with the description you want, mark it up with Organization or Person schema, and list your verified social profiles and Wikidata item in the sameAs property. It reinforces one consistent story across every source a machine reads.
Why AI answers repeat the same description
The knowledge panel description is not only a Google problem anymore. When someone asks ChatGPT, Gemini, Claude, or Perplexity “who is” a person or “what is” a company, the answer frequently sounds like the panel, sometimes word for word.
Large language models learn from the same public entity sources. OpenAI’s 2020 GPT-3 paper, “Language Models are Few-Shot Learners,” listed English Wikipedia as one of the five datasets in its training mix. Wikidata is openly licensed and structured for machine use, which makes it a natural reference for any system that needs to know what an entity is. Answer engines that search the live web before responding tend to retrieve Wikipedia and official sites near the top for entity queries. Google, for its part, became the first customer of Wikimedia Enterprise, the Wikimedia Foundation’s commercial API service, announced in June 2022.
The practical consequence is that a stale Wikipedia lead now does double damage. It sets your knowledge panel description and it seeds the paragraph an AI assistant reads aloud to a prospect, an investor, or a journalist. Fixing the source fixes both, though on different clocks: Google can reflect a change within days or weeks, while a model trained on older data may keep repeating the old wording until it is retrained or pulls fresh pages at answer time.
This is why we treat entity work and AI-search visibility as one discipline at Instant Press rather than two services. The inputs are identical: accurate encyclopedic records, clean structured data, a consistent official site, and enough independent press coverage that every source agrees on who you are. Run the TRACE method on your own panel this week, note which source is driving the description, and check whether the major AI assistants describe you the same way. If they diverge, the divergence points to the source that still needs work.
Entity descriptions will keep migrating from search panels into AI answers, and the brands that own accurate sources now will be the ones those systems describe correctly tomorrow.