A wholesale shop shows its prices only after login, and for good reason: customer prices, tiers and framework terms do not belong on a public page. It becomes a problem when the whole product page disappears behind the login together with the price. The search engine then sees nothing but a login form, and anyone searching for an item number, a standard or a use case may end up with another supplier. This article shows how to combine both: public product pages that can be found, and a price field that reveals nothing until the account is approved. It explains what the Eurostat figures say about web sales in wholesale, what Google documents about login barriers and structured data, why paywall markup is no way out and how the German Price Indication Ordinance (PAngV) applies to pure B2B shops. The wider context for merchants selling to business customers is covered on our page on B2B e-commerce for wholesalers.
The dilemma: price protected, product invisible
Login prices in wholesale have solid reasons. One business customer receives terms that another does not: discounts from framework agreements, tiered prices by order quantity, special prices for projects. These prices live in the ERP system, are applied per customer group or per customer and should end up neither with competitors nor with other customers. On top of that, a list price without context says little about the price a particular customer actually pays. The obvious technical solution is a login requirement. It can, however, be drawn wider than necessary: instead of locking only the price field, the shop redirects every visitor who is not logged in from the product page to the login form. For the customer with an account, that changes little. For everyone else, and for every search engine, the product range has simply disappeared.
So there are two designs that look similar from the outside and differ fundamentally for search. In the first, the entire product page sits behind the login. In the second, the product page is public, with title, item number, attributes, images and data sheets, and only the price field requires a login. This article describes the second design and how to get there. How the customer prices themselves get from the ERP system into the shop is covered in our article on customer-specific and tiered prices from the ERP; here the focus is on the public page in front of them, meaning what a prospect and a search engine get to see before any account is involved.
If a page is made private, such as requiring a log-in to view it, Googlebot will not crawl it.
Google Search Central, Google Search Technical Requirements
In plain terms: if a page can only be seen after logging in, Googlebot does not crawl it (Google Search Central). What is not crawled cannot be evaluated by the search engine either, neither the product name nor the attributes nor the item number. At most, the login page appears in the search results, and it is the same page for every query. This hits precisely the queries with a clear intent to buy: anyone who types a manufacturer part number, a standard designation or an exact dimension into a search box usually knows what they need and is looking for a supplier. If they cannot find the page, they may well order where the page is public. In this design, protecting the terms costs visibility that it would not have to cost.
What the figures say about web sales in wholesale
The size of the field is shown by the European survey on ICT usage in enterprises. In 2024, 33.80% of German wholesale enterprises with 10 or more employees sold to other businesses or to public bodies via websites, apps or marketplaces (Eurostat), roughly one third. Web sales of any kind, to whichever customer group, were reported by 37.58% of these enterprises (Eurostat), and 32.75% sold via their own website or their own app (Eurostat). Wholesale here means division 46 of the NACE Rev. 2 classification excluding trade in motor vehicles. The count covers enterprises with 10 or more employees including self-employed persons; micro-enterprises with fewer than ten employees are not covered by the survey. The values come from the 2025 survey, which asks about sales in the previous year.
For the question of login prices, the turnover side is more revealing. Of the turnover that German wholesalers with 10 or more employees generated via the web in 2024, 80.78% came from business customers and public bodies (Eurostat), roughly four fifths. 86.97% of this web turnover went through their own website or app, the rest through marketplaces (Eurostat). Measured against the total turnover of the enterprises, web sales accounted for just over one tenth, exactly 10.88% (Eurostat). In wholesale, the own shop is therefore the main channel of web business, and this web business is predominantly business with business customers. Where a shop puts prices behind a login, this affects exactly the customer group that carries most of this turnover.
| Indicator | Wholesale Germany | Wholesale EU-27 | All covered economic sectors Germany |
|---|---|---|---|
| Share of enterprises with web sales to businesses and public bodies | 33.80% | 28.50% | 13.96% |
| Share of businesses and public bodies in web turnover | 80.78% | not analyzed here | 41.95% |
The comparison puts the values in context. On EU average, 28.50% of wholesale enterprises with 10 or more employees sold via the web to businesses and public bodies in 2024 (Eurostat), and German wholesale is above that at 33.80% (Eurostat). Across all economic sectors covered by the Eurostat survey in Germany, the figure was 13.96% of enterprises with 10 or more employees (Eurostat), and there 41.95% of web turnover came from business customers and public bodies (Eurostat). For this last value, the reference is web turnover, not the number of enterprises. The survey does not cover the whole economy: the financial sector, public administration, education, human health and social work as well as arts and entertainment are missing. The gap to wholesale remains clear nonetheless: web sales to business customers are not a side issue there.
The Eurostat values describe web sales as a whole, not shops with login prices. There is no figure for the share of wholesale shops that show prices only behind a login. Electronic data interchange must also be kept separate: 44.90% of German wholesalers with 10 or more employees had e-commerce sales via web and EDI together in 2024 (Eurostat), and web and EDI together brought in 25.52% of their total turnover (Eurostat), roughly one quarter. EDI orders run from system to system and do not reach any search engine. For the question of what a shop can gain through search, the web share is what counts, not the sum of both channels.
What Googlebot sees behind a login
From the search engine's point of view, a product page behind a login is not a product page but a redirect or a login form. If the shop redirects visitors who are not logged in to the login page, the crawler follows the redirect and finds the same content there for every product address. If the shop shows the login form directly under the product address, the crawler does see a separate address per item, but no content that distinguishes one from another. In both cases, what Google states in its technical requirements applies: private pages, for example those that require a login, are not crawled (Google Search Central). Internal links, sitemaps or category pages do not change this as long as the target page itself only responds to logged-in customers.
The situation is different if only the price field is locked. Then the product address responds to every visitor with the complete page: title, item number, manufacturer part number, description, attributes, images and documents. In place of the price there is a note such as "Price after login" with a login button and a path to registration. The crawler can fetch and evaluate the page, and a search result can show title and description, just without a price. Whether and where the page appears is decided by the search engine; a basic prerequisite for being considered at all, however, is in place with the public page.
| Aspect | Entire product page behind the login | Only the price behind the login |
|---|---|---|
| Page can be fetched by the crawler | No, only a login form or a redirect | Yes, complete page without price |
| Search for item number or standard | Does not find the product page | Can find the product page |
| Product snippet without price | Not possible | Only with genuine, visible reviews, not promised |
| Merchant listing in search | Not possible | Not possible, because no price is visible |
| Customer prices and tiers | Protected | Protected |
| Generative search and chat assistants | Usually do not see the product page | Can fetch product data, no price |
What stays public and what belongs behind the login
The dividing line runs between product knowledge and terms. Product knowledge is everything that describes an item and is the same for every prospect: designation, item number, manufacturer and manufacturer part number, technical attributes, standards and approvals, dimensions, packaging unit, images, data sheets and safety data sheets. Terms are everything that depends on the customer: their price, their tier, their discount, their payment terms, their order history. Product knowledge belongs on the public page, terms behind the login. The quality of the public part determines how well the page matches search queries. If the product data lives in a PIM, it pays to maintain the attributes cleanly there and transfer them completely to the shop; how this works technically is described on our page on connecting PIM systems.
Designation and numbers
Product name, item number and manufacturer part number appear publicly in the title and in the text, so that searches for exactly these terms can reach the page.
Attributes as text
Material, dimensions, standards and area of use as readable text and as a table, not only as an image or as a filter value in the listing.
Images and data sheets
Product images with alternative text and data sheets as linked files that can be accessed without logging in.
Category and brand pages
Entry pages per product group and manufacturer with their own text, linking to the public product pages.
Customer price and tiers
The price per customer or customer group, quantity tiers and discounts appear only after login.
Terms and history
Payment terms, framework agreements, order history and quick order remain in the customer account.
In between lies a gray area that each shop decides for itself. Availability, for example, can appear publicly as a status, such as in stock or on request, while the exact stock level per location remains reserved for the customer. Minimum order quantities and packaging units are product knowledge and help assess whether an item fits even before login. Showing a manufacturer's recommended retail price publicly is a business decision with consequences for markup and price indications and should not be made in passing. Above all, the boundary should be defined in one place in the template and not anew in every component. Otherwise a price that is cleanly hidden in the price field turns up again in the cart widget, in the source code or in a product recommendation.
Anyone who types an item number into a search box is usually looking for exactly this item. The number should therefore appear in the page title or directly below it, together with common spellings of the manufacturer part number, for example with and without a hyphen. Variants with their own number need their own reachable address, or at least a mention on the main page, so that a search for the variant number also leads to a public page.
Structured data without a price: what works and what does not
Structured data describes to the search engine what is on a page. The central rule is simple: only what visitors to the page can actually see gets marked up (Google Search Central). For login prices, this means that a price that visitors who are not logged in cannot see must not appear in the markup of the public page either, neither as an offers entry with an amount nor hidden in a meta element. This is not a formality: markup that contains more than the visible page contradicts the guidelines for structured data. An overview of the markup types that are relevant for shops is given in our article on structured data with schema.org in online shops.
What remains without a price? For a product snippet, Google requires only one of the three properties review, aggregateRating or offers (Google Search Central). Without a price, this means that a product snippet is only an option if the shop has genuine reviews that are visible on the page and marks them up. Invented or purchased stars are not an option. Merchant listings, meaning entries with purchase information, on the other hand require a price greater than zero, unlike product snippets (Google Search Central), and Google advises checking that the page is not blocked by robots.txt, noindex or a login requirement (Google Search Central). For pure login prices, merchant listings are therefore out of reach. And even correct markup does not necessarily lead to a display: Google does not promise that structured data will appear in the search results (Google Search Central).
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Product name as shown on the page",
"sku": "ITEM-NUMBER",
"mpn": "MANUFACTURER-PART-NUMBER",
"brand": { "@type": "Brand", "name": "Manufacturer name" },
"description": "Description as visible on the page",
"image": "https://shop.example.invalid/media/product.jpg",
"additionalProperty": [
{ "@type": "PropertyValue", "name": "Material", "value": "as on the page" },
{ "@type": "PropertyValue", "name": "Standard", "value": "as on the page" }
]
}The example contains no offers entry and therefore no price. It describes the product with the same information that appears on the page: name, item number, manufacturer part number, brand, description, image and attributes. The values come from the same data fields as the visible text, so that page and markup do not drift apart. Whether this can lead to an enhanced display in the search results depends on whether genuine reviews are also marked up; without them, the markup remains a clean description that helps the search engine classify the page. After login, the page may show the customer price. What matters for search is the public version alone: it carries no price in the markup that is not also visible.
Prices that visitors cannot see without logging in; placeholder prices such as zero or one cent just to make an entry valid; a list price that appears nowhere on the page; reviews or stars that do not exist. Each of these tells the search engine something different from what the visitor sees.
Why paywall markup is no way out
Anyone looking for a way to get login content indexed anyway comes across Google's markup for subscription and registration content. It is intended for content that is only accessible with a subscription or registration and should still be indexed, and it is meant to distinguish such barriers from cloaking (Google Search Central). The decisive point is in the list of supported types: the markup applies to CreativeWork and subtypes such as Article, NewsArticle, Blog or WebPage (Google Search Central). Product is not among them. For product pages with login prices, this markup is therefore not an intended route, and anyone who uses it anyway describes the page with a type that does not fit. It does not change the basic rule either: what the search engine gets to see should match what a visitor sees.
One variant seems obvious: the shop recognizes Googlebot by its user agent and serves it the page including the price, while visitors without a login see the form. Google describes cloaking as presenting different content to users and search engines with the intent to manipulate search rankings and mislead users, and gives as an example text that is inserted only when a search engine requests the page (Google Search Central). According to Google, distinguishing subscription and registration barriers from it is precisely the purpose of the paywall markup (Google Search Central). Anyone who shows the crawler prices that visitors cannot see therefore risks violating the spam policies and, as a side effect, exposes their customer prices to anyone who makes their browser pose as Googlebot.
Registration instead of price: the price field as an entry point
When the price is missing, the price field takes on a different task: it leads to login or to registration. A well-built price field states clearly why no price is shown, offers a login button for existing customers and a second path for prospects who do not have an account yet. Next to it is the information that helps even before login: packaging unit, minimum quantity, delivery status. After login, the customer should land on the same product page, not on the home page, and see their price there right away. How a registration for business customers with a check of the business can be set up is described in our article on B2B customer onboarding with business verification.
- Application: company name, address, contact person and VAT identification number or proof of trade, with as few mandatory fields as possible.
- Review: the details are checked by the sales team or automatically against existing customer master data; in case of doubt, a query instead of a silent rejection.
- Assignment: the new account receives a customer group and, where available, the customer number from the ERP system, so that the correct prices apply.
- Approval: only after approval does the customer see prices; until then, the price field shows the status "Account under review".
- Confirmation: an email confirmation with a link to the product page viewed last, so that the entry point is not lost.
There is a technical trap in the cache. Public product pages should be delivered quickly and are therefore cached. But if the cached version already contains a customer price, the next visitor may see another customer's price. A clean separation is achieved when the public version without a price sits in the cache and the price for logged-in customers is loaded separately, or when the cache distinguishes by customer group. Which variant fits depends on the number of customer groups and on the load. For shops on their own infrastructure, this question is part of setting up Shopware hosting, together with the question of how the cache is cleared after a price change from the ERP system.
Price Indication Ordinance: context for pure B2B shops
Besides search, login prices raise a legal question: does a shop not have to show prices openly? The German Price Indication Ordinance governs the indication of prices for goods or services by traders to consumers (§ 1(1) PAngV). Who counts as a trader and who as a consumer is defined by the ordinance itself. For the trader, it refers to the Act against Unfair Competition and not to the German Civil Code (§ 2 no. 8 PAngV), for the consumer to the German Civil Code (§ 2 no. 9 PAngV). According to it, a consumer is any natural person who enters into a legal transaction for purposes that predominantly cannot be attributed to either their commercial or their independent professional activity (§ 13 BGB).
For a shop that is aimed exclusively at business customers and only approves verified companies, the ordinance usually does not apply, because its scope targets price indications to consumers (§ 1(1) PAngV). Things may look different if the clientele is mixed, if consumers can also register or if the shop is recognisably aimed at private customers as well. In that case, which obligations apply must be checked in the individual case, and that check belongs in the hands of legal counsel. From a technical point of view, a clear orientation helps: a prominent note that the offer is aimed at trade customers, a registration with verification and no price display for accounts that have not been verified. This does not replace a legal assessment, but it makes the orientation of the shop traceable.
This section places the wording of the provisions mentioned in context and does not replace legal advice. Whether and which price indication obligations apply to a specific shop depends on clientele, registration and presentation and must be checked in the individual case. The provisions are reproduced in the version that applied when this article was written.
Implementation in Shopware 6
In Shopware 6, the separation of product page and price can be implemented via customer groups, rules and an adapted template for the buy box. Visitors who are not logged in get the complete product page with the note in the price field, logged-in customers see their price from the customer group or from the ERP connection. We build such B2B functions individually for each shop, aligned with customer groups, pricing logic and ERP; an overview is given on our page on B2B e-commerce. It is important not to hide only the visible price line. The markup in the source code, variant and tier displays, product recommendations, listing pages and search suggestions can also contain prices and must follow the same rule.
After every major update, a second look is worthwhile, because templates and the output of structured data can change. If you are planning an update right now, our article on preparing the upgrade to Shopware 6.8 covers the steps before it; checking the price and markup output belongs on the list afterwards. The following commands show how to check this from the command line without logging in. The address is a placeholder and is replaced by a real product address of your own shop.
The first two commands count price information in the source code of the public version, once as microdata, once as a price field in JSON-LD. Both should return zero as long as the visitor is not logged in. The third compares the response for a request with a crawler user agent with the response for an ordinary visitor. With dynamic parts such as security tokens or timestamps, the comparison shows small differences; what matters is that the crawler receives no price and no additional content. Such checks belong in ongoing support, so that an update or a new extension does not silently undo the separation; this is part of our Shopware maintenance.
Generative search and chat assistants usually only see what is public
What applies to classic search applies equally to generative search systems and chat assistants: they can only process what they can fetch. As a rule, they cannot fetch a product page behind a login, while a public product page with clean attributes can appear in answers when someone asks for a suitable item. How content can be prepared for such systems is described on our page on Generative Engine Optimization. Conversely, the lock also applies to your own assistant: a public chatbot on the shop must not reveal login prices just because they are in its knowledge base. How to keep the knowledge of such an assistant current and cleanly separated is shown in our article on knowledge maintenance for the shop chatbot.
Roadmap: five steps to a public product page
- Take stock: which product, category and brand addresses respond without login with the complete page, and which redirect to the login form? A crawl without login shows the picture that the search engine has as well.
- Separate page and price: the template delivers the product page publicly and locks only the price field, tiers and cart; the rule lives in one single place.
- Clean up the markup: no price in microdata or JSON-LD of the public version, a product description with item number, brand and attributes, reviews only if they are genuine and visible.
- Build the registration: a price field with login and application, review, assignment to a customer group and return to the product page after login.
- Measure instead of hope: monitor coverage and search queries in Search Console and repeat the check commands from above regularly; this does not promise any ranking, but it makes the foundation measurable.
A good starting point is a look from the outside: our shop check shows technical findings on speed, search engine optimization and accessibility, and the question of which pages can be reached without login can be added to it. For ongoing work on visibility, structure and content, we offer search engine optimization for shops. One more note on the figures: Eurostat plans the next update of its Statistics Explained article on e-commerce statistics for enterprises for February 2027 (Eurostat). The database from which the values in this article are taken can be updated independently of this; the values given here refer to the calendar year 2024.
How we work at XICTRON
We build wholesale shops on Shopware 6 Community Edition and connect them to the existing ERP system, such as SAP Business One or Microsoft Dynamics. For login prices, we start with an inventory of the public pages and the markup, then separate product page and price field in the template, set up registration and approval, and check after every change that no price slips into the public version. The B2B functions are built individually for each shop, not as a ready-made package, because customer groups, pricing logic and approval processes differ from merchant to merchant. Whether a new shop is built or an existing one is rebuilt is described on our page on online shop development; for an initial conversation, you can reach us via the contact form.
This article draws on the database of the European survey on ICT usage in enterprises by Eurostat (datasets isoc_ec_eseln2 and isoc_ec_evaln2, data for the calendar year 2024, enterprises with 10 or more employees), on the Eurostat Statistics Explained article on e-commerce statistics for enterprises, on the Google Search Central documentation on the technical requirements of Google Search, product snippets, merchant listings, the general structured data guidelines and the markup for subscription and registration content, and on the wording of § 1 and § 2 of the German Price Indication Ordinance and § 13 of the German Civil Code (BGB). All shares refer to the population stated in the source.
That depends on what sits behind the login. If the entire product page can only be seen after logging in, Googlebot does not crawl it (Google Search Central). If the page is public and only the price field is locked, the search engine can evaluate title, item number and attributes. There is no promise of indexing or ranking in either case.
No. Only what visitors to the page can see gets marked up (Google Search Central). A price that is not visible without logging in does not belong in the structured data of the public page. If the shop serves the crawler prices that visitors cannot see without logging in, Google may treat this as cloaking; the markup for subscription and registration content does not cover product pages.
It is possible if the shop has genuine reviews that are visible on the page. For a product snippet, one of the properties review, aggregateRating or offers is enough (Google Search Central). Google does not promise a display even with correct markup (Google Search Central).
Merchant listings require a price greater than zero (Google Search Central), and the page must not be blocked by a login requirement (Google Search Central). With pure login prices, this listing is therefore out of reach.
The ordinance governs price indications by traders to consumers (§ 1(1) PAngV). A shop that is aimed exclusively at verified business customers usually does not fall under it. With a mixed clientele or a registration that is also open to consumers, this must be checked in the individual case, ideally with legal advice.
In 2024, 33.80% of German wholesale enterprises with 10 or more employees sold via the web to businesses and public bodies (Eurostat). Of their web turnover, 80.78% came from business customers and public bodies (Eurostat). The values apply to web sales as a whole, not specifically to shops with login prices.