Kivora Operations Team · Reviewed by Kivora
What Google Merchant Center requires of a South African online store
Updated 2026-08-22 · 6 min read
Quick answer
Google will suppress every product from a store it cannot identify. Publish the legal seller name, a physical address and a contact route on the site itself; match those exactly in Merchant Center's business information; claim the website; and make the product data in your feed agree with the landing page it points at. Most suspensions labelled Misrepresentation are about missing business identity rather than anything to do with the products.
Misrepresentation is the policy that catches stores nobody would call dishonest. It is not primarily about false claims; it is about whether a stranger arriving from a search result can tell who they are buying from and how to reach them. A store can be entirely legitimate, sell real stock at fair prices, and still be suspended because none of that is stated anywhere a crawler reads.
The checks are automated, and they read the served HTML rather than the page a shopper sees after JavaScript runs. That distinction catches a lot of modern storefronts: a footer rendered by a framework after boot is invisible to the check, so a site can display its address to every human visitor and publish none to Google.
Say who the seller is, on the site
The legal entity accountable for the sale needs to appear on the storefront, not only in the payment provider's records. That means the registered company name, a physical address, and at least one contact route a person actually answers.
If the shop trades under a brand that differs from the legal entity — a storefront name operated by a parent company — say so plainly. A trading name presented as the seller, with the real seller named nowhere, is the exact pattern the policy describes.
- Registered company name, not only the shop's brand
- A physical address, not a PO box alone
- An email address or phone number that reaches a person
- A contact page reachable from every page, not buried in a footer link
Publish policies that point somewhere real
Terms, privacy, shipping and returns pages are expected. The common failure is subtler than missing them: policy pages that tell the shopper to use 'the contact details shown on this store' when the store shows none. A promise that resolves to nothing reads worse than silence.
South African stores have two statutory anchors worth stating explicitly, because shoppers and reviewers both look for them: the seven-day cooling-off right for eligible online purchases under the Electronic Communications and Transactions Act, and the Consumer Protection Act's implied warranty on defective goods.
- Terms, privacy, shipping and returns, each at its own address
- A returns window stated as a number of days
- Contact details that appear on the page the policy points at
Make Merchant Center agree with the site
The business information in Merchant Center is cross-checked against the storefront. Business name, address, customer-service email, phone and contact URL should be identical in both places — not merely similar. A lowercase brand token in one and a registered entity in the other is a mismatch a reviewer can see at a glance.
Claim and verify the website. Verification by meta tag is generally safer than a DNS TXT record on a wildcard subdomain, where adding a record can stop the wildcard answering for that host at all.
- Business name matching the legal entity on the site
- Address matching the site character for character
- Customer-service email, phone and contact URL populated
- Website claimed and verified
Product data has to match the landing page
A feed that disagrees with the page it links to is a data-quality problem that reads as misrepresentation. The frequent causes are structural rather than careless: a feed uploaded by hand drifts from the shop the moment it is uploaded, so a scheduled fetch of a live feed is more reliable than a periodic CSV.
Brand is the attribute most often wrong. It must be the manufacturer, never the shop, unless the shop genuinely made the product. A reseller publishing its own name as the brand of a third-party product is making a false claim about who made the goods. Where a product has no brand at all and the retailer is its only seller, Google's own guidance permits the store name — the ordering is what keeps the two apart.
Unique product identifiers follow a rule that reads backwards: omitting identifier_exists means 'yes'. An item only has unique identifiers when it carries GTIN plus brand, or MPN plus brand, so anything short of that must declare 'no' rather than stay silent.
- Prefer a scheduled fetch of a live feed over manual uploads
- Brand is the manufacturer; omit it rather than substituting the shop
- Submit real GTINs where the product has one
- Declare identifier_exists: no unless brand and an identifier are both present
Two things that suspend accounts faster than misrepresentation
Promotional overlays on product images are prohibited. A supplier's marketing flyer used as the product photograph — a starburst badge, a price flash, a page border — is a disapproval waiting to happen, and it is easy to inherit without noticing when images arrive from a supplier feed.
The counterfeit policy is harsher than any other and worth reading carefully. Terms like replica, knock-off, imitation or clone used near a brand name are prohibited outright, and Google states it suspends on detection without prior warning. Labelling something a replica does not mitigate the problem; the word beside a marque is itself the violation. If a product is officially licensed, the brand attribute should still name the actual manufacturer rather than the licensor.
- No promotional text, badges or watermarks on product images
- No replica, knock-off, imitation or clone near a brand name
- Licensed goods: manufacturer in the brand field, not the licensor
Fixing it, and asking for the review
Nothing is re-checked automatically. After the site and the account agree, the review has to be requested from the issue itself, and it typically takes a few days. Requesting before the work is finished spends a review cycle and, for some policies, triggers a cooling-off period before another can be requested.
Verify the fix the way the checker sees it, by reading the served HTML rather than the rendered page. If the identity block only exists after JavaScript runs, the check will not find it.
- Finish the site work before requesting the review
- Confirm identity appears in the served HTML, not only after boot
- Request the review from the account issue, then wait
How this guide was prepared
Prepared from Google's published Merchant Center policies and from remediating a live South African account through a Misrepresentation review, including the Merchant API responses that showed which checks the account was failing. It is operational guidance, not legal advice, and Google's policies change: treat the linked policy pages as the authority.