Google Merchant Center on WordPress Without WooCommerce

Every guide to Google Shopping on WordPress starts with the same step: install Google for WooCommerce. That plugin’s own listing sets out what it needs, and the list includes WooCommerce 11.0 or greater (the plugin’s page on WordPress.org).

So if your site sells through Easy Digital Downloads, an embedded cart from another service, a booking plugin, a membership plugin, or product pages with a payment link, that route is closed. Four others are open, and none of them needs WooCommerce.

Route 1: let Google read your product pages

The least work, and the route most WordPress sites should try first. You add your site as a data source and Google collects the products itself. Google describes what it reads: We read the structured data on those pages to understand product details like title, price, and availability (Google’s page on adding products automatically from your online store). It says it checks your website at least once every 24 hours.

Which makes your product markup the whole job. On a WordPress site without WooCommerce, nothing writes Product structured data for you: not the theme, and not most SEO plugins, which mark up articles and pages rather than products. So each product page needs its own Product markup with, at minimum, a name, an image and an offer carrying a price and a currency.

Two conditions that catch people here. Google requires a price above zero for merchant listings, so “price on request” pages don’t qualify. And the markup has to be in the page Google receives: Google warns that markup written by JavaScript can't be generated with JavaScript after the page has loaded for Merchant Center’s automatic updates (Google’s page on structured data for Merchant Center). An embedded cart that draws its prices in after load is exactly that case.

Our post on merchant listing structured data issues goes through the properties and which ones actually matter.

Two other things this route needs: your site verified and claimed in Merchant Center, and Googlebot allowed in. A robots.txt left over from a staging site, or a “discourage search engines” setting still ticked in WordPress under Settings → Reading, will stop the crawl without any obvious error.

Route 2: a file

A CSV, TSV or XML file that Merchant Center collects on a schedule. Google’s page on adding products from a file covers the formats and the required columns.

On WordPress without WooCommerce, nothing generates that file, so you either export it from whatever holds your products or write it by hand. Two rules to know first: Google says Scheduled updates only appear for scheduled fetch and Google Sheets data sources. and that pointing to an HTML page of your website will cause the processing of your product data source to fail (Google’s page on scheduled updates). A link to your shop page is not a feed.

Route 3: a Google Sheet

The same idea, maintained in a spreadsheet, which Google syncs on a default schedule of every 24 hours. For a handful of products that rarely change price, this is the pragmatic answer: no plugin, no developer, no file hosting.

It stops being pragmatic at the point where someone has to remember to update it. Products expire 30 days after their last refresh, and our post on products expiring in Merchant Center covers what that looks like.

Route 4: the Merchant API

If you have a developer, Merchant Center’s API sends products directly. Google’s page on creating a product data source covers how an API source works alongside the rest. Worth knowing before commissioning anything: the older interface is closed. Google says The Content API for Shopping reached its sunset on August 18, 2026. Our post on the Content API to Merchant API move covers how to check which one a tool uses.

The store requirements don’t change

This is the part that catches WordPress sites more often than the feed does, because a WordPress site is usually a website first and a shop second. Merchant Center asks for the same things of every store, however the products arrive.

A checkout that works. Google is specific on both counts: Customers must be able to add in-stock products to their cart and finalize their purchase. and You must secure your checkout with a valid SSL certificate. (Google’s checkout requirements). A “contact us to order” page or an email-for-a-quote form will not pass. Our guide to a checkout a shopper can’t complete covers the usual failures.

A contact method a visitor can find. Google asks you to Show at least a business address, phone number, email, contact form, or social media business profile on your online store. and to add your phone number to Merchant Center’s business information too (Google’s page on missing contact information). One of those is enough; a contact form counts. Our guide to a missing contact page covers what doesn’t count.

A returns policy, stated even when you don’t take returns. Google says: Even if you don't offer returns or refunds, still state your policy explicitly (Google’s page on keeping your account approved). On a site selling downloads or services this is the line people skip, and “all sales are final, because the file is delivered immediately” is a perfectly good policy to state. Our guide to a missing refund policy covers what to put in it.

If you sell somewhere else and link to it

This is the specific case where a WordPress site can’t use Merchant Center at all, and it is worth being clear about rather than discovering it after a suspension. Our guide to how to fix a Misrepresentation suspension covers that recovery.

Google’s landing page requirements say: Don’t redirect people to another website outside of the domain you claimed in your Merchant Center account. (Google’s page on landing page requirements).

And Google Search has the same restriction for merchant listings: Only pages where a shopper can purchase a product are eligible for merchant listing experiences, not pages with links to other sites that sell the product. (Google’s merchant listing documentation).

So a WordPress product page whose buy button goes to Etsy, Amazon or a separate Shopify store doesn’t qualify. The purchase has to complete on the domain you claimed. If that is your setup, the answer is to claim the domain where the checkout happens, not to feed the WordPress pages.

A short checklist

1. Decide the route, whether markup and a crawl, a file, a Sheet or the API, by how often your prices change and who maintains it.
2. Verify and claim your domain in Merchant Center.
3. Let Googlebot in. Check robots.txt and untick “Discourage search engines” under Settings → Reading.
4. Add Product markup to every product page, in the server-rendered HTML, with a price above zero.
5. Make the checkout complete on your own domain, over HTTPS.
6. Show one contact method on the site, and a phone number in Merchant Center.
7. Publish a returns policy, even if it is “no returns”, plus shipping, privacy and terms.
8. Check what a logged-out visitor sees, on a phone, including the final payment step.

If you do run WooCommerce after all, our WooCommerce page covers what we check there, and for the wider WordPress picture our WordPress page covers the same ground.

Where ShieldKit fits

Our free store check needs no plugin and no account: it reads your live site the way a shopper does. On a WordPress site without WooCommerce it covers five of the things on the checklist above: whether your refund, shipping, privacy and terms pages exist and say something specific, whether a contact method is visible, whether your product pages carry Product structured data that parses, whether those pages load at all, and which payment methods your homepage shows, plus a comparison of each product page’s visible price with the price in its own structured data.

What it can’t do here is worth saying plainly. Hidden fees need a full store check, which you get by adding the site to a free ShieldKit account; that works on any platform. Product data and product images need a product list, which only Shopify and WooCommerce publish, so on plain WordPress those two come back “Not checked”, not “passed”. The business-details match needs your Merchant Center account connected. And the robots.txt report that names each crawler is part of a full store check, not the public one.

FAQ

Can I use Google Merchant Center on WordPress without WooCommerce?

Yes. The Google for WooCommerce plugin requires WooCommerce, but Merchant Center itself doesn’t care how your site is built. You can let Google read your product pages, submit a file, use a Google Sheet, or send products through the Merchant API.

Does Google need a plugin to read my products?

No. Google can take products from your website if the product details are in the page’s structured data; it says it reads that markup for details like title, price and availability, and checks the site at least once every 24 hours. Nothing on a WordPress site writes that markup for you without a shop plugin, so that is the part to add.

Can I link to my Etsy or Amazon listing instead?

No. Google says not to redirect people to a website outside the domain claimed in your Merchant Center account, and its merchant listing documentation says only pages where a shopper can purchase the product are eligible, not pages linking to other sites that sell it.

Do I need a returns policy if I sell digital downloads?

Google asks every store to state one: even if you don’t offer returns or refunds, state the policy explicitly. “All sales are final” is a policy; silence isn’t.

Does my checkout have to be on my own site?

Google requires that customers can add in-stock products to a cart and finalise the purchase, and that the checkout is secured with a valid SSL certificate. A hosted payment page you send the shopper to is normal; a page that asks them to email you for an invoice is not a checkout.