Feed freshness and crawl timing
Almost every price and availability disapproval is a timing problem in disguise. The feed and the website are two systems telling Google about the same product, and disapprovals happen in the gap between them.
The three ways data arrives
| Method | Latency | Use for |
|---|---|---|
| Scheduled feed fetch | Hours | The full catalogue, daily or more often |
| Content API | Near real time | Price and stock changes as they happen |
| Automatic item updates | Google-initiated | A safety net, not a strategy |
Automatic item updates let Google correct price and availability from the structured data on your landing page when the feed disagrees. It is worth enabling as a backstop, but it is a correction of your data by a third party, not a substitute for sending the right data.
How often to fetch
Daily is the minimum for any live catalogue. Several times a day is right for anything with volatile stock. For genuinely fast-moving inventory, such as marketplaces, flash sales and single-unit stock, scheduled fetching is the wrong tool and the Content API is the right one.
The crawl you cannot schedule is Google’s crawl of your landing page. It happens on Google’s timetable, which is why the feed must be right before the page changes rather than after.
Ordering changes so they do not disapprove
- Price rises: update the feed first, then the site.
- Price cuts: update the feed first, then the site. The feed is always first.
- Going out of stock: feed first, ideally through the API.
- Coming back in stock: site first is harmless; feed first is faster to appear.
Structured data on the product page
Product schema markup on the landing page gives Google an unambiguous price and availability to read instead of parsing the rendered page. It reduces mismatch disapprovals materially, it is what automatic item updates read, and it is the same markup that AI shopping surfaces use. It is the highest-return technical change on this list.