You cannot apply for a knowledge panel, and you cannot buy one. Google’s own help documentation says panels are created automatically by its search systems once enough information about an entity exists across the web. What you can do is make your software company easy for Google to recognize as one specific, well-described thing. For a SaaS business, that comes down to a single decision most teams skip: treat the company and the product as two separate entities, describe each one the same way everywhere, and connect them. Do that across your schema markup, Wikidata and a short list of third-party profiles, and you give the Knowledge Graph what it needs to build a panel. Once the panel appears, you claim it and keep it accurate.
The rest of this guide is the setup, in the order that works.
How Does Google Decide a SaaS Company Deserves a Panel?
Google announced the Knowledge Graph on May 16, 2012, in a post by Amit Singhal titled “Introducing the Knowledge Graph: Things, Not Strings.” The idea was that search should understand entities (a company, a person, a product) instead of matching keywords. By May 2020, Google’s public liaison for search, Danny Sullivan, wrote that the Knowledge Graph had collected over 500 billion facts about five billion entities.
Sullivan’s post also explained where those facts come from. Google compiles them from sources across the web, from open and licensed databases, and from markup that site owners publish. “Wikipedia is a commonly-cited source, but it’s not the only one,” he wrote. That sentence matters for software companies, because very few early-stage SaaS businesses meet Wikipedia’s notability bar.
The history explains why open databases carry so much weight. Google’s early Knowledge Graph was powered in part by Freebase, a community database it acquired through Metaweb in 2010. On December 16, 2014, Google announced it would shut Freebase down and help move its data to Wikidata, and freebase.com went offline for good on May 2, 2016. If you query Google’s Knowledge Graph Search API today, many older entity IDs still begin with “/m/”, the Freebase format, while newer ones begin with “/g/”. The lineage is still visible in the data.
So the practical answer is that Google builds a panel when several trustworthy sources agree on who you are. No single source triggers one. Disagreement between sources stalls one.
Your Company and Your Product Are Two Entities
This is the problem that makes the knowledge panel for SaaS different from a panel for a law firm or a restaurant. A software company usually has at least two things worth describing: the business that employs people, raises money and has a headquarters, and the application that customers log in to, which has a price, an operating system and reviews.
Sometimes they share a name. Sometimes the product name is famous and the company name is obscure. Sometimes the company renamed itself after the product took off, and half the web still uses the old name. Each of those cases confuses the matching systems. Google sees a founding date attached to a product, a pricing page attached to a company, and a logo that belongs to both, and it cannot decide what the entity is.
Schema.org already gives you separate vocabulary for each. Organization (or a more specific subtype) describes the company. SoftwareApplication, with subtypes such as WebApplication and MobileApplication, describes the product. Google’s documentation treats them differently too. Organization markup has no required properties and is used to disambiguate your business and choose the logo shown in search results and your knowledge panel. SoftwareApplication markup is aimed at rich results and requires a name, an offers.price (set to 0 if the app is free) and either an aggregateRating or a review.
The goal is not to pick one. It is to describe both and tie them together so that every source tells the same story: this company, founded in this year, headquartered here, makes this product.
Build the Split Ledger Before You Touch Markup
Most teams start by pasting JSON-LD into a page. That is backwards. The markup will only repeat whatever inconsistencies already exist in your public profiles, so start with an audit. Call it the Split Ledger.
The Split Ledger is a simple document with two halves. The left half is the company. The right half is the product. Under each, write the canonical value for seven facts: the official name, any alternate names (including old names), the canonical URL, the founding or launch date, the headquarters or primary market, the founder or publisher, and the logo file. The company half also gets a category in plain words, such as “business software company.” The product half gets an application category from Google’s supported list, such as BusinessApplication or DeveloperApplication.
Then check those values against six sources: your homepage or About page, your product or pricing page, your LinkedIn company page, your Crunchbase profile, your main review directory listing (G2, Capterra or an app marketplace), and Wikidata if an item exists. For every fact, mark whether each source matches the ledger exactly, differs, or says nothing.
The score is the count of mismatches. A mismatch is any source that states a different value, not a source that is silent. Silence is a gap you can fill later. Contradiction is what holds a panel back. A founding year of 2019 on LinkedIn and 2020 on Crunchbase is a mismatch. A product listed on G2 under your old company name is a mismatch. A logo that is a wordmark on your site and an icon on LinkedIn is a judgment call, so pick one primary logo and use it as the Organization logo everywhere.
Aim for zero mismatches before you publish new markup. In practice, the first pass usually turns up a handful, and most are fixable in an afternoon by logging into the profiles you already own. The ones you cannot fix directly, such as an old article with the wrong founding year, go on a list for outreach later. The ledger also becomes your reference document, so the next person who edits the About page or a directory listing copies the canonical values instead of improvising.
Write Organization and SoftwareApplication Markup That Agrees With Itself
With the ledger clean, the markup is a transcription job.
Put Organization markup on your homepage or a single About page. Google says you do not need it on every page. Include name, legalName if it differs from your brand name, alternateName for former or shortened names, url, logo, description and foundingDate. Add sameAs with the URLs of the profiles from your ledger: LinkedIn, Crunchbase, your Wikidata item, your X or YouTube account, and your main review listing. Google describes sameAs as pointing to pages on other sites with more information about your organization, which is exactly the job here. If you have a DUNS number or an LEI, Google now recommends expressing it with the iso6523Code property, for example a value beginning with 0060 for DUNS or 0199 for LEI. These identifiers do not show up visually. They help Google tell your company apart from others with similar names.
Put SoftwareApplication markup on the product or pricing page. Use name, applicationCategory, operatingSystem (for a browser-based product, “Web” or the platforms you support), offers with price and priceCurrency, and an aggregateRating or review that follows Google’s review snippet guidelines. Do not invent ratings. If you do not have reviews you can show on the page, you will not qualify for the rich result, but the markup still states the product’s name, category and price in a form machines can read.
Then connect them. In the SoftwareApplication block, set publisher or provider to your Organization, ideally by referencing the same @id you gave the Organization on your homepage. That one link tells Google the product belongs to the company, which is the relationship the Split Ledger was built to clarify.
Validate both with Google’s Rich Results Test and the Schema Markup Validator. Then search your brand name a few weeks later and see whether the logo and description in results match your ledger.
Is Your SaaS Company Ready for Wikidata?
Wikidata is the open database that took over Freebase’s role, and it is one of the cleanest ways to give the Knowledge Graph a structured description of your company. It is also a community project with rules, and items that break them get deleted.
Wikidata’s notability policy accepts an item that meets at least one of three conditions: it has a sitelink to a Wikimedia page such as a Wikipedia article, it is a clearly identifiable entity that can be described using serious and publicly available references, or it fills a structural need in Wikidata. Most software companies qualify under the second condition or not at all. That means you need independent sources, such as trade press, funding coverage or analyst mentions, before you create an item. Your own website can support basic facts like the official URL, but it should not be the only reference.
If you qualify, keep the company item tight. Use instance of (P31) with a value such as business, put the sector under industry (P452) rather than forcing it into the instance field, and add official website (P856), inception (P571) and headquarters location (P159), each with a reference. If the product is independently notable, create a separate item for it as a software instance with a developer or publisher statement pointing back to the company. That mirrors the split in your schema. Add the Wikidata URL to your Organization sameAs once the item is live.
Disclose your connection if you edit your own company’s item, and keep descriptions neutral. Promotional language is the fastest route to a deletion request. We wrote a longer piece on Wikidata notability if you want the edge cases.
Get Third-Party Sources Saying the Same Thing
Markup and Wikidata are statements you control. The Knowledge Graph also weighs what others say about you, and that is where many SaaS panels stall. A company can have flawless JSON-LD and still have no panel because the only sources describing it are its own. Of every step in building a knowledge panel for SaaS, this is the one founders most want to skip, and the one that most often decides the outcome.
The fix is earned coverage that repeats your ledger facts. A funding announcement picked up by a trade publication that names your founders and founding year. A podcast interview whose show notes link your homepage and state what the product does in one sentence. An analyst or comparison article that names the product and the company together. Each of those adds an independent source that agrees with your markup instead of contradicting it.
When you pitch, hand journalists the canonical values. Put a short boilerplate at the bottom of every press release with the official company name, the product name, the founding year and the headquarters city, and keep it identical across releases. Reporters copy boilerplate, and that consistency flows into the coverage. Correct errors when they appear. A polite note to an editor asking them to fix a founding year is a small request, and it removes a mismatch from the record permanently.
This is also where answer engines come in. The same consistency that helps Google build a panel helps ChatGPT, Perplexity and Google’s AI features describe your company correctly, because they draw on overlapping sources. If you want to see how those systems currently describe your brand, the free Instant Press AEO rating checks it.
Claim the Panel, Then Maintain It
When a panel appears, claim it. Search Google for your company, click “Claim this knowledge panel” at the bottom of the panel, review the information, and sign in to one of the official profiles Google lists, which per Google’s help page include YouTube, Search Console, X (listed by Google as Twitter) and Facebook. A Search Console property for your domain is usually the cleanest match for a software company. If Google cannot connect you to an official profile, it asks for more information to verify you. Not every panel can be claimed, and Google directs businesses that serve customers at a physical location to Google Business Profile instead.
Once verified, you can suggest edits through the Feedback link, flagging a fact, describing the correction and attaching links that prove it. Google assigns roles too. Owners and managers can add or remove users, and contributors can suggest changes. Give access to at least two people so the panel does not depend on one employee.
Then maintain the ledger. Rebrands, acquisitions, new headquarters and product launches all create fresh mismatches. Update the ledger first, then the markup, then the profiles, then send feedback on the panel. In that order, every source moves together.
The short version: you cannot request a knowledge panel for SaaS, but you can earn one. Split your company and product into two clearly described entities, audit every public source against the Split Ledger until the mismatches hit zero, publish Organization and SoftwareApplication markup linked by a shared @id, add a properly referenced Wikidata item if you qualify, earn third-party coverage that repeats the same facts, and claim the panel the day it appears.