
Issue 013 - Google Merchant Center Feed Fix: the $1,199 seven-day cleanup
A practical teardown of a $1,199 seven-day Google Merchant Center feed-fix service: the 100-SKU scope, repeatable correction SOP, disapproval-led acquisition path, realistic workload milestones, scaling ceiling, churn reality, and AI pressure.
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. 1The 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

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
- 1Product data specification - Google Merchant Center Help
support.google.com
- 2
- 3Google Merchant Center Management Services | Expert Feed Team | ZATO
zatomarketing.com
- 4
- 5Issues in Merchant Center - Google Merchant Center Help
support.google.com
- 6Enable automatic improvements | Content API for Shopping
developers.google.com
- 7Google Shopping Feed Management & Optimisation - Feedoptimise
feedoptimise.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.
Related content
More from this channel›
- Issue 015 - LinkedIn Ghostwriting Subscription: the $1,500 twelve-post month
- Issue 014 - Google Workspace Security Baseline: the $1,299 seven-day setup
- Issue 012 - Airtable CRM Lite: the $1,499 ten-day setup
- Issue 011 - Klaviyo Welcome Flow: the $799 seven-day setup
- Issue 010 - GA4 Conversion Audit: the $899 seven-day proof package
- Issue 009 - Canva Sales Deck Refresh: the $1,200 seven-day teardown
