Enterprise B2B AXO Guide

The bottom of the enterprise funnel has not moved. Contracts still get signed after security review, a procurement cycle, and an argument about the MSA. What moved is the quiet phase before any of that, when a technical lead assembles a shortlist without contacting a single vendor. That phase now runs partly through an assistant, and the assistant reads your site the way a fetcher reads it: no JavaScript execution, no gated content, no context supplied by your sales team.

In B2B the documentation is the marketing

Your technical documentation is read by three audiences and written for one. Evaluators read it during selection to work out whether the product does the thing they need. Engineers read it during implementation to work out how. Coding agents now read it on behalf of both, and an agent asked to wire up an integration fetches your docs, never your homepage.

This is the sector where that stops being a nice observation and becomes the strategy. Nobody chooses an observability platform because of a hero headline. They choose it because somebody skimmed the docs, found the ingestion limits and the retention model stated plainly, and concluded the product was serious. Marketing owns the homepage. Docs are usually owned by whoever had spare time, and they are the more valuable asset by a wide margin.

The most common way a docs site becomes invisible is architectural rather than editorial. Most AI fetchers do not execute JavaScript. A documentation site built as a client-rendered single-page app returns an empty shell with a loading spinner to anything that does not run a browser engine, which means every API reference, every code sample, and every configuration table you have written is absent from the version of your site that gets read during evaluation. Fetch one of your own doc pages with curl and read what comes back. That is the document.

curl -sL https://docs.example-platform.com/api/webhooks | wc -c
curl -sL https://docs.example-platform.com/api/webhooks | grep -c "signing secret"

# If the byte count is small and the grep returns 0, the page a fetcher
# sees does not contain your webhook documentation. It contains a <div
# id="root"> and a bundle reference.

• Author in markdown and expose the markdown. Serving the rendered HTML is table stakes. Serving the source at a predictable address alongside it — /api/webhooks.md next to /api/webhooks, or the same URL under content negotiation for text/markdown — hands a consumer a document with unambiguous heading structure, code fences, and no navigation chrome to strip. Several developer-tool companies now do this. It is a convention rather than a standard, and it costs a routing rule.
• URLs are an API and breaking them is a breaking change. Every heading gets a stable anchor that does not change when the heading is reworded. A docs reorganisation that moves forty pages without redirects invalidates every link anyone has ever saved, cited, or pasted into a runbook.
• Version the content and say the version in the prose. A dropdown in the top-right corner that swaps the docs to v2 is invisible in an extracted passage. "This endpoint requires API version 3.2 or later" travels with the sentence. Keep prior versions at their own URLs, canonical the current one, and label superseded pages in their first paragraph rather than in a banner.
• Put the constraints in the reference, not in a sales conversation. Rate limits, payload ceilings, retention windows, concurrency caps, supported auth methods. These are the facts that decide a technical evaluation, and burying them is a decision to lose evaluations you would have won.
• Complete, runnable examples beat fragments. A snippet with YOUR_API_KEY_HERE and three elided lines is guessed at. An example that runs end to end, with the request, the headers, and the actual response body, is copied correctly.

There is a retrieval-side reason to fund docs maintenance as well. Ahrefs' 2026 analysis found that AI-cited URLs skew roughly 25.7% fresher than the web at large (source). Documentation that tracks the product, with a real changelog carrying dates and version numbers, is on the right side of that. Documentation describing the 2024 API surface is not, and it is also the thing that makes an evaluator quietly close the tab.

Beyond publishing the docs well, there is the question of exposing the product itself to an agent rather than only describing it. An MCP server that lets an assistant call your API directly during an evaluation is a different category of thing from a documentation page about your API. The implementation patterns guide covers MCP after the stateless 2026-07-28 revision, along with the rest of the agent-facing stack.

The comparison gets written whether or not you write it

Ask any assistant to compare four vendors in a category and it will produce a comparison. It does not decline for want of material. If you have published nothing, it assembles your column from your competitors' comparison pages, from analyst summaries, and from forum threads.

Ahrefs' July 2026 analysis of citations across AI engines found Reddit the most-cited domain, at roughly 16.7% of ChatGPT citations (source). For enterprise software that number is not incidental. Practitioners describe what a tool is actually like to operate in subreddits, and they do it with the candour of people who are not being quoted in a press release. Your unpublished weaknesses are already documented; they are documented by the person who spent a weekend fighting your migration tooling.

Which makes publishing an honest comparison the rare case where admitting a weakness is the commercially correct move. The choice is not between a comparison that flatters you and no comparison at all. It is between a comparison you wrote and one your competitor's marketing team wrote about you.

The right-hand version is more useful to a buyer, more quotable, and considerably more likely to be reproduced verbatim, because it contains propositions rather than adjectives. It also disqualifies the wrong prospects early, which your sales team will thank you for once they stop being annoyed about it.

• Pick the rows the buyer picks. Deployment model, data residency, pricing unit, integration coverage, migration effort, support SLA, contract minimum. Not the six features you shipped last quarter.
• Name the losing condition, not just the loss. "They are stronger for teams under fifty seats" is more credible and more useful than a vague concession, and it tells the reader whether the loss applies to them.
• Cite the competitor's own documentation for their side. Linking to their pricing page and their docs, rather than to your description of them, makes the comparison checkable and makes it much harder for them to complain you misrepresented anything.
• Date it and review it on a schedule. A comparison against a competitor's 2024 feature set is a liability rather than an asset, and they will happily point that out to a prospect. State the review date in the body text.
• One page per competitor. A single page covering eight rivals gets extracted for the wrong one. Separate pages also match the query a buyer actually types, which names two products.
• Do not fake the third-party voice. Buyers and engines both discount a comparison hosted on your domain, which is fine and expected. Laundering it through a review site or an astroturfed thread is a different thing entirely, and it is the kind of thing that surfaces.

Alternatives pages follow the same logic with one wrinkle. A page titled "alternatives to Competitor B" is transparently a bid for a query where somebody is looking to leave. That is legitimate. Write it as an actual survey of the category, list options you do not sell, and say which of them you would choose over yourself and when. A page listing five alternatives where four are strawmen is recognisable at a glance, by a person and by a model.

What "contact sales" costs when the researcher cannot fill in a form

"Contact sales" is a form, and a form is a dead end for the thing doing the research. The assistant does not queue up in your pipeline. It reports that your pricing is not public and moves on, usually in the same paragraph where it prints a competitor's actual numbers. The buyer sees a table with three rows carrying figures and one carrying an absence.

An absence in that position reads as expensive, evasive, or both. Neither reading is one you chose.

SparkToro's 2026 analysis found that 68% of US Google searches ended without a click between January and April 2026, up from 60.45% in 2024 (source). Applied to a buying committee, that describes a research phase which largely never lands on the page where your form lives. The gate was designed for a visitor who arrives. Fewer of them arrive.

The reasons enterprises hide pricing are real and worth stating before dismissing any of them. Price genuinely varies by seat count, deployment model, support tier, region and term. Publishing a list price constrains a discounting strategy that is often the actual commercial model. Competitors read your pricing page and undercut it the same afternoon. Some existing contracts carry most-favoured-nation clauses that make a published number legally awkward. And a company still finding its price does not want to nail it to the wall.

None of those require the page to say nothing. There is a middle path, and it costs you far less negotiating room than the people defending the gate believe.

Opaque    "Enterprise    Contact sales"

Useful    "Enterprise plans start at $40,000 per year. Pricing is per
           named user, with volume tiers at 250, 1,000 and 5,000 seats.
           Three things move the figure: deployment model (multi-tenant
           SaaS, single-tenant, or self-hosted), support tier, and
           whether you need access to the FedRAMP environment. Every
           enterprise plan includes SSO, SCIM, audit log export,
           unlimited environments, and a named technical account
           manager. Prices are list, exclusive of tax, and reviewed
           each January."

The second version does not stop you negotiating. It stops you being omitted. It also does most of the qualification your SDR was going to do on the first call, which is why the sales objection to publishing it tends to soften once somebody counts how many of those calls end at the price.

• Publish the floor if you publish nothing else. One number, the annual minimum, in text. It answers the only question half your visitors have and it filters out the people who were never going to buy.
• Name the unit even when you withhold the rate. Per named user, per active user, per workflow run, per gigabyte ingested, per node. The unit determines whether the model fits the buyer's shape at all, and it is a much cheaper disclosure than the number.
• Say what moves the price, in both directions. A buyer who understands the drivers can estimate, and an assistant can pass on the estimate with the conditions attached.
• Put tier contents in text, not in a checkmark grid. An image or an icon matrix conveys nothing to a fetcher. "The Enterprise plan includes SSO, SCIM provisioning, audit log export and a 99.9% uptime SLA" is a sentence that gets quoted.
• If SSO sits behind the top tier, expect that to be reported. Charging separately for security features is a defensible commercial decision and a well-known complaint. Either own it in the copy or change it. Silence gets filled from elsewhere.
• Date the pricing page and honour the date. A number without an effective date cannot be trusted a year later, and stale published pricing is worse than none.

We will state a position rather than hedge it. For most B2B software companies outside the largest enterprise deals, hiding pricing entirely now costs more in shortlist omissions than it earns in negotiating room. That was not obviously true in 2022, when the buyer reached the pricing page and hit the form and called you anyway. The buyer who never reaches the page cannot be captured by a gate.

"Does it work with X" is usually answered in an image

Compatibility is one of the two or three most common questions in an enterprise evaluation, and the standard answer to it is a logo wall: forty vendor marks in a grid, rendered as images, with no alt text and no accompanying prose. To anything that does not do image recognition on your marketing page, that grid contains nothing at all. You have answered the question in a format that cannot be read.

Keep the grid. Put the list underneath it in text, and make each entry say what the integration actually does, because "Example CRM" as a bare word does not distinguish a two-way object sync from a button that opens a link.

Logo only    [example-crm.svg]

In text      Example CRM — two-way sync of accounts, contacts and
             opportunities through the Example CRM REST API. Built and
             supported by Example Platform. Requires Example CRM
             Enterprise Edition or above. Custom objects are supported;
             Example CRM Files are not. Setup takes about 20 minutes and
             needs an Example CRM user with API Enabled and Modify All
             Data permissions.
             Docs: docs.example-platform.com/integrations/example-crm

• One page per integration that matters. Setup steps, the data that crosses the boundary, the auth method, the permissions required, and the limits. This is also the page the implementing engineer needs six weeks later.
• Say what you do not integrate with. "Example Platform has no NetSuite integration and none is planned" is a clean answer. Silence is a gap, and a gap gets filled with a guess that may be generous or may be wrong in the other direction.
• Mark who built and who supports each one. First-party, partner-built, and community-maintained are three different reliability promises. A buyer who discovers during implementation that the connector they chose you for is an unmaintained community plugin will remember how they found out.
• List the standards, not only the brands. SAML 2.0, SCIM 2.0, OIDC, OpenTelemetry, S3-compatible object storage, the PostgreSQL wire protocol, OpenAPI 3.1. Protocol names answer a whole class of compatibility questions at once and they match the way a technical evaluator phrases things.
• Qualify with versions. "Works with Kubernetes" is a claim nobody can act on. "Tested on Kubernetes 1.29 through 1.33" is a fact somebody can check against their cluster.

Certifications should be public even when the audit report is not

SOC 2 Type II, ISO/IEC 27001, GDPR posture, data residency, the subprocessor list. This is factual, checkable, high-value content that a security reviewer will look for early and that most companies file entirely behind a form in a trust centre.

The tension here is genuine and the resolution is not "publish everything". Gating the audit report itself is defensible. It contains control descriptions, exceptions, and auditor findings, and you have a legitimate interest in knowing who holds a copy and under what NDA. Keep the gate on the document. The existence, scope and currency of your certification is a different thing, and there is no security argument for hiding it. Your competitors already know. The only party the gate excludes is the researcher deciding whether you clear the bar.

• One public security page, ungated, stating each certification with its scope. "SOC 2" on its own is close to meaningless. Which trust services criteria, covering which systems, audited by whom, over what observation period, expiring when.
• Type I and Type II are not interchangeable. One tests design at a point in time; the other tests operating effectiveness over a period. Reviewers know the difference and will notice a page that blurs it.
• Data residency as a named list of regions. Which regions you offer, whether the customer chooses at provisioning, whether data can leave the region during support access, and what covers that transfer.
• Publish the subprocessor list as a dated table with a subscribe link. Most DPAs oblige you to notify changes anyway. A public list saves a round trip in every security review you will ever run, and it is the single most requested artefact after the SOC 2 report.
• For GDPR, name the mechanism rather than the aspiration. Your role as processor or controller, your transfer mechanism, the URL of the DPA, and how a customer executes it. "GDPR compliant" asserts a conclusion; the mechanism is the evidence.
• Do not claim certifications that do not exist. There is no HIPAA certification. If what you mean is that you will sign a BAA, write that. Overclaiming here is checkable, and it is checked by the one audience with a professional obligation to be suspicious.

The security page is also the page most likely to be quietly out of date, because the person who set up the trust centre has usually moved on by the second renewal. An expired certification stated as current is a false statement about a regulated attestation, made on your own domain, and it is the kind of thing that ends a deal at the exact moment it was going to close.

An anonymous case study is worth nothing to a retrieval system

"A leading financial services firm reduced processing time by 40%" names nobody, dates nothing, and can be verified by no one. There is no entity for a retrieval system to attach the claim to and no basis on which to weigh it against a competitor's identically-shaped sentence.

We have a duty to say the harder part plainly, because this site tells other people to source their claims. That sentence reads as invented. Often it is: a number produced by a sales engineer's model, rounded up, attached to a customer who never signed off on it, and published because the case studies page needed a third tile. A buyer who has read four vendor sites has seen the same construction on all four, with a different percentage each time, and has already stopped counting them as evidence.

Real customers do agree to be named when the outcome is real, the legal review starts early, and somebody senior asks. It is slower than writing an anonymous one. It is also the only version that functions as evidence.

• Name the company, the person, and the role. A quote attributed to "VP of Engineering at a Fortune 500 retailer" is not attribution. A quote from a named director at a named company is a claim that person has staked something on.
• Give the number a baseline and a window. "Median deploy time fell from 42 minutes to 9 minutes between March and September 2026, measured across their CI pipeline" can be reasoned about. "78% faster" cannot.
• Say who measured it and how. Customer-supplied figures, your telemetry, and a modelled projection are three different evidentiary weights. Label which one you are presenting.
• If the customer will not be named, say that, and say why. "Figures supplied by the customer, a US health insurer that asked not to be identified, verified against their internal reporting in July 2026" is honest and still useful. A vague industry descriptor with no acknowledgement that anonymity was requested is dressing up a gap.
• Label illustrative figures as illustrative, in the same sentence as the figure. ROI calculators and modelled savings have a legitimate place. A modelled number presented in the visual language of a measured result does not.
• Link outward wherever the customer has said anything publicly. A conference talk, an engineering blog post, a podcast episode. Third-party corroboration you do not control is worth more than any case study you write.

Markup for a product being evaluated rather than browsed

Three types carry most of the weight in B2B. SoftwareApplication describes the product, including the pricing structure and the platform requirements. Organization describes the company and, through sameAs, connects it to the external profiles that let a system resolve which Example Platform you are. FAQPage carries the evaluation questions in a form that maps question to answer without inference.

On FAQPage specifically: Google restricted FAQ rich results to government and health sites in 2023, so this markup buys no SERP treatment for a software vendor. Emit it anyway, and emit it for machine-readability rather than for a visual feature. The same rule as everywhere else applies — the questions and answers must appear in the visible page text, not only in the JSON-LD.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example-platform.com/#organization",
      "name": "Example Platform",
      "legalName": "Example Platform, Inc.",
      "url": "https://example-platform.com/",
      "foundingDate": "2017-04-03",
      "numberOfEmployees": { "@type": "QuantitativeValue", "value": 240 },
      "address": {
        "@type": "PostalAddress",
        "streetAddress": "80 Example Street, Floor 6",
        "addressLocality": "Boston",
        "addressRegion": "MA",
        "postalCode": "02110",
        "addressCountry": "US"
      },
      "contactPoint": [
        {
          "@type": "ContactPoint",
          "contactType": "sales",
          "email": "sales@example-platform.com",
          "areaServed": ["US", "CA", "GB", "DE"],
          "availableLanguage": ["en", "de"]
        },
        {
          "@type": "ContactPoint",
          "contactType": "technical support",
          "url": "https://example-platform.com/support"
        }
      ],
      "hasCertification": [
        {
          "@type": "Certification",
          "name": "SOC 2 Type II",
          "description": "Security, Availability and Confidentiality trust services criteria, covering the Example Platform production environment and supporting infrastructure.",
          "certificationIdentification": "SOC 2 Type II",
          "certificationStatus": "https://schema.org/CertificationActive",
          "issuedBy": {
            "@type": "Organization",
            "name": "Example Assurance LLP"
          },
          "auditDate": "2026-05-29",
          "validFrom": "2025-06-01",
          "expires": "2027-05-31",
          "url": "https://example-platform.com/security"
        },
        {
          "@type": "Certification",
          "name": "ISO/IEC 27001:2022",
          "certificationIdentification": "IS 000000",
          "certificationStatus": "https://schema.org/CertificationActive",
          "issuedBy": {
            "@type": "Organization",
            "name": "Example Certification Body Ltd"
          },
          "auditDate": "2026-02-11",
          "expires": "2029-02-10",
          "url": "https://example-platform.com/security"
        }
      ],
      "sameAs": [
        "https://www.linkedin.com/company/example-platform",
        "https://github.com/example-platform",
        "https://www.crunchbase.com/organization/example-platform",
        "https://www.wikidata.org/wiki/Q00000000"
      ]
    },
    {
      "@type": "SoftwareApplication",
      "@id": "https://example-platform.com/#product",
      "name": "Example Platform",
      "url": "https://example-platform.com/",
      "description": "Change data capture and transformation between operational databases, warehouses and SaaS applications, with column-level lineage and row-level access control.",
      "applicationCategory": "BusinessApplication",
      "applicationSubCategory": "Data integration",
      "operatingSystem": "Any modern web browser; self-hosted deployment on Linux (x86-64, arm64)",
      "softwareVersion": "8.4",
      "releaseNotes": "https://example-platform.com/changelog",
      "softwareRequirements": "Self-hosted deployment requires Kubernetes 1.29-1.33, PostgreSQL 14 or later, and an S3-compatible object store.",
      "countriesSupported": "US, CA, GB, DE, AU, JP",
      "featureList": [
        "SAML 2.0 single sign-on and SCIM 2.0 user provisioning",
        "Two-way Example CRM sync over the Example CRM REST API",
        "Column-level lineage across every configured pipeline",
        "Audit log export to any S3-compatible destination",
        "Customer-managed encryption keys on the Enterprise plan"
      ],
      "softwareHelp": {
        "@type": "CreativeWork",
        "url": "https://docs.example-platform.com/"
      },
      "publisher": { "@id": "https://example-platform.com/#organization" },
      "offers": [
        {
          "@type": "Offer",
          "name": "Team",
          "url": "https://example-platform.com/pricing",
          "price": "45",
          "priceCurrency": "USD",
          "availability": "https://schema.org/InStock",
          "eligibleCustomerType": "https://schema.org/Business",
          "priceSpecification": {
            "@type": "UnitPriceSpecification",
            "price": "45",
            "priceCurrency": "USD",
            "unitText": "named user",
            "referenceQuantity": {
              "@type": "QuantitativeValue",
              "value": 1,
              "unitText": "named user"
            },
            "billingDuration": {
              "@type": "QuantitativeValue",
              "value": 1,
              "unitCode": "MON"
            },
            "valueAddedTaxIncluded": false
          }
        },
        {
          "@type": "Offer",
          "name": "Enterprise",
          "url": "https://example-platform.com/pricing#enterprise",
          "description": "Annual contract from $40,000. Priced per named user with volume tiers at 250, 1,000 and 5,000 seats. Deployment model, support tier and FedRAMP environment access move the figure.",
          "priceCurrency": "USD",
          "availability": "https://schema.org/InStock",
          "eligibleCustomerType": "https://schema.org/Business",
          "priceSpecification": {
            "@type": "UnitPriceSpecification",
            "minPrice": "40000",
            "priceCurrency": "USD",
            "unitText": "annual contract",
            "billingDuration": {
              "@type": "QuantitativeValue",
              "value": 1,
              "unitCode": "ANN"
            },
            "valueAddedTaxIncluded": false
          }
        }
      ]
    },
    {
      "@type": "FAQPage",
      "@id": "https://example-platform.com/faq#faqpage",
      "url": "https://example-platform.com/faq",
      "dateModified": "2026-08-10",
      "about": { "@id": "https://example-platform.com/#product" },
      "publisher": { "@id": "https://example-platform.com/#organization" },
      "mainEntity": [
        {
          "@type": "Question",
          "name": "What does Example Platform cost?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "The Team plan is $45 per named user per month, billed annually. Enterprise contracts start at $40,000 per year, priced per named user with volume tiers at 250, 1,000 and 5,000 seats. Deployment model, support tier and FedRAMP environment access move the figure. Published prices are list prices, exclusive of tax, reviewed each January.",
            "url": "https://example-platform.com/faq#pricing"
          }
        },
        {
          "@type": "Question",
          "name": "Where is customer data stored, and can we choose the region?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "Customer data is stored in the region chosen at provisioning: us-east-1 (Virginia), eu-central-1 (Frankfurt) or ap-southeast-2 (Sydney). Data does not leave the selected region in normal operation. Support access originating outside the region is covered by the standard contractual clauses in the data processing addendum at https://example-platform.com/legal/dpa.",
            "url": "https://example-platform.com/faq#residency"
          }
        },
        {
          "@type": "Question",
          "name": "Can Example Platform be self-hosted?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "Yes, on the Enterprise plan only. Self-hosted deployment runs on Kubernetes 1.29 through 1.33 with PostgreSQL 14 or later and an S3-compatible object store. Self-hosting is not available on the Team plan.",
            "url": "https://example-platform.com/faq#self-hosted"
          }
        },
        {
          "@type": "Question",
          "name": "Is single sign-on included, or is it an add-on?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "SAML 2.0 single sign-on and SCIM 2.0 provisioning are included on both the Team and Enterprise plans at no additional cost. Customer-managed encryption keys and the FedRAMP environment are Enterprise only.",
            "url": "https://example-platform.com/faq#sso"
          }
        }
      ]
    }
  ]
}
</script>

• A per-seat subscription is a UnitPriceSpecification, not a bare price. referenceQuantity says what one unit is, unitText names it in words, and billingDuration carries the period. A lone "price": "45" on a seat-based product will be read as the cost of the product.
• A floor goes in minPrice. That is how you publish "from $40,000 per year" without asserting a fixed figure. If you also want Google's software rich result, note that it wants a plain price on an offer, which the entry-level tier supplies.
• hasCertification is the machine-readable form of your security page. certificationStatus, auditDate and expires together let a consumer establish that the attestation is current rather than merely claimed. Generate these from whatever your compliance team already tracks, and let the property disappear when a certification lapses rather than leaving a stale date live.
• sameAs is entity resolution, so favour profiles you do not control. A Wikidata item, a Crunchbase record, and a public GitHub organisation are corroborating identifiers. Your own three social accounts are not.
• Put version and platform facts in softwareVersion, softwareRequirements and operatingSystem. These are the fields a compatibility question resolves against, and they are almost never populated on B2B sites.
• Do not emit aggregateRating from your own testimonials. A rating aggregated from quotes you selected and published is not a rating, it is a structured data policy violation with a number in it.
• Generate all of this from the source that renders the page. Markup saying $45 above a pricing table saying $52 publishes two conflicting figures under one domain and gives a retrieval system reason to trust neither.

Related reading: implementation patterns for MCP servers and agent-facing APIs, schema markup for the markup mechanics, trust and authority signals for the credibility patterns behind the case-study and certification sections, and measurement before anyone concludes from a traffic chart that the research phase stopped happening.

Example Platform, its competitors, its certifications and every figure in the markup samples are placeholders, written to show the shape of the fields rather than to describe any real product. Nothing here is advice on what your security programme should contain or on what you may contractually publish about pricing; check the second one with whoever holds your customer agreements before you change a pricing page.