Preparing a WooCommerce store for Google Merchant Center is not limited to installing a product integration or uploading a catalogue. The website, business identity, customer information, policies, product offers and checkout journey must tell the same clear and credible story. A preventable inconsistency can affect customer confidence and may also create product or account-level problems.
This 25-point checklist gives e-commerce site owners a practical review order before opening an account, submitting products or requesting another review. It is especially useful for WooCommerce stores operating in Türkiye, including businesses serving İstanbul, Ankara, İzmir, Bursa, Antalya and other cities, but the core principles also apply to merchants targeting other supported markets.
Complete every item using the public storefront, not only the WordPress administration screen. Open the site as a logged-out visitor, test it on desktop and mobile, and record evidence such as the page URL, test date and responsible person. A checked box should mean that the condition has been verified, not merely assumed.
Important limitation
This checklist is a local preparation resource. It is not a Google approval checklist, legal certificate or guarantee. Google applies its own policies and makes the final decision about products and accounts. PW Merchant Check is independently developed, does not connect to Merchant Center and cannot read Google’s account diagnostics or private review signals.
How to use this checklist
- Assign one responsible person to coordinate the review.
- Mark each item as verified, unresolved or not applicable.
- Add a note explaining why an item is not applicable.
- Correct critical identity, accessibility, price and checkout problems first.
- Run PW Merchant Check again after changes are published.
- Perform a final manual test before applying or requesting review.
Do not treat the list as a race to reach 25 ticks. A single unresolved problem involving the real seller, an unavailable offer or a broken checkout may deserve more attention than several minor presentation improvements.
Business identity
1. Confirm the real business name
☐ The public website clearly identifies the person or company responsible for selling the products.
Compare the name in the header or footer, About page, Contact page, policy pages, invoices, payment records and Merchant Center business information. Use the genuine registered or trading name that customers will recognise. Do not present a web agency, hosting company, supplier or marketplace as the seller unless that entity truly operates the store.
If the legal name and customer-facing brand differ, explain their relationship naturally. The objective is not to repeat registration language everywhere; it is to prevent customers from encountering several unexplained identities.
2. Publish an informative About page
☐ The About page explains who the merchant is, what the business sells and how it serves customers.
Replace template slogans and generic claims with specific, verifiable information. Mention the business activity, relevant experience, service area and genuine value offered to customers. Avoid fabricated awards, unsupported market-leader claims and copied biographies. An About page should improve transparency, not operate as a keyword container.
Address and contact details
3. Verify the complete business address
☐ A real, complete and consistently formatted business address is available where appropriate.
For an address in Türkiye, review the neighbourhood, street, building number, district, province, postal code and country. Compare every occurrence across the footer, Contact page, policies, invoices and Merchant Center. If the registered office, warehouse and return destination differ, label each purpose clearly rather than displaying apparently conflicting addresses.
4. Test the telephone number and email address
☐ Customers can reach the business through working, monitored contact methods.
Call the published number, send a message to the listed email address and confirm that the mailbox can reply. Check spelling, country code and opening hours. A contact method is not complete merely because it is displayed; it must lead to the business and support the expectations created on the site.
5. Test the Contact page and form
☐ The Contact page loads publicly, the form works and the customer receives an understandable result.
Submit the form in a private browser window. Confirm delivery, spam handling, validation, privacy notice and confirmation message. Remove fields that collect unnecessary personal information. If a map or messaging service is used, ensure it does not replace essential written contact details.
Technical accessibility
6. Remove maintenance mode and public access barriers
☐ The storefront, products, policies, cart and checkout are accessible without an administrator login.
Check for maintenance pages, coming-soon screens, password protection, staging restrictions, country blocks and security challenges that may prevent legitimate users or crawlers from accessing content. Test from a logged-out browser and, where relevant, a second network. Necessary age or legal gates should be implemented without concealing the required product information after access.
7. Confirm correct indexability and crawl access
☐ Important public pages are not accidentally marked noindex or blocked from normal crawling.
Review WordPress search-engine visibility, SEO plugin settings, robots directives and server rules. Product URLs should return a successful response and resolve to the intended canonical version. Redirect chains, repeated server errors and soft 404 pages should be corrected before products are submitted.
8. Repair broken links and placeholder content
☐ Menus, footer links, policy links, product buttons and internal references work.
Remove demo products, lorem ipsum, stock theme pages, empty social icons, unfinished sections and links that lead to errors. Review both language versions when the store is multilingual. Customers should not have to guess whether the website is operational or still under construction.
HTTPS and website security
9. Confirm HTTPS across the complete purchase journey
☐ The homepage, product pages, cart, checkout and policy pages load through valid HTTPS without mixed-content warnings.
Check the certificate, redirects from HTTP, images, scripts and third-party checkout components. Test direct product links instead of checking only the homepage. HTTPS is essential, but a padlock alone does not establish business trustworthiness; the content and purchase process must also be transparent.
Store and policy pages
10. Publish a clear privacy policy
☐ The privacy page accurately explains what data the store collects, why it is used and with whom it may be shared.
Include relevant information about orders, payments, analytics, cookies, contact forms and service providers. Replace copied names and outdated tools. The policy must reflect the site’s real configuration. PW Merchant Check can help detect the presence of a page, but it cannot certify its legal completeness.
11. Publish terms and conditions
☐ Customers can access understandable sales terms before completing a purchase.
Describe the seller, order formation, payment, fulfilment, cancellations, customer responsibilities and relevant limitations. Ensure the terms do not contradict product pages, checkout notices or policies. Obtain qualified legal advice for the jurisdictions and product categories in which the business operates.
12. Explain payment methods and charges
☐ Accepted payment methods, currencies and possible charges are clear before the final order step.
Do not advertise a payment option that is unavailable at checkout. Explain instalments, bank transfer procedures or cash-on-delivery costs accurately. Review whether tax and compulsory fees are included or disclosed as required. A customer should not encounter a surprising mandatory charge after relying on the product price.
Shipping and delivery
13. Publish a complete shipping policy
☐ The shipping page identifies destinations, methods, processing periods, delivery estimates, charges and material restrictions.
Use realistic ranges supported by actual operations. Separate order processing from carrier transit time. If delivery is limited to certain Turkish provinces, districts or postal codes, explain this before checkout. Stores targeting another country should provide market-specific information instead of relying on a vague worldwide-delivery statement.
14. Match website delivery information with Merchant Center settings
☐ Shipping cost and delivery expectations are consistent across product pages, policies, checkout and Merchant Center.
Test representative addresses and basket values. Review free-shipping thresholds, remote-area fees, oversized items and excluded destinations. Google provides official guidance for configuring shipping settings; the configuration should describe the service customers can actually receive.
Returns and refunds
15. Publish an accurate return and refund policy
☐ The policy explains the return period, conditions, method, address, costs, exclusions and refund process.
Customers should know how to start a return, who pays shipping, how long inspection may take and how approved refunds are issued. Do not copy another merchant’s address or promise a process the business cannot provide. Google also offers official information about return-policy settings in Merchant Center.
16. Verify that the published policy is operational
☐ The customer service and fulfilment teams can follow the stated return and refund procedure.
A well-written page does not solve an operational contradiction. Confirm the return destination, response mailbox, refund method and responsible staff. Review exceptions for personalised, perishable, hygiene-sensitive or regulated items with suitable professional advice. This checklist and PW Merchant Check do not provide legal certification.
Product data
17. Review product titles and descriptions
☐ Titles and descriptions identify the real product without deceptive claims, keyword stuffing or leftover supplier text.
Include meaningful attributes customers use to distinguish the item, such as brand, model, material, size or colour where relevant. Remove unsupported certifications, false scarcity and exaggerated performance statements. The product submitted to Google should be the same product customers find on the landing page.
18. Match price and currency everywhere
☐ The price and currency agree across WooCommerce, the visible landing page, structured data, product data and checkout.
Test regular prices, sale prices, variable products, taxes and customer-location behaviour. Clear caches after price changes. Google’s official product data specification requires accurate price and availability information that matches the landing page and checkout. A feed or API value should not conceal an incorrect storefront value.
19. Match availability and purchasability
☐ Products presented as in stock can genuinely be purchased and delivered to the intended market.
Check stock quantity, backorders, preorder dates, delivery restrictions and disabled purchase buttons. The selected variation must have the same availability as the corresponding submitted offer. Google states that availability should remain consistent across product data, landing pages, structured data and checkout.
20. Inspect product images
☐ Every important product has a clear, accessible image that accurately represents the item.
Open original image URLs, check mobile display and remove placeholders, promotional overlays or unrelated graphics from the main image. Review Google’s current image requirements before submission. Google has announced that from 31 January 2027 newly submitted and updated products require images of at least 500 × 500 pixels, so merchants should prepare their catalogues early.
21. Verify identifiers, brand and variations
☐ SKU, GTIN/EAN, MPN, brand and variation attributes are accurate where applicable.
Use identifiers assigned by the manufacturer; never invent a GTIN to fill an empty field. Products without manufacturer-assigned identifiers should be represented according to the applicable Google specification. Test each meaningful variation, including size, colour, price, image, stock and landing-page selection. A variable product with no purchasable variations should be corrected or excluded.
Cart and checkout
22. Complete a test purchase from product page to confirmation
☐ A customer can add the advertised item to the cart, enter an eligible address, choose delivery and payment, and reach a clear order result.
Test as a guest unless the business genuinely requires an account and that requirement is clearly communicated. Verify coupons, taxes, shipping, stock reduction, emails and payment return pages. Repeat the journey using a variation and a mobile device. Avoid requesting an external reviewer to assess a checkout that the merchant has not recently tested.
Mobile presentation
23. Review the complete storefront on mobile
☐ Essential identity, policy, product and checkout information is readable and usable on a typical phone.
Check menus, cookie notices, pop-ups, variant selectors, price placement, buttons, forms and payment frames. Important content must not be hidden behind an uncloseable overlay or broken layout. Mobile visitors should receive the same essential product and business information as desktop visitors.
Merchant Center settings
24. Verify account, domain and market configuration
☐ The intended Merchant Center account uses the correct business, verified website, language, country, currency, shipping and return settings.
Avoid creating duplicate accounts for the same business merely to escape an unresolved issue. Confirm website ownership and ensure the submitted landing-page domain matches the claimed site. Review each target market separately. If an old data source and a new API integration submit the same products, resolve duplicate submission before proceeding.
Final review
25. Run a final audit and request review only after fixes are live
☐ The store has been checked again after corrections, and every declaration is supported by the current public website and real operations.
Run the PW Merchant Check site, product and misrepresentation-readiness reviews. Investigate critical and important findings manually. Then ask someone unfamiliar with the project to browse the store as a customer; fresh eyes often detect ambiguous names, hidden policies and confusing checkout steps that the site owner overlooks.
If Merchant Center already shows an issue, read the current account message and official instructions before requesting another review. Do not repeatedly request review without correcting the underlying cause. PW Merchant Check cannot see that account message because it works locally without Google API or OAuth access.
Recommended correction priority
- Restore public access, HTTPS and working product or checkout pages.
- Correct the seller’s identity, address and contact methods.
- Remove unavailable products, false claims and price or stock conflicts.
- Publish accurate shipping, return, refund, privacy and payment information.
- Repair product identifiers, images, variants and mobile presentation.
- Align Merchant Center settings and data sources with the live store.
- Run a new audit and complete an independent final customer-journey test.
How PW Merchant Check supports this process
PW Merchant Check is a free WordPress and WooCommerce preparation tool. It brings site-level, product-level and misrepresentation-readiness checks into a structured local workflow. Findings are grouped by importance so a merchant can decide where to begin, make corrections and run the inspection again.
The plugin does not require a licence code, Pro package, Google API connection or Merchant Center authorisation. Audit data is evaluated within the WordPress environment and is not sent to PW Feed or Poyraz Web for the purpose of the scan. An HTML report can help document the review or share findings with the person responsible for corrections.
Automatic detection is not infallible. A custom theme, page builder, multilingual route or unusual checkout can produce a result that needs manual interpretation. A detected policy page may still contain inadequate information, while a valid custom page may not be recognised automatically. Always verify findings on the live public site.
What PW Merchant Check cannot do
- It cannot approve a Merchant Center account or guarantee approval.
- It cannot read account diagnostics, product disapprovals or review outcomes.
- It cannot prove that a business declaration is true.
- It cannot replace legal, tax, consumer-protection or compliance advice.
- It cannot submit or synchronise products as the separate PW Merchant API solution does.
- It cannot replace a real checkout test or manual inspection.
Frequently asked questions
Should I complete all 25 items before opening Merchant Center?
You should resolve every applicable item that affects transparency, accessibility, product accuracy and purchasing. Some settings can only be completed inside Merchant Center, but the website and operational foundations should be ready first.
Does completing the checklist guarantee approval?
No. It reduces avoidable local weaknesses and creates a more disciplined preparation process, but Google alone determines eligibility and approval.
Can PW Merchant Check see why my account was suspended?
No. It does not connect to Merchant Center. Read the issue details inside the account and use the plugin to inspect related website, policy and product conditions locally.
Is a high readiness score enough?
No. The score is a local indicator based on detectable signals and user answers. It is not a Google score. Review every unresolved finding and verify declarations manually.
Do I need Google API access to use the checklist?
No. The checklist and PW Merchant Check can be used before any Google connection. Account-level diagnostics remain available only through Merchant Center or an authorised integration.
Which problems should I correct first?
Prioritise inaccessible pages, unclear seller identity, broken contact methods, unavailable offers, incorrect price or stock, missing core policies and failed checkout. These affect the basic customer journey.
What if my warehouse and registered address differ?
Use genuine information and label the purpose of each address clearly. Do not make separate legitimate locations look like contradictory versions of one address.
Must every product have a GTIN?
No. Requirements depend on whether the manufacturer assigned identifiers and on the product type. Never invent a GTIN. Follow the current official product data specification.
Should policy pages be copied from another store?
No. Policies must describe the merchant’s real identity, fulfilment and customer-service processes. Generic templates require careful adaptation and may need qualified legal review.
How often should I repeat the checklist?
Repeat it after major theme, checkout, policy, catalogue, currency, shipping or business-information changes, and before submitting products or requesting another review.
Can I use the checklist for stores outside Türkiye?
Yes, but adapt policies, taxes, consumer information, shipping and market settings to the target country. Local professional advice may be necessary.
Is PW Merchant Check the same as PW Merchant API?
No. PW Merchant Check is a free local preparation and audit tool. PW Merchant API is a separate solution for authorised product-management and synchronisation workflows. Their purposes should not be confused.
Final reminder
A reliable Merchant Center preparation process is built on evidence: a real seller, working contact methods, truthful policies, accessible products, matching price and availability, and a checkout that performs as promised. Use the 25 items to find gaps before they reach customers or become harder to diagnose.
This checklist and the PW Merchant Check readiness result are local preparation aids; neither is a Google approval score or guarantee.