Issue 013 - Google Merchant Center Feed Fix: the $1,199 seven-day cleanup (2026)

A small store can have a working checkout, a real catalog, and products that still fail to appear on Google. The usual cause is a mismatch between the product data Google receives and the product page a shopper opens: price, availability, identifiers, images, shipping, or a required field.

That gap creates a bounded service. The store owner already has the products and the ecommerce platform. You repair one Merchant Center feed, document the changes, and leave the owner with a resubmission trail they can use after you leave.

The offer

Google Merchant Center Feed Fix $1,199 flat. Seven business days. One feed. One country.

The package covers one verified Merchant Center account, one primary online product source, one target country, and up to 100 active SKUs. The client supplies administrator access, the store URL, the product export or feed URL, current shipping and return rules, and one person who can approve product-data changes.

You return a corrected primary source or a documented set of feed rules, a resubmission of the affected products, a before-and-after issue map, a QA packet with sample product checks, and one 60-minute handoff call.

Google's product-data specification makes the boundary concrete. Each product needs a stable id, title, description, landing-page link, main image_link, availability, and price. Brand and identifiers such as gtin or mpn apply according to the product and catalog situation. Missing required attributes can keep products from serving in ads and free listings. 1

The service repairs the data path. The service does not promise impressions, approval of an account suspension, rankings, sales, or a permanent clean bill of health. Google can review products by country, and the store can change prices, stock, images, or policies after the handoff.

Included

One Merchant Center account and one target country.
One primary product source from Shopify, WooCommerce, BigCommerce, a spreadsheet, or another source the client already maintains.
Up to 100 active SKUs, including variants when the source identifies those variants clearly.
Up to five recurring issue classes, such as missing identifiers, price or availability mismatch, broken product links, missing required fields, or image-policy problems.
One feed correction pass or one set of Merchant Center feed rules.
One resubmission and one diagnostic review after the new data is processed.
A sample QA check of 20 products, with the client choosing the sample or the operator selecting a spread across products and variants.
One before-and-after issue map showing the affected attribute, source of the value, correction, and remaining client action.
One consolidated revision round.
One 60-minute handoff call and a 14-day defect window for errors in the approved correction map.

Keep outside the package

Move these requests into a second offer or a specialist referral:

Account suspension recovery, misrepresentation appeals, legal-page writing, or policy disputes that require a full store review.
More than 100 active SKUs, more than one country, multiple catalogs, or multiple ecommerce stores.
Custom API development, warehouse or ERP integration, or a new feed-management platform.
Product photography, image retouching, copywriting for an entire catalog, or manual rewriting of every title.
Paid Shopping campaigns, Performance Max structure, bid management, or conversion tracking.
Tax, shipping, or returns decisions that only the store owner or a qualified adviser can make.
Ongoing monitoring, seasonal catalog work, or unlimited resubmissions.

The client owns the store, Merchant Center account, product source, and feed rules. The operator receives temporary access, records the settings changed, and removes access after handoff. This keeps the service repeatable and keeps the data with the business that generated it.

Loading stats card…

Why this is not ordinary freelancing

"Fix our Google Shopping feed" sounds small until the work begins. The feed may be wrong because the source export is stale, the product page shows a different price, a variant lacks a gtin, a crawler cannot reach the page, or a shipping setting conflicts with the product data. A vague promise turns each new error into free investigation.

The package becomes saleable when the buyer can see the boundary before access begins: one account, one country, 100 active SKUs, five issue classes, seven business days, one revision. The buyer pays for diagnosis, controlled correction, and evidence of what changed.

Public asking prices show why the package needs a visible scope. Fiverr's 2026 cost guide places basic feed setup and listing work around $40–$80, intermediate optimization and campaign launch around $90–$150, and advanced strategy or ongoing management around $180–$250 or more. The same guide says catalog size, feed optimization, advertising integration, and specialist experience change the price. Those figures describe marketplace asking prices, not an audited market average. 2

At the other end, ZATO publishes a one-time Merchant Center feed audit at $1,500–$3,000. Its audit includes a full account review, attribute-quality assessment, custom-label evaluation, title and description analysis, supplemental-feed review, a written report, and a strategy call. 3

OuterBox describes a wider management service that adds setup, feed creation, attribute mapping, ongoing optimization, automation, inventory synchronization, diagnostics, reporting, and support for large catalogs and multiple stores. OuterBox publishes a quote-based offer rather than a fixed public price. 4

The $1,199 package sits between low-cost listing work and a full account audit because it sells one repair cycle. The package earns its margin by refusing to become campaign management, catalog copywriting, or suspension recovery.

Delivery SOP

Plan for about 12 hands-on hours across seven business days. The clock pauses when the client has not supplied access, an export, a policy answer, or an approval. A fixed deadline needs a fixed waiting rule.

Day 1: qualify the failure

Ask for the Merchant Center account, target country, store platform, product-source type, current issue export, affected-product count, and the person who can approve changes. Ask the client to name the business result that is blocked: product eligibility, a price mismatch, a broken source, or a small set of missing attributes.

Reject or re-scope when:

the account is suspended and the client expects an approval outcome;
the catalog needs a full copywriting project;
the source has more than 100 active SKUs;
the store has several country feeds with different currencies or shipping rules;
the client cannot identify who owns tax, shipping, returns, or product identifiers;
or the operator would need to build an integration before a feed can be corrected.

Write one sentence before payment:

We will diagnose and repair up to five issue classes across one Merchant Center product source, one country, and 100 active SKUs in seven business days, then hand back an evidence packet.

The sentence protects the service. A request for another country, catalog, or integration becomes a separate quote.

Day 2: export the issue map

Merchant Center places item-level problems in Products → Needs attention. The client can filter those products and download a CSV of affected items. Google separates warnings from disapprovals: warnings leave products eligible while limiting performance, while disapprovals stop products from showing until the issue is fixed and the product is reviewed. 5

Google Merchant Center Products page showing the Needs attention area and a request-a-review flow — *Google's Merchant Center Help shows the Needs attention workflow and request-a-review path for product issues. Open the original Google support guidance.*

Create one row per issue class, not one row per vague complaint:

Issue class	Affected sample	Value in source	Value on page	Correction owner	Evidence required
Price mismatch	20 products	Feed price	Product-page price	Store owner or operator	Feed row and page check
Missing identifier	20 products	Blank `gtin` or `mpn`	Supplier or catalog record	Store owner	Identifier source
Broken link	10 products	Old URL	Current product URL	Operator	HTTP and page check
Missing attribute	20 products	Blank field	Variant or product record	Operator with approval	Before-and-after row
Image issue	10 products	Image URL	Product image	Store owner or operator	Image and policy check

The table gives the client a place to answer questions. A blank identifier becomes a client decision when nobody can verify the manufacturer code. The operator should preserve the unresolved row instead of inventing a value.

Day 3: trace each value to its owner

For every selected issue, record four values: the feed value, the landing-page value, the required Google field, and the person who can approve the correction. This step separates a formatting error from a business decision.

Google lists price and availability mismatches as a source of preemptive item disapprovals. Google also lists placeholder content, broken links, missing or inconsistent information, inaccurate descriptions, category mismatches, blocked crawlers, unavailable pages, and redirects to generic pages among the website problems that can lead to product disapprovals. 5

Check the most expensive-to-miss values first:

Price and sale price against the product page and checkout.
Availability against the store's current stock state.
Product link, canonical destination, and redirects.
Brand, gtin, mpn, variant grouping, and category.
Main image, promotional overlays, and missing variant images.
Shipping, returns, and country-specific settings.

The operator changes only values inside the approved correction map. The client decides whether an unknown product identifier is available, whether a product is really in stock, and which shipping rule the store can honor.

Day 4: correct the source

Use the client's existing source wherever possible. A spreadsheet source may need a corrected column. A platform feed may need a field mapping or an attribute rule. A client-owned app may need a setting changed in the ecommerce platform.

Google's specification requires stable identifiers, consistent product text, valid landing-page links, accepted image formats, a supported availability value, and price with an ISO 4217 currency code. The specification also sets conditional requirements for apparel, variants, bundles, multipacks, and products that need certification information. 1

Keep an exception log with three labels:

Fixed by operator — a clear mapping, URL, formatting, or rule change.
Approved by client — a price, identifier, stock state, shipping, or policy decision.
Waiting on client — a missing value or store change that requires access or business knowledge.

Google can automatically update price, availability, condition, images, and estimated delivery times when the relevant automatic-improvement settings are enabled. Those settings are off by default, and image improvements apply to disapproved products such as products with image overlays. 6

Automatic updates are a useful safety net. They are also a reason to document settings rather than claim that one manual fix will hold forever. The client should approve which automated corrections can change its product data, especially when low stock or intentionally restricted items are involved.

Day 5: resubmit and test

Submit the corrected source or apply the approved rules. Recheck the 20-product sample across the selected issue classes. Capture the source row, the product page, the resulting Merchant Center status, and any warning that remains.

A product can move from a fixable item issue to an account-level problem. The operator should stop the package when the next action requires a suspension appeal, legal-page rewrite, policy interpretation beyond the agreed checklist, or a platform integration.

The handoff packet should contain:

the original issue export;
the correction map;
the changed source or feed-rule list;
the 20-product QA sample;
unresolved rows and the client owner for each row;
the date of resubmission;
and the steps for checking Products → Needs attention again.

Days 6–7: review, revise, and hand off

Send one review page with four sections: corrections, client decisions, remaining issues, and requested changes. Ask for one consolidated response. A second catalog, new country, or new issue class starts a new quote.

Run the handoff call through five actions: open the issue export, trace one product from source to page, inspect one approved correction, download a fresh issue list, and pause or change any automatic improvement the client chooses to control. Remove access after the client confirms receipt of the packet.

Loading chart…

This is a planning model. A catalog with unclear identifiers or an owner who changes the store during the repair can consume the margin before the correction is complete.

Acquisition channel: the disapproval teardown

The first buyer is a store owner who can already see a problem. That makes a small diagnostic teardown stronger than a generic promise to "optimize Shopping."

Look for independent ecommerce brands, small agencies, and Shopify or WooCommerce operators whose product pages are public. Check a small sample of products for visible signals: a broken destination, a price that differs from the page, missing variant details, thin product data, or a catalog that cannot explain its own identifiers.

Send a short teardown with five fields:

one product URL or public catalog sample;
the visible issue and the page element that supports it;
the Merchant Center field likely involved;
the fixed $1,199 offer and its 100-SKU boundary;
and the client input needed before work begins.

Use public product pages and a fictional feed row in the sample. Keep account screenshots, product exports, and supplier identifiers private. A teardown should prove that the operator can connect a visible page problem to a feed field; it should not pretend to have inspected a private account.

Run the channel for 30 days:

Send five specific teardowns each week to stores with a clear catalog problem.
Offer a paid diagnostic only when the buyer has account access and a named decision-maker.
Track replies, qualified calls, paid projects, approval delays, unresolved rows, and revision hours.
Publish one redacted before-and-after correction map each week.
After 20 qualified conversations, keep the package if buyers pay for the bounded repair or if the objections identify one boundary you can fix.

The test measures whether the problem is visible and urgent. It does not promise a conversion rate or restored revenue.

Revenue model

Treat the first version as a one-time project. A clean feed creates recurring work only when the catalog changes, a new country launches, or the owner has a real monitoring need.

Assumptions:

Price: $1,199 before tax, payment fees, and software.
Delivery: 12 hands-on hours across seven business days.
One account, one source, one country, 100 active SKUs, five issue classes.
The client supplies access, the product export or feed URL, and policy decisions.
The operator diagnoses, corrects, tests, documents, and hands off.
The client pays for any third-party connector or feed platform it chooses.

Loading stats card…

At one project, you are testing whether a store owner will pay for diagnosis, controlled corrections, and a usable evidence packet. At two, the planned delivery load is 24 hands-on hours, leaving room for five outreach messages each week, admin, and client waiting time. At three, the planned load reaches 36 hours. That can fit a solo operator while the catalog boundary stays firm.

An optional follow-on can be Feed Watch — $299 per month. The service checks one account and one country once each week, reviews new warnings or disapprovals, and sends a short action note. The client owns any product edits, connector cost, and policy decision. Sell the follow-on only when the catalog changes often enough to create a real checking job. If the catalog stays stable, the honest recurring revenue number is zero.

Scaling ceiling

The first ceiling is data ownership. A feed is easy to correct when the store knows which source owns price, stock, identifiers, images, shipping, and returns. A feed becomes a strategy project when nobody can answer those questions.

Move 1: choose one store situation

Start with one buyer situation: Shopify apparel stores with variant errors, WooCommerce brands with price mismatches, or small agencies that need a clean handoff before launching Shopping campaigns. A narrow situation gives you repeatable samples and a shorter intake form.

"I optimize product feeds" is broad. "I repair up to 100 Shopify apparel SKUs with variant and price issues in seven business days" names the buyer, the failure, and the boundary.

Move 2: separate row collection from policy judgment

A contractor can collect product URLs, compare feed rows with pages, label missing fields, and prepare a correction sheet. The operator keeps issue classification, identifier judgment, shipping and returns questions, final approval, and the handoff.

Pay for a completed evidence packet rather than an undefined block of spreadsheet hours. The packet should contain the source row, page URL, observed mismatch, proposed correction, client decision, and test result.

Move 3: add a larger catalog tier

Keep $1,199 for 100 SKUs and five issue classes. Add a separate Catalog Repair — $2,499 tier only after three projects show the same expansion: up to 500 SKUs, one source, one country, ten issue classes, and a 14-day monitoring period. The larger tier needs its own sampling rule and correction map.

Do not put 500 products into the entry package because the source looked easy on Day 1. The correction unit is a product attribute, and the number of attributes rises with variants, countries, and platforms.

Loading stats card…

A sensible early ceiling is three repair projects per month until the correction map, QA sample, and client-wait rule are stable. The next move is a separately priced catalog tier or a small specialist team. The next move is not unlimited monitoring inside the original $1,199 price.

Keeping clients and staying sane

A feed repair has natural project churn. A client may need another paid engagement when the catalog expands, a country changes, a supplier adds variants, or a platform migration changes the source. A stable catalog has no honest reason to buy another repair every month.

Name the next legitimate trigger during handoff. If the client adds a country, launches a second store, changes its product platform, or sees a new issue class, offer Feed Watch or a new repair project. If the client has no change, close the project cleanly and ask for an introduction.

The burnout risk is invisible catalog growth. A client says the store has 80 products, then reveals 80 parent products with 260 variants, three markets, and a second feed. Count the actual active SKUs and countries before accepting payment. Put the count in the quote.

Policy risk needs the same discipline. A product-level issue is a repair candidate. An account suspension, a misrepresentation review, or an uncertain regulated-product decision needs a broader specialist process. The operator can document the evidence and refer the decision without promising approval.

AI and platform automation weaken the cheapest part of the offer. Google can extract product information from structured data, update some item fields, remove certain image overlays, and improve delivery estimates when the relevant settings are enabled. 6 Feed platforms also advertise AI title generation and attribute extraction as ways to fill catalog gaps, as Feedoptimise describes in its Google Shopping integration page. 7

The human work remains visible in the correction map:

deciding which product source is authoritative;
separating a true mismatch from a deliberate sale or low-stock rule;
preserving variant relationships and stable IDs;
identifying when an identifier is unknown rather than guessing one;
checking the store's shipping, returns, and country rules;
and explaining what the client must change after the operator's access ends.

The defensible product is a bounded answer to one operational question: which catalog values are blocking this store's products, who owns each correction, and what evidence shows the repair?

How to start this week

Monday: choose the store situation

Pick one buyer and one failure, such as Shopify apparel stores with variant or price issues. Write the offer in one sentence:

I repair up to 100 active SKUs in one Google Merchant Center feed, one country, and five issue classes in seven business days for $1,199.

Tuesday: write the boundary

List the required access, one-country rule, 100-SKU cap, five-issue limit, client decisions, revision round, defect window, suspension exclusion, and platform-integration exclusion. Put the price beside the delivery window.

Wednesday: build the delivery kit

Create the intake form, issue export template, correction map, product-sample checklist, source-change log, resubmission checklist, QA packet, handoff agenda, and change-order sentence. The first client should not be the first time you decide how to record a mismatch.

Thursday: make three proof samples

Create three fictional cases: a price mismatch, a missing identifier, and a broken product link. Show the source row, the product page observation, the correction owner, and the proof of completion. A clean evidence packet is stronger proof than a generic dashboard screenshot.

Friday: send five teardowns

Find five stores with public product pages and a visible catalog issue. Send one specific observation and ask whether the owner wants a fixed-scope feed repair. Keep the message about the observed failure, not about guaranteed Shopping performance.

Saturday: run your own QA

Test the sample correction map, count variants correctly, verify the URLs, check the currency format, and rehearse the handoff. Write down the exact evidence a client will receive.

Sunday: publish and review the signal

Put the price, 100-SKU cap, seven-day window, client inputs, and exclusions on one page. Review every reply for four signals: a visible issue, account access, a named decision-maker, and a catalog that fits one country and one source.

The business stays small by design: one account, one feed, one country, five issue classes, one repair cycle, one evidence packet. Keep that boundary until buyers show you which larger catalog problem deserves its own offer.

References

1
Product data specification - Google Merchant Center Help
support.google.com
2
Google Merchant Expert Cost Breakdown 2026
fiverr.com
3
Google Merchant Center Management Services | Expert Feed Team | ZATO
zatomarketing.com
4
Shopping Feed Optimization | Google Shopping Feed Management Services - OuterBox
outerboxdesign.com
5
Issues in Merchant Center - Google Merchant Center Help
support.google.com
6
Enable automatic improvements | Content API for Shopping
developers.google.com
7
Google Shopping Feed Management & Optimisation - Feedoptimise
feedoptimise.com