Common mistakes when setting up Google Merchant Center

Common mistakes when setting up Google Merchant Center

Setting up Google Merchant Center can look simple: create an account, verify a website and add products. In practice, a reliable setup depends on many connected details. The public store, business identity, policies, WooCommerce catalogue, product data source, shipping settings and checkout must describe the same real commercial operation. When these details conflict, products may receive warnings or disapprovals, and account-level concerns may also arise.

This guide explains the mistakes WooCommerce merchants most often make before and during Merchant Center setup. It is written especially for e-commerce sites operating in Türkiye, including stores based in İstanbul, Ankara, İzmir, Bursa, Antalya and other cities, while the review principles are also relevant to merchants serving other supported countries.

The objective is not to find a shortcut to approval. It is to build a transparent store, accurate product data and a purchase journey that customers can trust. Google makes the final decision about product eligibility and account status. A local audit can reduce preventable errors, but it cannot guarantee approval.

Why Merchant Center setup errors are often connected

A price mismatch may begin with a WooCommerce sale schedule, a cache delay or an outdated data source. An address conflict may come from a footer edited years ago while the Contact page and Merchant Center contain newer information. A shipping error may arise because the website promises free delivery while Merchant Center still applies a charge. The visible warning is therefore not always the complete cause.

Review the setup as one system. Compare what the customer sees, what WooCommerce stores, what the product source submits and what Merchant Center is configured to expect. Correcting only one screen while leaving the underlying inconsistency in place can cause the issue to return.

Mistake 1: Creating Merchant Center before the store is genuinely ready

Some merchants open an account and submit products while the website is still in maintenance mode, policy pages contain placeholder text, products cannot be purchased or contact details are incomplete. A visually attractive homepage does not mean the commercial journey is ready.

Before adding products, browse the store while logged out. Open product pages, add different product types to the cart, calculate delivery, proceed through checkout and inspect confirmation messages. Repeat the test on mobile. Remove demo pages, unfinished menu links, default theme content and unavailable test products.

A ready store should clearly show who sells the products, how customers can make contact, what they will pay, when delivery is expected and what happens if they wish to return an order. The answers must remain accessible before payment.

Mistake 2: Using inconsistent business names, addresses or contact details

Different business identities across the footer, Contact page, policy pages, invoices and Merchant Center can make the store difficult to understand. This sometimes happens when a trading brand differs from the registered company name, when a website has changed ownership or when an old agency template remains on one page.

Create a simple identity inventory. Record the customer-facing brand, legal seller, full address, telephone number, email address and support hours. Compare every public occurrence. If the legal company and brand have different names, explain their relationship naturally. If the registered office, warehouse and return address differ, label the purpose of each address rather than presenting unexplained alternatives.

For businesses in Türkiye, use a complete and readable address structure appropriate to the real location. Do not add İstanbul, Ankara or another city merely to create a GEO signal. Location information must represent the actual business or service operation.

Mistake 3: Hiding essential contact information

A contact form alone may not give customers enough confidence, especially if it does not confirm submission or the messages are not monitored. Social media icons and messaging applications are useful additions, but they should not conceal the responsible business or replace dependable contact channels.

Publish a working email address and appropriate telephone information, then test both. Submit the form from a private browser, check delivery, review spam handling and confirm that validation errors are understandable. Keep the Contact page and footer accessible on mobile. A link that exists but cannot be used is not a completed contact method.

Mistake 4: Treating policy pages as decorative templates

Merchants sometimes create Privacy, Returns, Shipping and Terms pages only to satisfy a checklist. The pages then contain another company’s name, foreign currencies, impossible deadlines, irrelevant laws or processes the store does not follow. This creates more inconsistency rather than more transparency.

Every policy must describe the real operation. The shipping page should explain destinations, charges, handling and estimated delivery. The return and refund page should state applicable conditions, periods, steps, costs and the return destination. The privacy page should reflect the actual forms, checkout, analytics, cookies and service providers used by the site.

Place core policy links where customers can find them easily, commonly in the footer and at appropriate points in checkout. Review them on mobile and in every active language. PW Merchant Check may detect whether a likely page exists, but automatic detection cannot certify its legal completeness or factual accuracy. Qualified local advice may be necessary.

Mistake 5: Making shipping promises that do not match checkout or Merchant Center

Shipping is often configured in three places: WooCommerce zones and methods, public policy text and Merchant Center settings. A store may advertise free delivery above a threshold while checkout applies a fee, or Merchant Center may use a flat charge that does not match the amount customers see.

Test representative destinations, including remote or differently priced regions when relevant. Check small and large orders, free-shipping thresholds, coupons, taxes and product-specific classes. Record the final charge and delivery expectation. Then compare those results with the public policy and Merchant Center configuration.

Google’s official shipping guidance requires complete and correct shipping information, including relevant charges and speed. Do not publish an attractive delivery promise that operations cannot consistently meet. See the official shipping attribute guidance.

Mistake 6: Publishing unclear or contradictory return information

A return policy may say “easy returns” without explaining the procedure, while another page states that no returns are accepted. Merchant Center settings may describe a different window or customer cost. Customers should not have to discover the real terms after purchasing.

Review the return window, eligible and excluded products, product condition, exchange options, refund method, processing time, return shipping cost and address. Ensure that customer support follows the published process. If different countries or product categories have different rules, present the differences clearly rather than combining them into ambiguous wording.

Mistake 7: Running duplicate or conflicting product data sources

WooCommerce stores frequently accumulate several submission methods over time: an old plugin, scheduled XML file, spreadsheet, website crawl and a newer API integration. If the same products remain active in multiple primary sources, merchants may see duplicates, conflicting updates or uncertainty about which source controls the current offer.

List every active product source in Merchant Center and identify its owner, update schedule, countries, languages and product IDs. Decide which source is authoritative. Do not delete an old source blindly; first confirm that the replacement supplies every required product and that its identifiers, destinations and update behaviour are correct. Then retire the obsolete path in a controlled way.

Stable product IDs are important because changing IDs unnecessarily can break continuity. When moving from a legacy feed to an API solution, plan the transition rather than operating both indefinitely without a defined purpose.

Mistake 8: Allowing submitted price to differ from the landing page or checkout

Price mismatches can be caused by cached pages, expired sales, currency conversion, tax display rules, variation selection, member pricing or delayed updates. The product source may send one amount while the landing page initially displays another, and checkout may calculate a third.

For each affected product, compare the submitted price and currency with the default landing-page offer, structured data and checkout. Test without an administrator session. If a customer must select a variation, ensure that the submitted URL and product data consistently represent that variation. Do not submit a promotional price that is no longer available.

The official product data specification states that price and currency should match the landing page, structured data and checkout. Fix the source of the discrepancy, clear relevant caches and allow the authorised product source to update before requesting a review.

Mistake 9: Submitting unavailable products as in stock

A product can appear “in stock” in exported data even when it is backordered, disabled, missing a purchasable variation or restricted by an extension. Conversely, a real product may be available in WooCommerce while a stale data source still reports it as out of stock.

Check stock management at both parent and variation level. Test whether a new customer can add the exact submitted offer to the cart and continue to checkout. Explain legitimate preorder or backorder conditions accurately. Do not use an in-stock value merely to increase visibility when fulfilment is not actually possible.

Stores with rapidly changing inventory need an update method and frequency suitable for that volatility. Scheduled synchronisation alone may be insufficient for very fast stock movement; the operational process must keep the public offer and submitted availability aligned.

Mistake 10: Sending the parent product instead of the correct variation

Variable products require careful handling. Different colours, sizes or materials may have separate prices, stock levels, GTINs and images. Submitting only a generic parent while customers must choose a materially different child option can create inaccurate or ambiguous data.

Review every submitted variation as a distinct offer where required. Use consistent grouping, unique IDs and the correct attributes. The landing page should make the advertised option easy to identify. If a blue size-medium item is submitted, the customer should not arrive at an unrelated default combination with a different price or availability.

Mistake 11: Inventing GTIN, EAN, MPN or brand information

Some store owners enter a random barcode, internal SKU or repeated placeholder because an identifier field appears compulsory. This is worse than accurately representing a product that genuinely has no manufacturer-assigned GTIN.

Use the valid GTIN or EAN assigned to the exact product by its manufacturer. Do not convert an internal SKU into a GTIN and do not reuse one identifier across unrelated variations. For products without a manufacturer-assigned GTIN, follow the current requirements for brand and MPN or the appropriate custom-product treatment.

Google’s official GTIN guidance explains why valid identifiers matter. PW Merchant Check can flag missing or suspicious catalogue fields, but it cannot independently prove that a number belongs to the physical product. Verify identifiers from reliable manufacturer or supplier records.

Mistake 12: Using weak, misleading or inaccessible product images

Common image problems include placeholders, watermarks, promotional text, broken URLs, very small files, incorrect variation images and pictures that do not clearly show the product. A theme may display an image correctly to the administrator while a crawler or logged-out customer receives an access error.

Open the submitted image URL directly in a private browser. Confirm that it returns the intended image without authentication, temporary tokens or blocking. Use a clear primary image that accurately represents the offer, then add useful alternative views where available. Check that variation images match the selected colour or model.

Image requirements can change, so review the current official specification rather than relying on an old blog post. In particular, merchants should plan for Google’s announced minimum 500 × 500 pixel requirement for product images from 31 January 2027, while also preserving truthful, high-quality presentation.

Mistake 13: Writing vague, copied or exaggerated product content

Manufacturer text copied unchanged across many stores gives customers little reason to trust or understand the specific offer. Extremely short titles may omit the product identity, while keyword-heavy titles and unsupported claims can mislead. Descriptions that promise functions, certifications or results the product cannot deliver create a more serious problem than weak SEO.

Write a precise title using the brand, product type, model and meaningful variant details where appropriate. Describe the real material, dimensions, use, included items and limitations. Keep the landing page and submitted data consistent. Avoid false urgency, fabricated discounts, unverified awards and superlatives that cannot be substantiated.

Mistake 14: Blocking Google or customers with technical restrictions

Maintenance mode, password protection, robots directives, firewall rules, country blocks, cookie overlays and aggressive bot challenges can make important pages inaccessible. Server errors or redirect loops may occur only for logged-out visitors, mobile users or particular locations.

Test the homepage, product, image, policy, cart and checkout URLs from a private browser and, where possible, another device or network. Review HTTP responses, redirects, canonical URLs and WordPress search-engine visibility. Security controls are necessary, but they should be configured so legitimate customers and permitted crawling can reach the commercial content.

Mistake 15: Assuming HTTPS alone proves the store is trustworthy

A valid certificate protects data in transit; it does not prove who operates the store, whether products exist or whether policies are honest. Some merchants install HTTPS and consider the trust review complete while leaving anonymous contact details, impossible claims or broken checkout steps.

Use HTTPS across the entire journey and correct mixed content, but also review seller transparency, real support channels, policy accuracy and operational reliability. Google’s guidance on building customer trust emphasises clear business information, policies and a usable checkout experience.

Mistake 16: Failing to test checkout as a real customer

Perform at least one end-to-end test using a supported payment method or a controlled test environment that reflects production accurately. Test guest checkout if offered, error messages, coupon behaviour, order confirmation and transactional email. Confirm that the final price, currency, shipping charge and product selection match what the landing page promised.

Mistake 17: Ignoring mobile usability

Review the complete customer journey on a real phone, not only a resized browser window. Check menus, filters, variation selectors, image galleries, policy links, cart totals, payment controls and form validation. Mobile usability is part of the commercial experience, not a cosmetic afterthought.

Mistake 18: Mixing currencies, languages or target countries

A Turkish store may show TL on the product page while the data source submits another currency, or a translated landing page may redirect to the default language. Shipping and return information may be valid only for Türkiye even though products target additional countries.

Define the intended country, language and currency for each offer. Confirm that the landing page remains accessible in that combination and that checkout supports the promised destination. Translate essential commercial information completely; a translated product title leading to untranslated or contradictory policies is not a finished market experience.

Mistake 19: Changing product IDs unnecessarily

Product IDs should remain stable for the same offer. Regenerating them after every synchronisation, migration or minor edit makes management more difficult and can disrupt historical continuity. At the same time, reusing one ID for a different product is also incorrect.

Document how IDs are generated and preserve that method when changing integration tools. Map existing products carefully during migration. Give each submitted variation the correct unique identity without turning titles, prices or timestamps into unstable identifiers.

Mistake 20: Requesting a review before corrections have propagated

After receiving a warning or suspension, merchants sometimes make one visible edit and immediately request another review. The product source may not yet be updated, cached pages may still show old content and related problems may remain elsewhere on the site.

Read the current Merchant Center message and relevant official policy. Audit the whole affected journey, correct the underlying causes, update the product data and verify the live public result. Google’s review guidance recommends resolving the issue comprehensively before requesting review or appeal.

PW Merchant Check cannot see the account message because it does not connect to Google. Use the exact account diagnosis as the starting point, then use local site and catalogue checks to investigate related conditions.

A practical correction order

1. Restore public access to the store, products, policies, cart and checkout.
2. Confirm the real seller identity, address and working contact methods.
3. Remove false claims, placeholders and products that cannot be purchased.
4. Align price, currency, availability and variations from source to checkout.
5. Correct shipping, returns, privacy, payment and terms information.
6. Verify identifiers, images, titles, descriptions and stable product IDs.
7. Review every active data source and retire obsolete duplicates carefully.
8. Test desktop and mobile customer journeys while logged out.
9. Update the authorised source, verify propagation and only then consider review.

How PW Merchant Check helps

PW Merchant Check is a free local preparation and audit plugin for WordPress and WooCommerce. It brings site, product and misrepresentation-readiness checks into one structured workflow. Findings can help a merchant notice missing pages, incomplete product fields, price or availability concerns, image issues and other areas that deserve manual review.

The plugin does not require a licence, quota, Pro package, Google API connection or Merchant Center authorisation. Data inspected for the audit is not sent to PW Feed or Poyraz Web for the purpose of the scan. Users can make corrections, repeat the check and create an HTML report for internal review.

Automatic inspection has limits. Custom themes, page builders, multilingual systems and unusual product structures may cause false positives or prevent detection. A page can be found automatically but still contain inaccurate information. A valid custom page may exist even if its title is not recognised. Every important result should therefore be confirmed manually on the public store.

What PW Merchant Check cannot do

• It cannot approve a Merchant Center account or guarantee approval.
• It cannot read private account diagnostics, review outcomes or product status.
• It cannot submit or synchronise products like the separate PW Merchant API solution.
• It cannot prove that business statements or identifiers are genuine.
• It cannot replace legal, tax, consumer-protection or compliance advice.
• It cannot replace a complete manual customer-journey and operational test.

Frequently asked questions

What is the most common Merchant Center setup mistake?

There is no single cause for every store, but incomplete preparation and inconsistency are recurring themes. Business details, policies, product data and checkout should describe the same real offer.

Does a WordPress plugin guarantee Merchant Center approval?

No. A plugin can help detect or manage information, but Google applies its own policies and makes the final decision. Any promise of guaranteed approval should be treated cautiously.

Can I use two product sources at the same time?

Different sources may have legitimate purposes, but submitting the same offers through overlapping primary sources without a clear plan can create duplication and conflicts. Identify the authoritative source and control the migration carefully.

Should I delete my old data source immediately?

Not without verification. First confirm that the replacement contains all intended products, correct IDs and current information. Then retire the obsolete source in a controlled sequence.

Why does Merchant Center show a different price?

Possible causes include cache, delayed synchronisation, currency conversion, taxes, expired sales or variation pricing. Compare submitted data, the logged-out landing page, structured data and checkout.

Must every WooCommerce product have a GTIN or EAN?

No. Requirements depend on whether the manufacturer assigned an identifier and on the product type. Use the genuine identifier when one exists and never invent one.

Can PW Merchant Check read my Merchant Center suspension reason?

No. It has no Google API or OAuth connection. Read the diagnosis within Merchant Center, then use the plugin to inspect related local website and product conditions.

Is the PW Merchant Check readiness score a Google score?

No. It is a local preparation indicator based on detectable signals and user confirmations. It is not an approval score, account status or guarantee.

Are policy templates sufficient?

Only after careful adaptation and appropriate review. They must accurately describe the actual seller, fulfilment, returns, payments, privacy practices and applicable market.

Why should I test while logged out?

Administrators may bypass cache, maintenance rules or security restrictions. A logged-out test is closer to the experience of a new customer and permitted crawler.

How often should I audit the store?

Repeat the review after changes to the theme, checkout, currency, shipping, policies, product source or business details, and before requesting a new account review.

Is PW Merchant Check the same as PW Merchant API?

No. PW Merchant Check is a free local preparation tool. PW Merchant API is a separate solution designed for authorised product submission and management. The two products serve different purposes.

Final reminder

Successful preparation comes from consistency and evidence. The business must be identifiable, products must be purchasable, policies must reflect reality, and submitted data must match what customers see through checkout. Correct foundations first, then deal with smaller optimisation opportunities.

Use PW Merchant Check to organise local inspection, but confirm every critical finding manually and follow the current instructions displayed in Merchant Center. The plugin is independently developed and is not created, endorsed or approved by Google.

PW Merchant Check and this guide are preparation resources; they do not provide a Google approval score or approval guarantee.