Skip to content

Problem

Merchant Center feed fetch failed: how to fix it

Scheduled fetch is Google pulling a file from a URL you gave it, on a clock you set. When that pull fails, nothing about your products changed and nothing in your campaigns changed, so the cause is almost always at the other end of the request: the URL, the server that answers it, or the shape of the file. Product data stays live for a while after the last good fetch, which is the window you have to repair it.

By CartKernel · Last reviewed 2026-09-07

Does this look familiar?

  • The feed shows a failed fetch with a date, while the item count from the previous run is still there
  • An email saying the file could not be downloaded, or that the download timed out
  • Item counts falling day by day as older products reach their expiry
  • The feed URL opens fine in your own browser but Google reports that it cannot be reached
  • Processing finishes but reports zero items, or an encoding or format error near the first line
  • A feed that ran for months started failing the week the theme, the feed app or the host changed

Causes, ranked

Why it happens, most common first

Check them in this order. The first two account for most cases we open.

  • most common

    The feed URL moved, expired or now needs credentials

    Feed apps regenerate their file paths when they are reinstalled or upgraded, and a store redesign can retire the route that served the file. Basic authentication credentials stored in the fetch settings also go stale when a password is rotated. Google keeps requesting the old address and receives a not found or unauthorised response.

  • most common

    Bot protection or a firewall rule blocks the request

    A managed WAF, a rate limit, a country block or a challenge page will answer Google's fetcher with something other than the file. The response often looks like a normal page in a browser because your own session is trusted. Anything that requires JavaScript or a cookie to pass will fail a plain server request.

  • common

    The file is generated on request and takes too long to answer

    Large catalogues that build the feed live, per request, can spend minutes assembling it. Google stops waiting well before that and records a timeout. The same file often succeeds when it is pre-generated and served as a static file or compressed archive.

  • common

    The file is not valid for the format it claims

    An XML feed with an unescaped ampersand, a stray character before the opening tag, a byte order mark, or a delimited file whose header row does not match the columns will stop processing. Mixed encodings from a manual spreadsheet edit produce the same result.

  • occasional

    Redirects, certificate or protocol problems on the feed host

    A URL that redirects to another domain, an expired or incomplete certificate chain, or a host that only answers on an older protocol can all break an automated fetch while a browser quietly works around it. Chained redirects are a frequent cause after a domain change.

  • occasional

    The fetch is scheduled while the file is being rewritten

    If the app rebuilds the export at the same hour Google collects it, the fetcher can receive a partial or empty file. Time zone mismatches between the app schedule and the fetch schedule make this look random.

The fix

In this order

Each step is something you can do today. Do them in sequence; skipping ahead is how a review fails twice.

Prevent it next time

  • Keep the feed URL on a path that a theme update or app reinstall will not change
  • Add the feed URL to uptime monitoring so a failed download is noticed before Merchant Center notices it
  • Pre-generate the export on a schedule rather than building it for whoever asks
  • Re-enter fetch credentials the same day any password on the feed host is rotated
  • Check the processing history once a week even when no email has arrived
  1. Read the fetch status and the exact wording of the failure

    Open the feed in Merchant Center and look at the processing history for the failed run. Note whether the message describes a download failure, a timeout, an authentication problem or a parsing error. Those four point at different parts of the chain, and guessing between them wastes a day.

  2. Request the URL the way a machine does

    Fetch the exact feed URL from a command line, without your browser session, and look at the status code, the content type and the first lines of the response. A challenge page, a login redirect or an HTML error page will be obvious immediately.

  3. Allow the fetch through robots and through your edge rules

    Make sure robots.txt does not disallow the feed path, then add an allow rule for Google's crawler in your firewall or bot management settings so the feed URL is never challenged or rate limited. If the file sits behind basic authentication, re-enter the current credentials in the fetch settings.

  4. Make the file static and smaller

    Have the app or a scheduled job write the export to a file rather than building it per request, and serve it compressed. For very large catalogues, split by product group and use one primary file with supplemental files for the attributes that change often.

  5. Validate the file before Google sees it

    Run the file through an XML or delimited-file validator, confirm the character encoding is UTF-8 with no byte order mark, and check that every value containing a reserved character is escaped. Fix the export at the source rather than editing the file by hand.

  6. Move the schedule away from the rebuild window

    Set the fetch time at least an hour after the app finishes writing the file, and confirm both are using the same time zone. Where the platform supports it, publish to a temporary path and swap it into place so the live URL is never half written.

  7. Re-run the fetch and confirm the item count

    Trigger the fetch manually and wait for processing to complete. Compare the accepted item count with the number of sellable products in the store, then check the following day that the scheduled run succeeded on its own without you touching it.

  8. Consider a direct connection instead of a file

    For stores where the file keeps breaking, an official platform integration or an API connection sends product changes without a scheduled download at all. It removes the URL, the timeout and the firewall from the picture, and updates arrive closer to when stock actually changes.

When to get help

Bring in help when the fetch keeps failing intermittently rather than every time, because that pattern usually points at rate limiting or a generation job that only sometimes finishes, and it is slow to reproduce. It is also worth handing over when the catalogue is large enough that a single file is the wrong architecture, since the answer there is a primary and supplemental feed structure rather than another retry.

Get a Growth Analysis

Free. We reply within one business day.

Questions

Asked alongside this problem

By CartKernel · Last reviewed

How long do products stay live after the last successful fetch?

Product data submitted to Merchant Center expires roughly a month after it was last refreshed, so a feed that stops updating drains slowly rather than stopping at once. That is why item counts fall in a curve. Repair the fetch inside that window and nothing needs to be resubmitted.

Can I upload the file manually while I sort out the schedule?

Yes. A manual upload to the same feed refreshes the same products and buys you time. Keep the file identical to the scheduled export so you are not fixing two sources at once, and remember to confirm the scheduled fetch works again before you stop uploading.

Does a failed fetch pause my Shopping campaigns?

Not directly. Campaigns keep running against whatever product data is still valid, so spend continues while coverage quietly shrinks. The first visible sign is usually impressions falling for a widening set of products rather than any campaign status change.

Should the feed sit on the store domain or somewhere else?

Either works. Hosting it on the store domain keeps everything in one place but puts the file behind whatever protects the storefront. A separate static host or object storage bucket avoids that, at the cost of one more system to keep in sync with the catalogue.

Related problems, answers and terms

All problems
ProblemMerchant Center price mismatch: how to fix itA Merchant Center price mismatch means the crawler saw a different price on your page than the feed sent. The ranked causes and the fix, step by step.OpenProblemMerchant Center availability mismatch: how to fix itA Merchant Center availability mismatch means the page said sold out while the feed said in stock, or the reverse. Causes by frequency and the fix in order.OpenProblemShopping ads not showing: how to fix itShopping ads not showing usually traces to eligibility, not bidding. Work through account, product, campaign and targeting checks in that order.OpenProblemMerchant Center account suspended: how to fix itA suspended Merchant Center account stops every Shopping ad and free listing at once. The causes ranked by frequency, and the fix in order.OpenAnswerHow often should a product feed update?Match feed refresh frequency to how fast price and stock change. Daily fetch as a floor, real-time updates for volatile catalogues, and how to spot staleness.OpenAnswerCan one Merchant Center account serve multiple stores?A Merchant Center account is built around one verified website, so multiple stores usually need sub-accounts under an advanced account. When each model fits.OpenGlossarySupplemental feedA supplemental feed adds or overrides attributes on products already in a primary Merchant Center feed. Worked example, good uses, and what it cannot do.OpenGlossaryItem group idItem group ID is the feed attribute that ties variants of one product together for Merchant Center. Feed rows, why it matters, and the usual mistakes.Open

Stop the leak.

A free Growth Analysis finds what is broken and ranks it by the revenue it costs you.