Product Feed Optimization in 2026: What Changed and What Breaks

Two things happened to Google product feeds recently that we could not find covered anywhere, and both are live right now.

Content API for Shopping was sunset on 18 August 2026. Google’s own wording: “Content API for Shopping was sunset on August 18, 2026” and “Starting September 1, 2026, requests will experience progressive errors.” If your feed integration runs on it, it is already degrading. We read 22 pages currently ranking for feed optimisation on 13 September 2026 and none of them mentions it. Every integration section in that SERP is describing dead infrastructure.

And if you use AI to generate product titles, you are probably in breach of Google’s product data specification. Google requires: “All titles created using generative AI must be provided using the structured title [structured_title] attribute instead of the title [title] attribute”, with the digital_source_type sub-attribute set to trained_algorithmic_media (Google Merchant Center Help 6324415). AI title generation is now a common feature in feed tools, and none of the 22 pages we read mentions the disclosure requirement.

This page is the current reference, with the Merchant Center article ID behind every claim so you can check it. It also corrects the things this category repeats that are simply not true: the 70-character title limit, the idea that google_product_category is required, and the belief that you need a GTIN for everything.

Last verified: 13 September 2026.

What changed in Google feeds in 2025 and 2026?

Ten changes in a little over two years, with one mandatory requirement landing in seventeen days. None of the 22 pages we read assembles them, which is why the category is wrong in so many directions at once.

Feed changelog, with sources

Is it still called Merchant Center Next?

No, and getting this wrong dates your work by two years in either direction.

Three milestones, all documented:

• The migration finished on 1 October 2024. Google: “All merchants have now been migrated to Merchant Center Next.” There is no classic Merchant Center to go back to.
• The “Next” name was retired in July 2026. Google: “No action is required. This name change doesn’t affect your account.” It is now simply Google Merchant Center.
• The vocabulary changed with it. Feeds are data sources. Diagnostics is the Needs attention tab. Automatic item updates now live under Automations.

So a guide saying “classic Merchant Center” is two years out of date, and a guide carefully explaining “Merchant Center Next” is now out of date in the other direction. In the set we read, most pages fall into one camp or the other.

Is your feed integration already broken?

Check this before you optimise a single title, because a dead pipeline makes every other improvement irrelevant.

Google: “Content API for Shopping was sunset on August 18, 2026” and “Starting September 1, 2026, requests will experience progressive errors” (Content API for Shopping documentation).

The replacement, Merchant API v1, has been generally available since mid 2025. Google’s developer documentation dates general availability to July 2025 while the Merchant Center announcements log says August 2025.

How to tell which integration you are on

The one to actually worry about is the platform app. If you connect through an app rather than directly, you inherit whatever integration the vendor built, and you will find out it was Content API when products start dropping out. Ask them in writing.

Are your AI-generated product titles compliant?

This is the highest-value thing on this page and no ranking page mentions it.

Google’s requirement is explicit: “All titles created using generative AI must be provided using the structured title [structured_title] attribute instead of the title [title] attribute.” And the disclosure mechanism: “The digital source type [digital_source_type] sub-attribute of the structured title [structured_title] attribute must have value ‘trained_algorithmic_media’, indicating that the text was created using generative AI” (Google Merchant Center Help 6324415).

The same obligation exists on the image side: images created using generative AI “must contain meta data indicating that the image was AI-generated” (Help 14743464).

Why this matters right now. AI title generation has become a common feature in feed management tools. If you have switched it on and the output goes into the plain title attribute, you are submitting generative AI content without the required disclosure. None of the 22 pages we read mentions the obligation, so it is worth checking rather than assuming your tool handles it.

What to do: find out whether any part of your title or description generation is machine-generated, then route it to the right attribute. Titles go to structured_title. Descriptions go to structured_description. Both carry the digital_source_type sub-attribute set to trained_algorithmic_media (Help 14743464). Putting an AI-written description into structured_title is as non-compliant as leaving it in the plain field. Character limits are unchanged: 150 for titles, 5000 for descriptions.

Which feed attributes are actually required?

This category states requirements confidently and gets several of them wrong. The table below is built from Google’s product data specification (Help 7052112), with the individual attribute pages cited where the detail lives on them rather than on the spec.

Required, conditional and optional

Two corrections that matter.

google_product_category is optional. Google says so plainly (Help 6324436). Much of this category calls it mandatory. It is genuinely valuable and you should submit it, but “required” is false, and a merchant who believes it is required will waste time on it while a genuinely blocking issue sits unfixed.

gtin is not universally required either, and Google is direct about the wrong way to handle it: “Don’t submit a GTIN for a product that doesn’t have one. If you’re the only seller of a product or if your product is a store brand, it generally won’t have a GTIN, so you don’t need to submit one” (Help 6324461). Inventing GTINs to clear a validation error is worse than leaving it out.

How long can a product title be?

150 characters. Google’s specification: “Max 150 characters”.

The widely repeated “70 character limit” is not a limit. It is a rough guide to where titles get truncated on some surfaces, and 70 happens to be the actual character limit for the brand attribute, which is probably where the confusion started.

The practical implication is the opposite of what the myth implies. You have 150 characters to work with, so the constraint is not space, it is front-loading. Put the words a buyer would search in the first 70, and use the remaining 80 for the qualifying detail that helps Google match longer queries.

Descriptions: 5000 characters, not 1000.

How should you build a product title?

There is no single formula because the ordering that works depends on how people shop the category. What is constant is that brand and product type belong early, and attributes that people actually search belong before attributes that merely describe.

Title formulas by vertical

Three rules that apply to all of them:

• Do not stuff. Repeating the brand three times does not improve matching and reads as spam to a human, who is the one deciding whether to click.
• Match the landing page. A title promising a size or colour the page does not show creates a mismatch you will eventually be pulled up on.
• Test in blocks, not per SKU. Change the formula for one product type, hold everything else, and compare against the same period last year as well as the previous period.

If the titles are machine-generated at any point in that process, see the structured_title requirement above. That applies regardless of which formula you use.

What are the real image requirements?

The pages we read discuss images qualitatively. None publishes Google’s full set of thresholds, and one of those thresholds has a hard deadline coming.

Image specification

Sources: Help 6324350 and Help 12159030.

The deadline nobody is warning about. Google is raising the minimum image resolution to 500×500 across all product categories, with warnings running since 14 April 2026 and enforcement beginning 31 January 2027 (Help 16989427).

Be clear about what is enforced today. Right now the enforced minimums are still 100 x 100 for non-apparel and 250 x 250 for apparel. Images below 500 x 500 are generating warnings, not disapprovals. That changes on 31 January 2027, when 500 x 500 becomes the floor for every category.

So if your catalogue was built to 250 x 250, nothing is broken this week and a meaningful share of it will disapprove in January. That is a re-shoot or a re-export, which takes longer than four months in most businesses, so it is worth auditing now rather than in December. The workbook further down flags every image below 500 x 500 with a countdown.

If you check this yourself you will find Google’s pages appear to disagree: the specification states 500 x 500 while the disapproval troubleshooting page states 100 x 100 and 250 x 250. Both are right. The troubleshooting page describes what is enforced today and the specification describes the end state. Read it as a timeline rather than a contradiction, and plan to the January date.

Do you actually need a GTIN?

No, and the industry treats this as more urgent than Google does.

Google’s position: GTIN is “strongly recommended if available”, and you should not invent one. For products genuinely without an identifier, the correct move is identifier_exists: “Recommended for products that don’t have a GTIN, MPN, or brand” (Help 6324478).

Set it to no or false when the product genuinely has no assigned identifier. Google’s warning about misuse: products where it “is incorrectly set to no or false and for which there is evidence that a unique product identifier exists, will receive a warning.”

Note the word warning. This is a warning-level issue, not a disapproval. That matters for triage: teams routinely drop everything to fix identifier warnings while genuine item disapprovals sit untouched. The triage model further down ranks by what actually stops products serving.

One detail that catches out anyone moving to the new API: text and XML data sources accept yes, true, no and false, but Merchant API data sources accept only true and false.

google_product_category or product_type?

Both, and they do different jobs. Both are optional, which surprises most people.

The difference

Sources: Help 6324436 and Help 6324406.

That last row is the one nobody publishes. You can submit five product_type values, but Google scopes the usable one narrowly: only the first is used to organise bidding and reporting in Google Ads Shopping campaigns. Note that scope, because it is doing work. Teams build elaborate secondary and tertiary values expecting to segment on them everywhere, then find the segmentation is not where they expected. Put your most useful dimension first.

Build product_type at least two to three levels deep. A flat single-level value gives you nothing to segment on, which defeats the purpose of having your own taxonomy at all.

How should you use custom labels?

Five of them, custom_label_0 through custom_label_4, and Google’s stated purpose is worth quoting because it now names the current campaign types: they “allow you to create specific filters to use in your Performance Max, Shopping, or Demand Gen campaigns” (Help 6324473).

The limit that breaks plans: “1 to 100 characters, up to 1,000 unique values account-wide for each custom label attribute (up to 5,000 labels total).”

That kills the common advice to push a per-SKU dynamic value into a custom label. Margin to two decimal places across a 10,000 product catalogue blows through 1,000 unique values immediately. Bucket instead.

A custom label allocation that works

One rule: never encode the same dimension twice. If label 0 is margin band and label 4 is price band, check they are not simply correlated in your catalogue, or you have spent two of five slots on one signal.

Why do products keep disappearing from your feed?

Usually this, and it is a single sentence in Google’s documentation that explains a very common panic: “All products expire from your Merchant Center account 30 days after the last refresh” (Help 6324499).

Thirty days from the last refresh, not from upload. So a manual file upload that nobody re-runs silently empties the account a month later. A scheduled fetch that has been failing quietly does the same thing on the same clock.

Three things follow:

• Manual upload is not a strategy. It is a one-month timer.
• Check that your fetch is succeeding, not just that it is configured. A configured fetch pointing at a URL that now 404s looks fine in the settings screen.
• Use expiration_date deliberately if you want a product to stop showing on a date. Google allows “a date up to one year in the future.”

Google documents scheduled fetch as “a feature that automatically retrieves your product data from your server at regular intervals” (Help 15625172). It does not enumerate the available frequency options in its current help pages, so if you read a specific cadence somewhere, treat it as unsourced. What we can say with confidence is that whatever you choose has to land more often than every 30 days.

What can a supplemental feed actually do?

Less than most people assume, and the constraint is the thing that catches everyone out.

Google: a supplemental data source is “a secondary data source used to provide more details or update existing details” and can “add or override custom labels”, “add or override promotion IDs”, “override titles”, “exclude specific products”, “add missing Global Trade Item Number (GTIN)” and “add local inventory product data” (Help 15157604).

The hard limit: “your product data will only be updated when the supplemental product data sources contain IDs that are in a primary product data source.”

So a supplemental feed cannot add products, and it does absolutely nothing for any row whose id does not exactly match a row in the primary source. This is the single most common supplemental feed misconfiguration: the file uploads successfully, reports no errors, and changes nothing, because the IDs are formatted differently in the two files.

Attribute rules, which used to be called feed rules, are the other lever: they “give you the ability to transform your data to match our product data specification requirements” and the feature “works with a cascading function, which means that if you’ve multiple rules it’ll first run the first and then the second and so on” (Help 14994083). Order matters, and it is not obvious in the interface.

When to use which. Use attribute rules when the fix is a transformation of data you already have. Use a supplemental feed when the fix is data that does not exist in the primary source at all, such as margin bands from your finance system. Use neither when the right fix is upstream in the platform, because every layer you add is a layer somebody has to understand in two years.

Should you let Google auto-update your feed?

Google’s automations “keep your product data accurate by automatically using your landing page data to update your product data”, and are “offered for the price, sale price, availability and condition attributes” (Help 3246284). You will find them under Products and store, then Products, then Automations.

The pages we read describe this as a feature. It is also a risk, and none of them frames it that way.

The honest trade-off

The case against leaving it on indefinitely: if Google is quietly correcting your prices from your landing pages, your feed is wrong and you do not know by how much. That same feed is probably also going to Meta, Microsoft and your marketplace listings, where nothing is correcting it.

Our usual position: leave automations on while you fix the pipeline, then decide deliberately rather than by default.

How do you triage feed disapprovals?

The pages we read list errors alphabetically. None ranks them, and ranking is the entire job when you open an account with 4,000 issues.

Three severity tiers, which Google treats very differently:

Severity tiers

Misrepresentation is the exception that skips the ladder. Google: “Violations of this policy are taken very seriously and are considered egregious”, and “If violations of this policy are found, your Google accounts will be suspended upon detection and without prior warning, and you won’t be allowed to promote with Google Shopping again.” Google adds that “Accounts are only reinstated in compelling circumstances, and when there’s good reason” (Help 6150127).

That is why the usual warning-then-suspension mental model is wrong for this one category, and why it deserves a separate process. We have written that process up separately in the Merchant Center misrepresentation appeal template, and the policy clauses that most often trigger it are in the ten Merchant Center clauses that matter most.

The triage order that works, for everything below suspension level:

1. Anything blocking the whole account. Policy issues, verification, claims on the website.
2. Item disapprovals ranked by revenue at risk, not by error count. Forty disapproved accessories matter less than four disapproved bestsellers.
3. Price and availability mismatches, because they compound: they disapprove products and they erode the trust signals behind everything else.
4. Missing required attributes on products that are otherwise serving.
5. Warnings, including identifier warnings, last.

Review turnaround, when you do request one: Google says “Review requests typically take up to 3-7 business days to complete” (Help 13693195).

How do you stop price and availability mismatches?

One of the most common disapprovals in ecommerce, and the one the pages we read treat most vaguely.

Google’s requirement: “Submit an amount and currency that match the price on your landing page and the checkout pages”, and on failure, “we disapprove your product and let you know in your Merchant Center account” (Help 6324371).

Two things Google says that people miss:

• Both the landing page and the checkout page have to match. A price that changes at checkout because of a fee or a mandatory add-on is a mismatch even if the product page looks right.
• Geo-pricing is prohibited. “Don’t change the price of your product on your landing page based on a user’s location. IP detection is against our guidelines and may interfere with the crawler behavior.”

The fix nobody publishes is the markup. Google states: “We automatically read the structured data markup on your website using our advanced data extractors and directly pull product data from your HTML into Merchant Center” (Help 12157888). So the landing page markup is not decoration, it is a second source of truth that Google reconciles against your feed. If they disagree, you get disapprovals that look like feed problems and are actually markup problems.

The minimum viable Product markup for this purpose:

{

"@context": "https://schema.org",

"@type": "Product",

"sku": "ABC-123",

"gtin13": "0123456789012",

"name": "Product name exactly as in the feed",

"brand": { "@type": "Brand", "name": "Brand" },

"offers": {

"@type": "Offer",

"url": "https://example.com/product",

"priceCurrency": "USD",

"price": "49.99",

"availability": "https://schema.org/InStock",

"itemCondition": "https://schema.org/NewCondition"

}

}

Three rules: the sku should match your feed id, the price must be the number a buyer actually pays, and the markup must update when the site does. Static markup that says InStock on a sold-out product is worse than no markup.

How should variants be structured?

item_group_id groups them, and Google’s requirement is stricter than most merchants realise: it is “Required for free listings for product variants” and “Required for Shopping ads for product variants targeting” a list of countries that includes the United States (Help 6324507).

The variant-identifying attributes are colour, pattern, material, age group, gender and size. Each variant needs its own row with its own id, and the values that differ must actually differ.

The requirement people fail: “Make sure that the product details displayed on your landing page match the variant-identifying values you provide for the variant like title, variant option, color, price, availability, and image link.” A variant row for a red shirt that links to a page defaulting to blue is a mismatch, and it is very common on platforms where every variant shares one URL.

Two newer optional attributes, variant_option and item_group_title, extend this and did not appear in any of the guides we read.

What do US merchants need for shipping and tax?

The US has two specific requirements that get skipped.

Shipping is required. Google: “Shipping costs are required for Shopping ads and free listings” for a list of countries including the US (Help 6324484). Two exclusions worth knowing: “Do not include government-imposed fees such as import duties, recycling fees, copyright fees, or state-specific retail delivery fees in the shipping cost”, and specifically “For the state of Colorado, don’t include any retail delivery fee in your product data source.”

Tax is conditional, and Google would rather you did not use it. The tax attribute “lets you override US tax settings that you created in Merchant Center”, and is “Required for the United States when you need to override the account tax settings”. But Google’s own recommendation is: “instead of submitting this attribute, we recommend that you set up tax rates through Merchant Center settings” (Help 6324454).

If you do use it: “Make sure to cover every location in the US (even locations where you do not charge tax)”, and do not use it for any country other than the US, and never for VAT or import tax.

On promotions, one US-specific note: “Sale event is only available for the promotions targeted for the United States” (Help 2906014). Promotion IDs are case sensitive, max 50 characters, and must not contain spaces or symbols.

How does feed quality affect Performance Max?

Worth being careful here, because this is where the category tends to make claims Google has not made.

What Google actually says: “Providing all relevant attributes for a product increases its chances of showing for the most relevant search queries” and “it’s important that you provide accurate, high-quality product data” (Google Ads Help 188489). On Performance Max specifically, Google documents that campaigns use data source information to generate ad formats including Shopping ads (Help 14987606).

What Google does not say is any number. There are no published percentages tying feed completeness to conversion lift. If you have seen a statistic attributed to Google on this, it did not come from Google. We are not going to invent one either.

The defensible version: in Performance Max the feed is doing work that keywords used to do. You have fewer targeting levers than you did in a Search campaign, so the attributes are a larger share of what the system has to go on, and product_type and custom labels are how you retain any structural control at all. That is an argument from mechanics, not from a statistic. The asset group side of it is in Performance Max asset group structure for ecommerce, and the diagnostic order when it underperforms is in Performance Max not performing.

One catalogue, four channels and a marketplace

Every page we read writes as though Google is the only destination. In practice one master catalogue usually feeds Google, Meta, Microsoft and TikTok, often a marketplace too, and their rules conflict.

Where the channels disagree

The comparison below is our own working summary from managing feeds across these channels, not a citation of each platform’s documentation, so treat the non-Google columns as a starting point to verify rather than a specification.

The practical answer is not one feed. Keep a single master catalogue as the source of truth, then transform per channel at the last step, and keep a written record of where the rules diverge so the next person does not undo it. The failure mode is optimising titles for Google, pushing the same file to Meta, and quietly getting worse there without anyone connecting the two.

This matters more than usual right now because of the generative AI disclosure requirement. Google has one. We are not aware of an equivalent on the others, though that is worth checking per platform rather than taking from us. Either way, a single title-generation process feeding every channel is non-compliant on Google unless you handle Google separately.

What new attributes shipped in 2026?

Eight additions and changes, none of which appeared on any of the 22 pages we read. One of them stops being optional this month.

New and recent attributes

Source: Help 16989427 and the individual attribute pages.

Deal with the 30 September deadline first if you sell into the UK, Switzerland or the EEA with in-store pickup enabled. pickup_cost and minimum_order_value stop being optional on that date.

Then look at video_link. It became eligible to serve in June 2026 and adoption appears low, at least across the pages and feeds we have looked at. Our view, and it is a view rather than a finding: optional attributes that most competitors skip are among the cheapest differentiation available in Shopping, because the surface is identical for everyone and the content is not.

How do you measure feed quality?

You cannot see a feed quality score, and one of the strongest pages we read says exactly that and then stops. So build your own, because “the feed is better now” is not something you can put in a client report.

Six dimensions, weighted by how much each one actually costs you:

A feed health score

The weighting is the argument. Blocking compliance is 40 percent because a beautifully written title on a disapproved product is worth nothing. Most feed advice inverts this and spends its time on titles.

Track it weekly. The number matters less than the direction, and the direction is what a client can see.

The free feed audit workbook

The assets we found are either behind an email wall, badly out of date, or hosted tools you cannot take into a client meeting. So here is an ungated workbook, dated and source-linked.

What is in it

Ungated, no email. Four things in it we have not seen in any competing asset: the Content API dependency check, the 31 January 2027 image countdown, the generative AI disclosure flag, and the 2026 attributes including the 30 September requirement.

Common feed mistakes

• Writing titles to 70 characters. The limit is 150. Front-load the first 70, use the rest.
• Running AI title generation into the plain `title` attribute. Google requires `structured_title` with a `trained_algorithmic_media` disclosure.
• Still integrating through Content API for Shopping. Sunset 18 August 2026.
• Inventing GTINs to clear a validation error. Use `identifier_exists` instead.
• Treating `google_product_category` as mandatory. It is optional. Submit it anyway, but do not let it outrank real blockers.
• Building product_type values two to five expecting to segment on them. Only the first is used for bidding and reporting.
• Putting per-SKU values into custom labels. 1,000 unique values per label, account-wide.
• Uploading a file manually and walking away. Everything expires 30 days after the last refresh.
• Supplemental feed IDs that do not match the primary source. It will upload cleanly and do nothing.
• Fixing disapprovals alphabetically. Rank by revenue at risk.
• Leaving images at 250 x 250. Fine today, disapproved from 31 January 2027.
• Leaving automations on permanently. It hides how wrong your feed actually is, including for every other channel it feeds.

Frequently asked questions

What is the character limit for a Google Shopping product title?

150 characters. The “70 character” figure that circulates widely is a truncation guide, not a limit, and 70 is actually the limit for the brand attribute. Descriptions allow 5000 characters.

Is Content API for Shopping still supported?

No. Google states it “was sunset on August 18, 2026” and that “Starting September 1, 2026, requests will experience progressive errors.” Merchant API v1 has been generally available since mid 2025. If you connect through a platform app, ask the vendor which API they use.

Do I need to disclose AI-generated product titles to Google?

Yes. Google requires that “All titles created using generative AI must be provided using the structured title [structured_title] attribute instead of the title [title] attribute”, with digital_source_type set to trained_algorithmic_media. The same obligation applies to AI-generated images, which must carry metadata indicating they were AI-generated.

Is it still called Merchant Center Next?

No. All merchants were migrated by 1 October 2024, and the “Next” branding was retired in July 2026. It is simply Google Merchant Center. Feeds are now called data sources and Diagnostics is the Needs attention tab.

Is google_product_category required?

No. Google states it is “Optional for each product.” It is still worth submitting, but it is not a blocking requirement and should not outrank actual disapprovals in your fix list.

Do I need a GTIN for every product?

No. Google lists it as “strongly recommended if available” and says explicitly “Don’t submit a GTIN for a product that doesn’t have one.” For products genuinely without identifiers, use identifier_exists set to no or false. Misusing it produces a warning, not a disapproval.

Why did my products disappear from Merchant Center?

Most often expiry. Google: “All products expire from your Merchant Center account 30 days after the last refresh.” A manual upload that is never repeated, or a scheduled fetch that has been failing silently, empties the account on that clock.

What is the minimum image size for Google Shopping?

Today, 100 x 100 for non-apparel and 250 x 250 for apparel. From 31 January 2027 the minimum becomes 500 x 500 across all product categories, and images below that have been generating warnings since 14 April 2026. Around 1500 x 1500 is recommended, with a 64 megapixel and 16MB ceiling. Build to 500 x 500 or larger now.

Can a supplemental feed add new products?

No. Google states that “your product data will only be updated when the supplemental product data sources contain IDs that are in a primary product data source.” If the IDs do not match exactly, the supplemental feed uploads without error and changes nothing.

How many custom labels can I use?

Five, custom_label_0 through custom_label_4, each 1 to 100 characters, with up to 1,000 unique values account-wide per label and 5,000 in total. That ceiling rules out per-SKU dynamic values on a large catalogue.

How many product_type values should I submit?

You can submit up to five, but Google states that “only the first value will be used to organize bidding and reporting in Google Ads Shopping campaigns.” Put your most useful segmentation dimension first.

Should I let Google automatically update my feed?

It reduces price and availability disapprovals, and it also hides how inaccurate your feed is. That matters because the same feed usually powers Meta, Microsoft and marketplace listings where nothing is correcting it. Leave it on while you fix the pipeline, then decide deliberately.

How we checked this

We read 22 pages currently ranking across eight feed queries in full, not their meta descriptions, and recorded what each covers and omits. Every attribute, limit, date and quotation in this article was verified against Google’s own documentation, and the Merchant Center article ID is given so you can check it yourself.

Where Google does not document something the industry repeats, we have said so rather than repeat it:

• Google does not enumerate the available scheduled fetch frequencies in its current help pages. Any guide stating a specific cadence is citing something other than Google.
• Google publishes no maximum number of levels for the google_product_category taxonomy.
• Google publishes no limit on the number of attribute rules.
• Google publishes no quantified performance claims tying feed quality to conversion lift. The strongest thing Google actually says is that “Providing all relevant attributes for a product increases its chances of showing for the most relevant search queries.” Any percentage you see attributed to Google on this is not Google’s.
• Google’s own pages disagree on the enforced image minimum. The specification says 500×500, the disapproval troubleshooting page still references older thresholds, and the dated announcement puts full enforcement at 31 January 2027. We have followed the specification and the announcement.

Last verified: 13 September 2026. Google changed the product data specification three times in the eighteen months before that date, on 8 April 2025, 14 April 2026 and 28 April 2026, so check the linked sources before quoting a limit to a client. We re-verify this page quarterly and the changelog near the top records what moved.

Want the feed audited for you?

The pattern we see most often is not a badly written title. It is a pipeline that has been quietly failing, a catalogue built to image thresholds that expire in January, and a disapproval list nobody has ranked by what it actually costs.

Ask us to audit your feed, or read how we structure the campaigns it feeds in our ecommerce PPC services.