Press Kit: What a B2B Software Company Should Actually Publish

A press kit is the set of facts and files a company publishes so that anyone writing about it can get the details right without having to ask: what the company does, who runs it, when it started, how to reach a human, and which logo file is the current one. The reader here is whoever at a SaaS, AI, or B2B software company just got that request and has nothing to send back. It covers what belongs in the kit, why the whole thing works better as a page than as a download, where on the site it should sit, and how to mark it up so machines can read it.

One boundary before anything else: in music and film, the same phrase usually describes an electronic press kit built around a bio, photos, and a track or a trailer. That is a different document for a different industry, and this article is about the company version.

The short version

• A press kit is a page, not a folder of downloads. A PDF cannot be crawled section by section, cannot be linked to at the paragraph a writer needs, and cannot carry structured data.
• Four components do almost all the work: the boilerplate, a fact sheet, a logo file, and a named contact who replies. Several of the standard components exist for your own brand and legal teams rather than for the press.
• A press kit and a media kit are different documents with different readers. One serves people writing about you. The other serves people buying advertising from you.
• A press page is one of the few pages on a company site whose entire job is to state checkable facts about the company, which makes it unusually easy for a machine to parse and unusually expensive to get wrong.
• If nobody has asked for yours, building it is not this quarter's priority. The kit supports coverage. It does not create it.

What is a press kit?

A published set of facts and files about a company, assembled so that someone writing about it does not have to guess. The name comes from the physical version: a folder of printed sheets and photographs handed to reporters at an announcement. The folder is gone. The job it did has not changed.

That job is accuracy under time pressure. A writer on deadline needs your legal name spelled correctly, a description of what you sell that you will not later dispute, a logo that holds up in print, and someone who answers email today.

The people who ask are more varied than the name suggests: reporters and editors, but also analysts building a category map, partner marketing teams preparing a joint launch, conference organizers chasing a speaker bio. They want overlapping but not identical things, which is why the list below is organized by reader rather than by asset type.

What is the difference between a press kit and a media kit?

The reader, and therefore everything else. A press kit serves people writing about your company. A media kit, in its original sense, serves people considering buying advertising from you, which is why it leads with audience size and rate cards.

Document	Who it is for	What it contains
Press kit	Journalists, analysts, partners, anyone publishing something about you	Boilerplate, company facts, leadership, logos, contact, announcement archive
Media kit	Advertisers and sponsors evaluating your audience	Audience size and makeup, ad formats, placements, rates, sponsorship options
Electronic press kit (EPK)	Music and film press, bookers, festival programmers	Artist or production bio, photos, a track or trailer, past coverage, tour or release dates

The two terms have blurred in ordinary use. The distinction matters in one situation: if a partner asks for your media kit and you send a boilerplate and a logo pack, you have answered a different question. Ask which they mean before sending anything.

EPK is worth naming explicitly, because searching for press kit advice surfaces a great deal of it. Those contents are built around an artist or a production rather than a company, and almost none of that structure transfers here.

What actually goes in a B2B software press kit?

Nine components, and they are not equally important. Across the sources we reviewed, the usual advice presents them as a flat checklist, which implies every reader of the page needs every item. The table below separates them by who reaches for each one.

Component	Who actually uses it	What goes wrong
Boilerplate	Everyone writing about you	Written as positioning copy, so nobody can quote it. Keep it to two or three factual sentences
Company fact sheet	Journalists and analysts verifying details	Facts scattered across three pages instead of sitting in one scannable block
Media contact	Anyone who needs an answer today	A generic inbox nobody owns. A named person with a real reply time beats a shared alias
Logo files and usage rules	Designers and production editors at the publication	One PNG on a white background. Supply SVG, a dark variant, and the clear-space rule
Leadership bios and headshots	Profile writers, conference organizers, podcast producers	Bios that read as internal titles rather than as something publishable
Product screenshots	Reviewers and anyone illustrating a piece	Marketing renders instead of the actual interface, which is not what a reviewer illustrating the product needs
Announcement archive	Analysts building a timeline, and your own team	Treated as the main event. It is a reference shelf, not the kit
Coverage list	Mostly your sales team and candidates	Stale links, and an implicit claim that old coverage is current
Brand guidelines	Partners running co-marketing	A 40-page deck where a one-page summary would do

Read the middle column and the priority order falls out. The boilerplate, the fact sheet, a usable logo, and a contact who replies are what a writer on deadline takes. Build those four properly and the page is already doing its job.

The boilerplate deserves a paragraph of its own: it is the sentence that ends up inside other people's articles, so write it to be lifted. Legal name, category, what the product does, who buys it, and one verifiable fact such as the founding year or the headquarters city. Positioning language belongs on the home page, not here, because a writer cannot repeat a claim they have no way to check.

The fact sheet earns its place by removing questions before anyone has to ask them. A short block covering legal name, founding year, headquarters, leadership, funding status, employee band, and product category answers most of what anyone would otherwise email to ask. State only what you are willing to have quoted back to you.

On the announcement archive, one boundary is worth drawing. A press page is where announcements live. It is not a distribution strategy, and the two answer different questions. Our guide to whether press releases still earn links covers the distribution half of that question and this article does not re-argue it.

Should it be a page or a PDF?

A page, with a PDF only where a file is genuinely the deliverable. Our analysis suggests the format decision is the highest-leverage one on this list, because it determines whether the kit can be found, cited, and corrected.

What you need it to do	Page	PDF
Be found by someone searching for it	Crawlable and indexable like any other page	Indexable as a document, but far harder to surface for a specific detail
Be linked to at a specific section	Anchor links to any heading	Page numbers at best
Carry structured data	Yes, in the page markup	No
Be corrected after a change	Edit once, everyone sees the current version	Old copies keep circulating with the old facts in them
Hand over large binary assets	Link to a zip or an asset library	Fine, and this is the honest use case

The last row is where a file still earns its place. Brand guidelines, a logo bundle, and a high-resolution image set are files by nature, and packaging them for download is correct. What should not be a download is the information itself.

Version drift is the argument worth leading with. A downloaded kit is a snapshot that keeps circulating after it stops being true, and there is no way to call it back. A page has exactly one current version, which is also why it is the thing to link from a pitch rather than attach.

Where should it live, and what should the URL be?

On your primary domain, one level down from the root, at a URL you have no intention of changing. /press and /newsroom are both fine and the choice barely matters, as long as you pick one and keep it. What matters more is that the address is short, guessable, and permanent, because people will type it directly and other sites will link to it for years.

Give the heavy components their own child pages rather than one endless scroll. /press for the kit, /press/brand for logos and usage rules, /press/news for the archive: each page stays about one thing, and a writer gets something specific to link to.

Our recommendation on hosting is firmer than the URL advice. If a newsroom platform serves the page from a domain it owns, that is convenient right up to the moment you leave the vendor: links other people built point at their domain, any authority the page accumulated sits there, and the address is not yours to keep. Check which domain a hosted newsroom will answer on before you sign, and insist on your own.

Then link it from two places: the footer, and a line on the about page, which is the other obvious place to look for it.

How do you mark it up so machines can use it?

With schema.org's Organization type, and with more care about placement than the advice usually gives it. Schema.org defines Organization as "an organization such as a school, NGO, corporation, club, etc.", and the properties that describe a company's identity are the ones a press page already states in prose.

The properties worth declaring, using schema.org's own definitions: legalName for "the official name of the organization, e.g. the registered company name", foundingDate for "the date that this organization was founded", founder, url, logo, description, address, contactPoint, numberOfEmployees, and sameAs, which schema.org defines as the "URL of a reference Web page that unambiguously indicates the item's identity". Of those, sameAs is the one carrying the disambiguation load, pointing at the profiles and directory entries that describe the same company.

Now the placement point, which cuts against the instinct to put the markup on the press page. Google's guidance on organization structured data says the markup "can help Google better understand your organization's administrative details and disambiguate your organization in search results", and is explicit about where it goes: "We recommend placing this information on your home page, or a single page that describes your organization, for example the about us page." It adds that the markup does not need to appear on every page of the site.

So the practical rule is one Organization block, on whichever page you treat as the canonical description of the company, with the press page's visible text agreeing with it. Two blocks making slightly different claims is worse than one.

Two constraints belong here, both drawn from Google's general structured data guidelines. Markup must be "a true representation of the page content", and it must not describe anything "not visible to readers of the page". Together those rule out the familiar shortcut of declaring an employee count or a funding figure that appears nowhere in the visible text. Our guide to marking pages up with schema covers the JSON-LD mechanics and validation.

Do AI answer engines use press pages?

We have not measured that, and we are not going to assert it. The defensible version of the claim is narrower, and still worth acting on: a press page is structurally the kind of page machines parse well, and making it parseable costs almost nothing.

The reason is the page's unusual job. Most pages on a company site argue something. A press page states things, in short declarative sentences, with low ambiguity and few competing claims per paragraph. Founding year, headquarters, leadership, category, funding status. That is a dense, low-noise block of entity facts, and Google's own documentation describes structured data on exactly that material as helping to "disambiguate your organization in search results".

The corollary is what makes this a real argument rather than a hopeful one. A wrong or stale fact on your press page sits in the most quotable, most machine-legible format you have published, and correcting it later is harder than getting it right once. The upside of a clean press page is uncertain. The downside of a stale one is not.

The other half of the entity picture is not something you control by publishing. Independent sources describing your company in their own words are what corroborate the facts you state about yourself, and our guide to the independent coverage Wikipedia requires sets out how high that bar actually sits. A press page is your side of that exchange, and it is the cheap side.

What does a good one look like?

Atlassian's, which is worth opening in another tab. Visited on 12 September 2026, the page at atlassian.com/company/news/press-kit is organized into named sections for executives, founder headshots, logos, products, a company overview, press releases, and contact, with press@atlassian.com given as the press address.

Three things it gets right. Sections are named for what a reader wants rather than for how assets are stored internally, so someone after a headshot finds a heading saying headshots. The contact is a real press address, linked as a mailto rather than routed through a form. And the logos live behind a link into the design system, so the press page does not go stale when the brand updates.

The trade-off is equally visible. Company facts and press releases both live elsewhere, so the kit hands a reader onward rather than answering in place. At that scale, with an investor relations obligation and a decade of announcements, that is reasonable. For a Series A company whose entire fact sheet fits in a nine-row table, copying the structure means building navigation around content you do not have yet.

The transferable lesson is the section naming, not the architecture. Start with one page, headings named for what people ask for, and split a section out only once it deserves a URL.

How often should you update it, and who owns it?

On triggers rather than on a schedule, with one named owner and one calendar check a quarter as a backstop. A press kit does not decay gradually. It breaks at specific moments, and those moments are predictable.

The triggers worth wiring to a reminder: a funding round closing. A leadership change, especially a departure. A rebrand or a new logo. A change in how you describe the product category. A move of headquarters or a change of legal entity. A pricing or packaging change significant enough that the old description is now wrong.

The quarterly check exists because a funding close and a leadership change can both land without marketing hearing about either. A ten-minute pass confirming that everyone listed still works there and every link still resolves catches the rest.

Ownership decides whether any of this happens. The recognizable failure is a press page belonging to nobody: built during a launch by someone who has since changed roles, listing an executive who has left, serving a logo two versions old. That is worse than having none at all, because a journalist who uses it publishes your stale facts in good faith.

When is a press kit not the priority?

When nobody is asking for one. That sounds glib, so here are the four situations where building the kit is the wrong use of the week.

• No inbound requests and no coverage yet: a press kit supports coverage rather than generating it. If no writer has contacted you, the constraint is upstream, and earned media is the problem to work on first.
• No story to tell: if the interesting thing about the company is not yet built, launched, or measured, an immaculate press page gives a reporter nothing to write about. Our guide to the pitch that goes with it starts from the story rather than the assets.
• Facts still in flux: pre-rebrand, mid-raise, or between product positioning decisions, a press kit written this week is a page you will contradict next month. Publish a boilerplate and a contact address, and wait for the rest.
• Nobody will own it: if no named person will keep it current, the honest version is a short page with a contact address, not a complete kit that quietly goes out of date.

The minimum viable version answers a first request adequately: legal name, one paragraph on what the company does, the founding year, the leadership names, a logo file, and an email address a person reads. Everything else here is what you build once requests arrive regularly.

Where the requests are already arriving and the capacity to answer them properly is not there, the coverage side of the problem is what our digital PR work exists to solve, rather than the asset production.

The habit worth building is treating the press page as a product surface with a named owner, not as a launch artifact. Product surfaces get reviewed when the thing they describe changes. Launch artifacts get built once and quietly rot, and the difference is entirely whether someone's name is against it.

This week, open your own site and try to find your press kit the way a stranger would: type the domain followed by /press, then check the footer. If neither path gets you there in ten seconds, that is the first fix, and it is a smaller job than writing the page.