Since July 7, 2026, Google's documentation on merchant listing markup has described how stores can provide the Product.category property both as text and as a CategoryCode (Google Search Central). This means the store's own category and the Google product category can now sit directly in the schema.org markup of the product page, in line with the feed attributes product_type and google_product_category. The real work comes before that: every new item needs a store category, a matching category from the Google product taxonomy and often a marketplace category as well. This article shows how AI can take over this assignment against fixed lists, how a confidence threshold routes uncertain cases into a review queue and how the result then reaches the feed and the markup. Technically, we implement this with our AI-based category automation.
What Google added on July 7, 2026
In the Google Search Central changelog, the entry for July 7, 2026 reads “Added category to merchant listing structured data” (Google Search Central). Google's stated reason is that merchants should be able to place both their own and Google-defined category information in their schema.org markup. The changelog explicitly refers to the Google Merchant Center feed attributes product_type and google_product_category (Google Search Central).
Updated the Merchant listing documentation to detail how the Product.category property can be used with both Text and CategoryCode types.
Google Search Central, Documentation updates, entry of July 7, 2026
What this means for the markup is spelled out in the merchant listing documentation itself. There, category is listed among the recommended properties, not the required ones, and it accepts a list of values in which plain strings and CategoryCode objects may be mixed (Google Search Central). A text value stands for the store's own product category and corresponds to the feed attribute product_type; Google recommends keeping such values under the 750-character limit (Google Search Central). For the Google product category, the CategoryCode type is used: inCodeSet points to a Google product taxonomy file, and codeValue holds the numeric ID or the full path. Multiple values are explicitly allowed.
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Example Brand Leather Hiking Boot",
"image": "https://shop.example/media/hiking-boot-leather.jpg",
"gtin13": "9520123456788",
"category": [
{
"@type": "CategoryCode",
"inCodeSet": "https://www.google.com/basepages/producttype/taxonomy-with-ids.en-US.txt",
"codeValue": "187"
},
"Men > Hiking Boots"
],
"offers": {
"@type": "Offer",
"price": "149.00",
"priceCurrency": "EUR",
"availability": "https://schema.org/InStock"
}
} Schema.org itself defines the property broadly: category is a category for the item, and greater-than signs or slashes may indicate a hierarchy (schema.org). The usage figures on schema.org show how new the code form still is for many websites: the category property is in use on 1 to 10 million domains, the CategoryCode type on 1,000 to 10,000 domains, each based on a monthly analysis of Google's index as of August 2026 (schema.org). The property is common, while the CategoryCode type is still rare.
Merchant listing markup without category remains valid. The property adds to the required fields, and Google decides how it uses it in its results. For the European Economic Area, Google also describes separate units for comparison shopping services and direct suppliers (Google Search Central). What the changed results page means for your planning is covered in our article on free product listings in the EEA.
Three category systems with three jobs
In the day-to-day running of a store, at least three category systems operate side by side. The store category reflects the navigation. In Shopware 6, categories are also used to organize store pages and the service menu and to create landing pages (Shopware documentation). A category there is filled either manually or through a dynamic product group (Shopware documentation). The Google product category, by contrast, comes from a fixed taxonomy defined by Google. Marketplaces, finally, maintain their own category trees, often with their own required attributes.
The Google product taxonomy is more manageable than its reputation suggests. The downloadable file carries the version label 2021-09-21 and contains 5,595 categories, 21 of them at the top level; the deepest path spans seven levels (Google product taxonomy, own count). The German and English versions use the same numeric IDs, only the names are translated (Google product taxonomy, own check). For assignment work, this is an advantage: anyone working with the ID is independent of the language. Google itself advises using the English values or the numeric ID if the taxonomy is not available in your language (Merchant Center Help).
| Attribute | Store category (product_type, text) | Google product category (CategoryCode) | Marketplace category |
|---|---|---|---|
| Who defines the list? | the store itself | Google, as a fixed taxonomy | the respective marketplace |
| Purpose | navigation, filters, internal reporting | categorization at Google, product groups in Shopping campaigns | categorization on the marketplace, required attributes |
| Value in the feed | product_type, up to five values | google_product_category, ID or path | ID of the respective marketplace |
| Value in the markup | category as text | category as CategoryCode | not provided for |
| Changes | with every rework of the store tree | rarely, file at version 2021-09-21 | as specified by the marketplace |
For the feed attribute product_type, Google accepts up to five values, but only the first is used for bidding and reporting in Shopping campaigns (Merchant Center Help). If you want to settle ownership of the taxonomy in principle, the strategic side is covered in our article on PIM strategy and product data sovereignty. This article is about the next step: assigning individual items to these lists. For marketplaces, the handover runs through suitable marketplace integrations.
What Google assigns on its own
A common assumption is that a product will not show up properly at Google without google_product_category. The Merchant Center Help describes it differently: all products are automatically assigned a category from Google's product taxonomy, and the attribute serves to override this automatic categorization in specific cases (Merchant Center Help). The same page lists it as optional for each product. The help page on product_type, on the other hand, calls the Google product category required for system-wide categorization (Merchant Center Help). Both statements fit together if read this way: in the end, every product has a Google category, but Google assigns it itself if the store does not provide one.
According to the help page, Google only accepts your own value in three cases (Merchant Center Help):
- Category-specific requirements: If Google incorrectly assigns an item to a category with additional required fields, such as apparel, mobile phones or software, your own value overrides this assignment and removes the extra requirements.
- Campaign structure: If you build Google Ads campaigns around Google product categories, you can use the attribute to reassign items within that structure.
- Alcohol: Alcoholic beverages must be categorized correctly; an incorrect automatic assignment can be overridden here.
For stores in Germany, the second case matters most. Germany is one of the countries where product groups in Shopping campaigns can be organized by Google product category (Merchant Center Help). If you structure your campaigns this way, you need a stable and traceable assignment that does not shift with every automatic recategorization. How campaigns and budgets are currently changing is described in our article on channel prioritization in Google Ads; the basics of a well-maintained feed are covered in the guide to the Google Shopping feed.
According to the help page, Google accepts any version of the categories published after August 2011 and translates it to the latest version. What the store submits may then no longer match what it finds in Merchant Center (Merchant Center Help). Assigning against the current taxonomy file avoids this mismatch.
Why manual assignment does not scale
Small, stable catalogs can be categorized by hand; with supplier imports, seasonal goods and new channels, that no longer works. Each new item then needs not one but several decisions, each against a different tree. In practice, the store category is usually set carefully, because otherwise the item cannot be found in the store. The Google category, on the other hand, often remains empty or comes from a blanket rule per supplier.
On top of that, the trees do not line up. An example from the Google taxonomy: for shoes, there is category 187, Apparel & Accessories > Shoes, with no further subcategories (Google product taxonomy, own check). A hiking boot therefore belongs there, even if the store lists it under outdoor. The obvious mix-up lies elsewhere: category 1013, Sporting Goods > Outdoor Recreation > Camping & Hiking, sounds right but collects equipment such as hiking poles (Google product taxonomy). A rule that looks for the word hiking assigns the boot to the wrong place.
Artificial intelligence has arrived in many companies, though not in all of them. In 2025, 26% of companies in Germany with ten or more employees used artificial intelligence technologies (Destatis). In the EU, the share was 19.95% of enterprises with at least ten employees (Eurostat). Of the German companies that use AI, 52% use text mining, meaning the analysis of written language (Destatis). This is exactly the technique behind category assignment: where an item belongs is derived from its title, description and attributes.
In retail, the focus is on selling: of the EU retail trade enterprises that use AI, 48.18% used it for marketing or sales in 2025 (Eurostat). Enterprises that considered AI but did not adopt it most often cite a lack of relevant expertise; in the EU, 70.89% of these enterprises said so (Eurostat). For category assignment, this suggests that a clean setup deserves more attention than the choice of model.
Assign, don't invent: AI against fixed lists
The most important principle sounds unspectacular: the AI should not write, it should select. For product copy, free generation is the goal; for categories, it would be a mistake. A category that does not exist in the store tree or in the Google taxonomy is worthless, however plausible it sounds. A robust assignment therefore works against closed lists: the store tree with its IDs, Google's taxonomy file and the marketplace's category tree are the only valid answers.
Technically, several paths lead there. A classifier trained on the store's already assigned items returns a score per category. A language model can choose from a pre-filtered list of candidates, for example the most similar entries in a tree. In both cases, a simple check afterwards verifies that the returned ID exists in the list. Anything that does not is discarded and goes to review. How the enrichment of attributes and copy is structured as a whole is described in our article on AI data enrichment for product data.
Inputs
Title, description, attributes, brand, supplier category and, where available, image features.
Candidates
A shortlist from each target tree, for example based on text similarity. It keeps the choice small and the answer verifiable.
Validation
Every proposed ID is checked against the current list. Unknown or outdated values drop out.
Audit trail
For every decision, the score, model version and time are stored. This keeps it traceable why an item sits in a given category.
{
"sku": "EB-HB-1001",
"targets": {
"store_category": { "id": "men-hiking-boots", "confidence": 0.94, "status": "applied" },
"google_product_category": { "id": "187", "confidence": 0.81, "status": "applied" },
"marketplace_category": { "id": null, "confidence": 0.58, "status": "review" }
},
"threshold": 0.75,
"model": "category-classifier-2026-10",
"checked_at": "2026-11-01T08:15:00+01:00"
} Confidence threshold and review queue
Every automatic assignment returns, alongside the category, a score for how confident the model is. This number is useful, but it is not automatically a probability. A study presented at the ICML 2017 conference shows that modern neural networks, unlike models from a decade ago, are poorly calibrated: their confidence does not match their actual hit rate (Guo et al. 2017). The same paper describes a simple remedy, temperature scaling, which calibrates surprisingly well on most of the datasets studied (Guo et al. 2017).
For a store, this leads to a practical rule: the threshold is not estimated but measured on your own data. If a proposal falls below that, a person decides. In research, this approach is called selective classification: the model may reject cases and thereby trades coverage for error rate (Geifman/El-Yaniv 2017).
An example from image recognition shows how large this trade-off can be. For the ImageNet dataset, the authors report a top-5 error of 2% with a probability of 99.9%, at a coverage of almost 60% of the test cases (Geifman/El-Yaniv 2017). A top-5 error means that the correct class was not among the model's five most likely proposals; the method rejected the remaining test cases. Applied to categories: a strict threshold lowers errors considerably but sends a larger share of items to review. Where the balance lies depends on the catalog and can only be determined on your own inventory.
- Set aside a sample of items with verified assignments that the model has not seen before.
- Measure each target separately: store category, Google category and marketplace differ in the number and distinctness of their categories.
- Choose the threshold so that the error rate above it matches the risk. A wrong Google category for alcohol weighs more than a fuzzy subcategory in the store.
- Count the volume below the threshold: it is the work the review queue carries day after day.
- Measure again after every major change to the catalog or the model.
Every decision a person makes in the queue is a new, correctly assigned example. Collecting these decisions and feeding them back into training improves the assignment exactly where it was least certain. In our category automation, products below a defined confidence threshold are flagged for manual review, and the system learns from the corrections.
Three targets in one run
A joint run for all three targets has one advantage: the three answers can be checked against each other. If an item sits under hiking boots in the store but the model proposes Camping & Hiking for Google, something does not fit. Such a contradiction is a good reason to send a case to review even above the threshold.
| Target | Proposal | Confidence (example value) | Result |
|---|---|---|---|
| Store category | Men > Hiking Boots | 0.94 | applied |
| Google product category | 187, Apparel & Accessories > Shoes | 0.81 | applied |
| Marketplace category | two similar categories in the marketplace tree | 0.58 | review queue |
| Cross-check | store and Google match | not applicable | no contradiction |
The threshold in this example is 0.75; all values are example values, not measurements. The store and Google categories are applied, the marketplace category waits for a decision. For the store, this has a pleasant side effect: the item can already go live while the handover to the marketplace is still open.
Output: feed and markup from one source
An assignment that only lives in a spreadsheet helps no one. It has to arrive in three places: in the store as a category assignment, in the product feed as product_type and google_product_category, and in the JSON-LD of the product page as category. What matters is that all three are fed from the same source. If feed and markup drift apart, Google sees two different categorizations for the same item.
In practice, the assignment is stored as a field on the product, in the PIM or in the store itself. The feed export reads this field, and the product page template writes the same value into the markup. In a Shopware implementation, this belongs in the feed export and in the product detail page template. We set up the handover to Google and the mapping to the Google taxonomy through our Google Merchant Center integration.
- Mark up product pages only: Google recommends adding the markup to product pages, not to pages that list products or a category of products (Google Search Central).
- One category per item at Google: Google advises choosing the one category that describes the item most accurately and basing the choice on its main function (Merchant Center Help).
- As specific as possible: According to Google, the most specific matching category is preferable to a general one (Merchant Center Help).
- Sets and bundles: If a bundle contains a main product, the category of that main product applies (Merchant Center Help).
If the Google path is passed in codeValue instead of the ID, Google requires the > character as the separator between levels, and each level must contain at least one letter (Google Search Central). Store paths that use slashes or pipes must be rewritten before output.
Checking that the assignment arrives
After rollout, checks happen in three places. The Rich Results Test shows for individual pages whether the markup is being read. Search Console has two reports for Product markup, one for merchant listings and one for product snippets; both report errors and warnings (Google Search Central). Finally, Merchant Center shows which category Google actually assigns to the item.
Add a sample on top: each week, review a few randomly selected, automatically assigned items by hand. If the error rate in the sample rises, that is an early sign that the catalog or the supplier data has changed. The basics of structured data are covered in our article on structured data for online stores, which was published before the July change. How markup and categories contribute to a store's overall visibility is part of our search engine optimization work.
- Every ID in the feed exists in the current taxonomy file.
- Feed and JSON-LD carry the same Google category for the same item.
- The Search Console reports for Product markup show no new errors.
- The threshold was measured again after the last catalog change.
Common mistakes in AI assignment
- Allowing free answers: The model invents a plausible category that does not exist in the target tree.
- Secondary function instead of main function: Google gives the example of an MP3 player with a clock that should still be categorized as an MP3 player (Merchant Center Help).
- Accessory as main product: According to Google, a charger for an MP3 player belongs in the category for MP3 player accessories, not in general electronics (Merchant Center Help).
- Assigned too broadly: A top-level category such as electronics is formally correct but gives away the more precise categorization that Google explicitly recommends (Merchant Center Help).
- One threshold for everything: A score that works for the store category can be too lax for a more finely divided marketplace tree.
- No feedback loop: Decisions from the review queue are lost instead of improving the model.
How we implement category assignment
Category assignment is part of our AI data enrichment. There, we assign products to store categories, Google product categories and marketplace taxonomies, with confidence scores and approval workflows for uncertain cases. We write the results back to the connected system instead of building a second data store. For connecting PIM systems such as Akeneo or Pimcore, we use their interfaces; for Shopware 6, a connection through the Admin API or as an app.
- Inventory: We review the store tree, feed, markup and marketplace channels and record which targets are maintained and how.
- Target schema and lists: The store tree, Google taxonomy and marketplace trees are stored as closed lists.
- Training and testing: The model learns from your existing assignments; on a sample, we measure the hit rate and set the threshold per target.
- Operation: New items are assigned on import, uncertain cases go to approval, and the result flows into feed and markup.
You decide how much of this runs automatically and how much goes through approval. Experience shows it is sensible to start with a strict threshold and relax it once the samples remain stable over several weeks.
Categories as maintained data
The July change is small, but its effect on the work behind it is not. An AI assignment against fixed lists, with a measured threshold and a review queue for the rest, keeps this upkeep manageable even as the catalog grows. The effort shifts from manual work per item to maintaining lists, thresholds and samples.
This article is based on Google Search Central (changelog with the entry of July 7, 2026, merchant listing documentation, regional differences in Search), Merchant Center Help (attributes google_product_category and product_type), the Google product taxonomy files in German and English with IDs (own count and check), schema.org (category and CategoryCode), the Shopware documentation (categories), Destatis (use of AI in companies 2025), Eurostat (Use of artificial intelligence in enterprises, data extracted December 2025) and the papers by Guo et al. (On Calibration of Modern Neural Networks, 2017) and Geifman/El-Yaniv (Selective Classification for Deep Neural Networks, 2017). Retrieved on October 16, 2026. The usage figures on schema.org are updated monthly.
No, according to Google the attribute is optional. All products are automatically assigned a category from the Google product taxonomy (Merchant Center Help). Your own value is worthwhile mainly if you organize Shopping campaigns by Google category, if Google assigns an item to a category with additional requirements, or for alcohol.
Since July 7, 2026, Google has described how category is provided in merchant listing markup as text and as a CategoryCode (Google Search Central). This allows the store category and the Google category to appear directly on the product page as well. The property is recommended, not required.
Generally yes, if it selects from fixed lists and hands uncertain cases over to a person. What matters is a threshold measured on your own catalog. Without calibration, the confidence scores of modern models often do not match their actual hit rate (Guo et al. 2017).
There is no fixed number. Typically, the threshold is set per target on a sample of items that have already been checked. A strict threshold lowers the error rate but sends more items to review; research on selective classification describes this trade-off (Geifman/El-Yaniv 2017).
In the current taxonomy, shoes have category 187, Apparel & Accessories > Shoes, with no further subcategories (Google product taxonomy). The finer classification as a hiking boot belongs in your own store category, meaning product_type or category as text.
Yes. The assignment is stored as a field on the product and read by the feed export and the product template. We connect the store, PIM and Merchant Center for this and set up an approval step for uncertain cases. Feel free to reach us via our contact page.