B2B ecommerce SEO with gated prices: separate public facts from private offers

Decide which product facts are public

Start with a field list, not the lock app. Ask the commercial owner to classify product identity, specifications, stock information, standard price, negotiated price, quantity breaks, customer discounts, credit terms and documents. Assign one of three meanings: public, available to a defined company after authorization, or internal only. A public list price and a private contract price are different fields even when the current system stores them together.

For each field, record its source, audience, export destinations and approval owner. Avoid labels such as “B2B data” that conceal several rules. A safety data sheet may be public while a customer quote using the same product must remain private. Write the rule for visitors whose account is pending, suspended or no longer assigned to that company.

Use this as an acceptance contract across the storefront and integrations. It is an implementation recommendation, not a statement that your present platform enforces every row. If public product identity itself is confidential, choose a private catalog and accept the discovery limit instead of publishing a thin imitation of it.

Inspect the response, not just the visible price

A page can say “Log in for price” while its response still contains the price. Review the server HTML, rendered DOM, JSON-LD, inline configuration, data attributes, network responses and downloadable files. Include collection cards, quick views, predictive search, comparison tools, print views and alternate language or currency URLs. A theme correction reaches only the surfaces it actually controls.

Trace the product into feeds and integrations separately. Record who exports to Merchant Center, marketplaces, public search indexes or downloadable catalogs. Check whether a feed uses a default customer, a privileged service account or the last saved price. Access to an administrative source must not silently become permission to publish all of its fields.

I recommend capturing the expected field set before inspecting output. Search for the fictional test prices and company identifiers as well as the word “price.” A clean text search is useful evidence for those values; it is not proof that an endpoint cannot reveal a different private field. Ask the developer to review the server authorization rules and shared-cache behavior too.

Keep authorization separate from crawl and index controls

Authentication identifies a visitor; authorization decides whether that visitor can read a particular company’s offer. Google’s guidance recommends password protection for confidential content. The server must prevent an unauthorized response from carrying private terms, even if the caller knows a product or company identifier. Control what you share with Google Search.

Robots.txt is a crawler instruction. It does not require a human or API client to log in, and a blocked URL can still appear in Search. Noindex is a search exclusion rule. It does not stop a person with the URL from reading the response. Google must be able to crawl a resource to see its noindex rule, so blocking the same resource in robots.txt can prevent that rule from being processed. Robots.txt limitations; how Google processes noindex.

Do not send private prices to Googlebot as an exception. Keep the approved public product response useful to both ordinary visitors and crawlers. Have the implementation owner decide how authenticated responses, caches and exports preserve the company boundary. Disabling a button or changing CSS does not provide that boundary.

Choose the search appearance your public data can support

A product can still have useful public facts when it does not qualify for a shopping enhancement. Rich-result eligibility is not guaranteed display. Treat a missing-price warning as a scope decision: either you have a real permitted public offer, or that offer-based appearance is unsuitable for this page. Do not put zero in an Offer to mean “ask for price.” Zero describes a price, not an authorization rule.

Merchant Center permits free, straightforward account signup under its stated conditions, but the submitted price must be purchasable by any user in the target country. That does not make a negotiated Company A price a general offer. Keep regional rules, approved member pricing and your actual sales restrictions in the channel review.

Give the buyer enough public information to choose the next step

A public product page should help a buyer establish fit before they request access. Include approved identifiers, dimensions with units, material, compatibility, pack quantity, supported applications and genuine limitations. Link relevant public documentation. Explain what account approval changes: for example, access to company pricing and ordering. Do not imply instant approval when a sales team must review an application.

Keep confidential drawings and customer-specific documents out of the public asset folder. A document link hidden from a page is still a public link if the file server serves it anonymously. Give private downloads the same access review as the price response. Include PDF text and metadata in that review, not just the filename.

If the commercial team requires a completely private assortment, maintain an approved public capability or category explanation only where it helps visitors. Do not publish private product names to create search pages. This choice belongs to the business owner; SEO cannot decide that disclosure is acceptable.

Run a three-actor acceptance check

1. Prepare controlled inputs. Use a representative product, two authorized companies with deliberately different fictional prices, an anonymous session and the exact URL/endpoint/export inventory. Record theme/app versions and the owner of each output.
2. Check anonymous reads first. Open the product and its alternate surfaces without an existing session. Save response and rendered evidence in an access-controlled work folder. Do not paste real terms into public validators or support forums.
3. Check both company boundaries. Company A must not receive B’s price, or the reverse. Revisit the product after switching accounts and after logging out. Have the developer inspect whether a shared cache can reuse an authenticated response for another actor.
4. Check direct reads. Test the documented APIs and files with appropriate approved test access. A missing link does not excuse an endpoint that returns unauthorized data. Include expired or revoked membership.
5. Check publication outputs. Inspect fresh HTML, markup, generated feeds and downloaded documents after the change. Mark each case pass, fail or not yet checked, with evidence and an owner.
6. Release only the accepted scope. Keep public content discoverable where intended. Recheck representative surfaces after theme, lock-app, feed or search-service changes.

This is a test plan for your implementation team, not a claim that the examples below were run against a store. A failed boundary blocks release of that surface. Do not treat eighteen clean screenshots as a substitute for server authorization review.

Trace the leak or search loss to its owner

If private information is already public, first remove or protect the source and all affected URL variants. Review Google’s removal process for the appropriate temporary and lasting actions. A Search removal request is not a fix for a still-public API or feed. Keep evidence of the correction and monitor the affected URLs; do not promise a fixed recrawl or price-removal deadline.

Hand off a field contract, not a request to “hide prices”

The useful deliverable is a short table of fields, audiences, outputs, expected responses and acceptance evidence. Attach the outstanding cases and name the owner of storefront, feeds, search, documents and caching. Keep source evidence containing real company terms private.

I would choose a public technical catalog with authorized offers when discovery matters and product facts are publishable. I would choose a fully private catalog when assortment disclosure is itself restricted. If an app covers only the visible storefront, scope the missing endpoints and exports before purchasing more tools. The cost depends on the actual surfaces and responsibilities, not the number of hidden price labels.