How to fix Merchant Center feed processing errors
A step-by-step workflow for Merchant Center feed processing errors, fetch failures, encoding problems, malformed XML/CSV, column mapping and size limits.
Feed processing errors are file-level failures, Google couldn't fetch, parse or map your feed, so entire uploads fail or thousands of items vanish at once. They're a different animal from item-level disapprovals and they're fixed in a different place: the file, the server it lives on, or the mapping between your columns and Google's attributes. The processing report tells you which, if you know how to read it.
File-level vs item-level: know which problem you have
Merchant Center failures happen at two distinct layers, and merchants burn days fixing the wrong one:
- Feed processing errors are file-level. Google couldn't fetch the file, couldn't decode it, couldn't parse its structure, or couldn't map its columns to product attributes. The blast radius is the whole file: every product goes stale, or a whole block of items silently drops.
- Item issues are per-product. The file processed fine; individual products have bad data. Those live in Diagnostics and have their own fix workflow.
The tell: item issues affect some products with named reasons; processing errors affect the fetch: zero items read, a sudden count drop, or an error naming the file rather than a product. Always clear the file layer first. Nothing downstream is trustworthy while the file isn't being read.
The five failure families
1. Fetch failures: Google never got the file
The fetcher requests your feed URL on schedule and gets a timeout, an error status, or something that isn't your feed. Root causes, in rough order of frequency:
- Bot protection / WAF rules blocking Google's fetcher. Cloudflare challenges, rate limiters and "verify you are human" pages all read as fetch failures. Allow Google's user agent for the feed path.
- Slow generation. Feeds built on demand from a 30,000-product database can exceed the fetch timeout. Pre-generate to a static file, or serve from a feed layer built for it: a hosted feed serving URL returns instantly because the file is already built.
- Auth and redirects. A feed URL behind login, or a redirect chain ending at an HTML page, delivers a "file" that isn't a feed.
- SSL problems. Expired or misconfigured certificates fail the fetch outright.
2. Encoding errors: the file isn't what it claims to be
Google expects UTF-8. The classic failure is a spreadsheet or legacy platform export in Windows-1252 or Latin-1: everything ASCII parses, then a £ sign, a curly apostrophe or an é produces garbled characters or a hard decode error. Fix it at the export step (set the generator to UTF-8) never by find-and-replacing symptoms in the file.
3. Malformed XML or CSV: structure breaks mid-file
For CSV: unescaped quotes inside values, raw line breaks inside descriptions, inconsistent column counts per row, or a delimiter character appearing unquoted in a title. One bad row can end parsing for everything after it. For XML: unclosed tags, unescaped & and < in descriptions, or invalid characters. XML fails louder (a strict parser rejects the document) which perversely makes it easier to debug than CSV's silent truncation.
4. Column mapping: the file parses, the attributes land wrong
Your export says ean, Google wants gtin; your header row says product_name, Google reads nothing into title. The file processes "successfully" while required attributes arrive empty, and the fallout shows up as thousands of item-level "missing value" errors that are really one file-level mapping problem. Fix the header names to match the product data spec, or map them once with a feed rule: and note this is the one failure family that masquerades as item issues.
5. Size and truncation limits
Files cap at 4 GB. Practical truncation arrives earlier: a slow origin plus a big file can time out partway, and some platforms paginate exports without telling you. The symptom is a plausible-looking feed with a fraction of the catalogue in it.
Reading the processing report
The Processing tab on each feed answers four questions in order. Read them in order:
| Question | Where it's answered | If it's bad |
|---|---|---|
| Did the fetch succeed? | Fetch status + timestamp | Fetch failure: fix access, speed, SSL (family 1) |
| How many items were read? | Items count vs your catalogue size | Truncation or parse failure (families 3, 5) |
| Any file-level errors? | Errors list, often with line numbers | Encoding or structure (families 2, 3): the line number is gold |
| Did attributes populate? | Per-attribute warnings + downstream Diagnostics | Mapping problem (family 4) |
The line number deserves emphasis. "Parse error, row 8,431" means row 8,431 of the served file: open the actual file Google fetched, go to that line, and the unescaped quote or stray delimiter is usually staring at you. Debugging your source export instead of the served file is the most common wasted hour in this whole workflow.
After any fix, use Fetch now rather than waiting for the schedule, and re-read the report. A clean process with the right item count is the finish line; items then flow into review: see products pending review for what happens next.
Deep dive Why processing errors recur, and how to make them structurally impossible
Most merchants fix a processing error the same way twice a year, because the fix targets the file and not the pipeline that made it. The recurring pattern: platform export → maybe a spreadsheet edit → upload or fetch → breakage whenever anything upstream changes. Every link in that chain is a place encoding, structure or mapping can silently rot.
What actually ends the cycle:
- Serve a generated feed, not an exported one. A feed built programmatically from structured catalogue data can't have unescaped quotes or mixed encodings: the generator escapes and encodes every value by construction. Hand-touched CSVs can always have both. This is the single biggest structural fix, and it's how /tools serves feeds: your products sync in, enrichment applies on a supplemental layer, and the served file at your feed URL is built valid every time, returned instantly to Google's fetcher.
- Validate before Google does. A pre-submit check for decode errors, row-count consistency and required columns costs seconds. The same problem found by Google costs a failed fetch cycle, stale products, and (after enough consecutive failures) items expiring out of the account entirely.
- Monitor the item count, not just the status. "Processed successfully" with 60% of yesterday's items is a worse failure than a loud fetch error, because nobody notices for a week. A step change in items read after a platform update is the signal to trace: change monitoring watches exactly this kind of movement.
- Kill the spreadsheet hop. If someone opens the feed in Excel between export and upload, you will eventually ship Windows-1252 curly quotes and reformatted dates. Any manual correction that spreadsheet was doing belongs in a supplemental layer or upstream fix, where it applies automatically on every refresh.
The end state worth aiming for: fetch failures impossible because the file is pre-built and served fast; encoding and structure failures impossible because the file is generated, not edited; mapping failures impossible because the headers are the spec's names. At that point the Processing tab becomes the most boring screen in Merchant Center: which is precisely what you want.
Prevention checklist
- Serve the feed from a static or pre-built URL that returns in under a few seconds: no on-demand generation, no login, no bot challenge for Google's fetcher.
- Export or generate as UTF-8, and never route the file through a spreadsheet on its way to Google.
- Match header names to the product data spec exactly, or register the mapping once and leave it alone.
- Compress large files (gzip) and stay well under the 4 GB cap; split the catalogue across multiple primaries before you approach it.
- After every platform migration or app change, force a fetch and check items read against catalogue size: migrations are when feeds break, silently.
For choosing between scheduled fetches, uploads and API submission in the first place, see feed delivery methods.
Step by step
- Open the processing report for the failed fetch. In Merchant Center go to Products → Feeds, click the primary feed, and open the Processing tab. This shows the last fetch attempt, whether the file was retrieved, how many items were read, and every file-level error with a line reference where Google has one.
- Separate file-level errors from item-level issues. File-level errors (fetch failed, encoding, parse errors) stop some or all of the file being read, fix these first. Item-level issues live in Diagnostics and only matter once the file itself processes cleanly. If items read is zero, ignore Diagnostics entirely, nothing was ingested to diagnose.
- Verify Google can fetch the file at all. Request the feed URL yourself from outside your network with a plain HTTP client. Check it returns 200 (not a redirect chain, not a login page, not a 403 from bot protection), completes within the timeout, and serves the raw file rather than an HTML error page.
- Validate the file's structure and encoding locally. Open the actual served file, not your source export. Confirm UTF-8 encoding, one consistent delimiter, a header row matching Google's attribute names (or your registered mapping), quoted fields where values contain delimiters, and, for XML, well-formed markup that a strict parser accepts.
- Fix column mapping and re-fetch. If the file parses but attributes land wrong, the header names don't match what Merchant Center expects, rename headers to the product data spec names or fix the feed's attribute mapping. Then use Fetch now and re-read the processing report rather than waiting for the next schedule.
- Confirm the item count matches expectations. A successful process isn't the finish line, compare items read against your catalogue size. A feed that processes but reads 4,000 of 12,000 items has a silent truncation, size limit, or mid-file parse failure to find.
Frequently asked questions
Why does Merchant Center say my feed could not be fetched?
Google's fetcher got a non-200 response, timed out, or was blocked. The usual suspects, bot protection or a WAF blocking Google's user agent, an expired SSL certificate, a URL behind login, or a server that takes too long to generate the file on demand. Test the URL from outside your own network.
What causes "encoding error" or garbled characters in a processed feed?
The file isn't the encoding it claims to be, most often a Windows-1252 export (curly quotes, £ signs, accented letters) served as UTF-8. Re-export as genuine UTF-8; don't hand-fix individual characters, the next export reintroduces them.
Is there a size limit on Merchant Center feeds?
Yes, 4 GB per file (compressed or not). Beyond that, split the catalogue into multiple primary feeds or move to scheduled fetches of a compressed file. Very large catalogues are usually better served via the Content API.
My feed processes fine but half the items are missing, why?
A mid-file failure. One malformed row (an unescaped quote or stray delimiter) can end parsing early, or a size/timeout limit truncated the fetch. The processing report's items-read count against the errors list narrows down where reading stopped.
Feed processing errors or item disapprovals, which do I fix first?
Processing errors, always. Item-level fixes are meaningless while the file itself isn't being read correctly, and a fixed file often clears thousands of phantom item issues on its own.