How to Tell if a Website Is Built with WooCommerce
WooCommerce is WordPress plus Woo: woocommerce-* body classes, a /wp-content/plugins/woocommerce/ path and wc-* cart scripts. Here is how to detect it.
To tell if a website is built with WooCommerce, remember the key fact: WooCommerce is a WordPress plugin, not a standalone platform. So detection is a two-step check. First confirm WordPress — assets under /wp-content/, a /wp-json/ API, a generator meta tag. Then look for the WooCommerce-specific markers on top: assets loading from /wp-content/plugins/woocommerce/, woocommerce-* CSS classes on the <body> and store pages, wc-* scripts such as wc-cart-fragments in the DevTools Network tab, and a generator meta tag reading WooCommerce. This guide walks through every signal, the two-layer logic, and what finding WooCommerce tells you about a store.
It pairs with how to find out what ecommerce platform a website uses, the WordPress-focused how to tell what CMS a website is using, and the broader how to find out what technology a website uses.
What WooCommerce is, briefly
WooCommerce is the most widely used ecommerce plugin for WordPress. Rather than being a separate platform, it turns an existing WordPress site into an online store: it adds products, a shopping cart, a checkout, payment integration and order management on top of WordPress's content management. Because it is built on the open-source, self-hosted WordPress, WooCommerce stores are flexible and owner-controlled — you host them yourself, choose your theme and extend them with the vast WordPress plugin ecosystem — and they skew toward small and medium-sized merchants, though they scale up too.
For detection, the crucial consequence is the layered architecture. Every WooCommerce site is a WordPress site, so you will see all the usual WordPress fingerprints, and the WooCommerce markers sit on top of them. The detection logic is therefore: confirm WordPress as the base, then confirm WooCommerce as the commerce layer. Reading the two layers separately keeps the identification precise and is exactly what distinguishes "WordPress with WooCommerce" from a WordPress site that does not sell anything.
Step 1: confirm WordPress first
Because WooCommerce requires WordPress, start by confirming the CMS. The standard WordPress signals are: assets — themes, plugins, uploads — served from /wp-content/ (you will see /wp-content/themes/... and /wp-content/plugins/... in the source and Network tab); a REST API at /wp-json/; the /wp-includes/ path for core scripts; and frequently a generator meta tag reading <meta name="generator" content="WordPress 6.x">. Open View Source (Ctrl/Cmd + U) and search for wp-content and wp-json. Confirming WordPress is the foundation; the full CMS method is in how to tell what CMS a website is using. Once WordPress is established, you look for the commerce plugin on top.
Step 2 — Signal 1: the woocommerce plugin path and body classes
The clearest WooCommerce-specific fingerprint is its plugin asset path. WooCommerce ships its CSS and JavaScript from /wp-content/plugins/woocommerce/, so seeing requests to URLs like /wp-content/plugins/woocommerce/assets/css/woocommerce.css or .../assets/js/frontend/... is close to conclusive. Search the source and watch the Network tab for that plugins/woocommerce/ path.
The second half of this signal is the woocommerce-* body classes. WordPress adds descriptive classes to the <body> tag, and WooCommerce contributes its own: a store page typically carries woocommerce, woocommerce-page, and on specific pages classes like woocommerce-cart, woocommerce-checkout or woocommerce-account. Inspect the <body> element (or search the source for class="...woocommerce) and these classes name the plugin directly. The plugin path plus the body classes together are a strong, reliable confirmation.
Step 2 — Signal 2: wc-* scripts, wc-ajax and cart fragments
WooCommerce has a distinctive JavaScript footprint prefixed with wc-. You will commonly see scripts such as wc-add-to-cart.js, wc-cart-fragments.js and woocommerce.js loaded from the plugin path. The most telling behaviour is cart fragments: wc-cart-fragments.js keeps the mini-cart (for example the cart count in the header) up to date without a full page reload by making an AJAX call to a wc-ajax endpoint (you will see requests with a ?wc-ajax=get_refreshed_fragments parameter) and swapping in the updated cart HTML. Open the DevTools Network tab, reload, and — especially after adding an item to the cart — watch for the wc-cart-fragments script and the wc-ajax request to fire. This is distinctive WooCommerce behaviour that confirms the plugin is genuinely powering the store, not merely referenced somewhere.
You will also often find a woocommerce_params (and related wc_*_params) JavaScript object in the source, which WooCommerce uses to pass configuration such as the AJAX URL and cart settings to its scripts. Searching for woocommerce_params is another quick, specific tell.
Step 2 — Signal 3: the generator meta tag and store URLs
Two more corroborating signals are quick to check. First, the generator meta tag: alongside the WordPress generator, WooCommerce frequently adds its own, <meta name="generator" content="WooCommerce 8.x.x">, which names the plugin and its version directly in the head. Search the source for generator and you may catch both the WordPress and WooCommerce tags.
Second, the store URLs. WooCommerce's default pages use recognisable, human-readable paths: the cart at /cart/, the checkout at /checkout/, the account area at /my-account/, and the shop at /shop/, with products often under /product/ and categories under /product-category/. Navigating to the cart or reading the destination of the cart and account links is a fast corroborating check; these are WooCommerce defaults and line up with the plugin path, body classes and scripts to confirm the platform.
The signal table
| Signal | Where to find it | What it means |
|---|---|---|
/wp-content/, /wp-json/ | View Source, Network tab | WordPress base — required foundation |
/wp-content/plugins/woocommerce/... | View Source, Network tab | WooCommerce plugin assets — strong |
woocommerce, woocommerce-page body classes | Elements / View Source | WooCommerce store page — strong |
wc-cart-fragments.js, wc-add-to-cart.js | Network tab / View Source | WooCommerce front-end scripts |
?wc-ajax=get_refreshed_fragments request | Network tab | WooCommerce cart-fragment behaviour |
woocommerce_params JS object | View Source | WooCommerce configuration — specific |
<meta name="generator" content="WooCommerce ..."> | View Source (head) | Direct platform-and-version tag |
/cart/, /checkout/, /my-account/ URLs | Address bar / links | WooCommerce default store pages |
WordPress signals plus any of the WooCommerce-specific rows confirm the platform; two or more make it conclusive.
Method 1: View Source
The quickest single check is View Source. Open the homepage (or a shop page), press Ctrl/Cmd + U, and search in turn for wp-content, plugins/woocommerce, woocommerce-page, woocommerce_params and generator. Finding /wp-content/ confirms WordPress; finding the plugins/woocommerce/ path, the woocommerce body classes, the params object or a WooCommerce generator tag confirms the plugin on top. This works because these markers are written into the server-rendered HTML, so they are present before any JavaScript runs — which is exactly why a static source view catches the two layers cleanly in one pass.
Method 2: the DevTools Network tab
For a live view, open DevTools (F12), go to the Network tab and reload. Watch for assets loading from /wp-content/plugins/woocommerce/ and the wc-* scripts, then add a product to the cart and look for the wc-cart-fragments script and the ?wc-ajax=get_refreshed_fragments request to fire as the mini-cart updates. The Network tab is valuable because it shows the plugin's behaviour in action, not just its presence in markup — the cart-fragment request in particular is dynamic, distinctive WooCommerce activity. To identify the other plugins and tools loading alongside it, the same view feeds into how to find out what technology a website uses.
Method 3: Wappalyzer and BuiltWith
For a one-click read, the Wappalyzer browser extension and BuiltWith both recognise WooCommerce (and WordPress beneath it) and list them alongside the hosting, payment processor and analytics. They are convenient for a quick confirmation and for capturing the whole stack at once, and because WooCommerce is so common they detect it reliably. As always, treat their output as a strong starting point and verify the important calls against the raw signals — the /wp-content/plugins/woocommerce/ path, the woocommerce-* classes and the cart-fragment behaviour are the ground truth, and a quick View Source confirms what an extension reports.
A worked example
Say you are sizing up a competitor's shop. You open View Source and search for wp-content — there it is, confirming WordPress, along with a /wp-json/ reference. You search for plugins/woocommerce and find CSS loading from /wp-content/plugins/woocommerce/assets/css/woocommerce.css. Inspecting the <body>, you see class="... woocommerce woocommerce-page ...", and a woocommerce_params object sits in the source with the AJAX URL. To be thorough, you open the Network tab, add an item to the cart, and watch a ?wc-ajax=get_refreshed_fragments request fire as the header cart count updates. The cart link points to /cart/ and the account link to /my-account/. Every signal lines up across both layers: this is a WordPress site running WooCommerce. In about a minute you have the CMS and the commerce plugin, with the cart behaviour confirming it live.
Distinguishing WooCommerce from other ecommerce platforms
It is worth knowing how WooCommerce differs from the other major platforms so you do not misattribute. Shopify is a hosted SaaS platform with cdn.shopify.com assets, /cdn/shop/ paths and a Shopify.theme object — and crucially no /wp-content/, since it is not WordPress; see how to tell if a website is built with Shopify. Magento (Adobe Commerce) uses /static/version*/ and /media/catalog/ paths and Magento_ RequireJS modules, again with no WordPress base; see how to tell if a website is built with Magento. So the defining test for WooCommerce is the WordPress foundation (/wp-content/, /wp-json/) plus the WooCommerce plugin markers — that combination is what specifically names WooCommerce rather than a hosted platform. The general approach to telling commerce platforms apart is covered in how to find out what ecommerce platform a website uses.
One nuance worth noting: because WooCommerce lives in the rich WordPress ecosystem, a store may also run other commerce-adjacent plugins (for subscriptions, bookings, or a different gateway), each loading its own assets. So expect to find WooCommerce plus a handful of supporting plugins, and read the whole set rather than stopping at the first marker — the breadth of plugins is itself a signal of how the store is built.
Why the platform matters
Knowing a store runs WooCommerce tells you a lot. As the most widely used ecommerce plugin, running on self-hosted WordPress, it signals a flexible, owner-controlled store that the merchant (or their agency) hosts and extends themselves, and it skews toward small and medium-sized operations — though plenty of larger stores run it too. For agencies and developers, that identifies WordPress and WooCommerce build, maintenance and plugin or theme opportunities, since these stores rely on ongoing technical care and the plugin ecosystem. For competitive research, it reveals a rival's commerce setup and the supporting tools around it. And for sales qualification, it tells you a prospect runs a self-managed WordPress store with particular needs. Combined with the other plugins, the payment processor and the analytics a WordPress site loads, WooCommerce detection paints a clear picture of how the store is built and run.
How reliable is WooCommerce detection?
Very reliable, precisely because the signals are layered and intrinsic. The WordPress base is easy to confirm (/wp-content/, /wp-json/), and the WooCommerce markers — the /wp-content/plugins/woocommerce/ path, the woocommerce-* body classes, the wc-* scripts and cart-fragment behaviour, the woocommerce_params object and the generator tag — are baked into how the plugin ships and behaves, so they are present on the large majority of WooCommerce stores and are not used by unrelated tools. The main nuances are caching or optimisation plugins that rename or combine assets (the body classes, cart fragments and store URLs usually still give it away) and the occasional removed generator tag (the plugin path and scripts carry the detection). Confirm WordPress, then the WooCommerce layer, and you can state "this is WooCommerce" with genuine confidence.
The workflow
- Confirm WordPress first — search the source for
/wp-content/and/wp-json/. - Find the plugin assets — look for
/wp-content/plugins/woocommerce/in the source and Network tab. - Check the body classes — inspect
<body>forwoocommerceandwoocommerce-page. - Watch the Network tab — add to cart and look for
wc-cart-fragmentsand the?wc-ajax=request. - Corroborate with
woocommerce_params, a WooCommerce generator tag, and/cart/and/my-account/URLs.
Go deeper
- The platform question in general: how to find out what ecommerce platform a website uses.
- The WordPress base beneath it: how to tell what CMS a website is using.
- A hosted-SaaS contrast: how to tell if a website is built with Shopify.
- The enterprise alternative: how to tell if a website is built with Magento.
Want the ecommerce platform, CMS, hosting and full stack identified automatically? Analyse any site with StackOptic — free, no sign-up.
Frequently asked questions
How do I tell if a website is built with WooCommerce?
Because WooCommerce is a WordPress plugin, first confirm WordPress (assets under /wp-content/, a /wp-json/ API, a generator meta tag). Then look for WooCommerce's own markers: assets loading from /wp-content/plugins/woocommerce/, woocommerce-* CSS classes on the body and store pages, wc-* scripts like wc-cart-fragments in the Network tab, and a generator meta reading WooCommerce. Any of these on top of WordPress confirms WooCommerce, usually in under a minute.
What is the relationship between WooCommerce and WordPress?
WooCommerce is the most popular ecommerce plugin for WordPress, not a standalone platform. It turns a WordPress site into an online store by adding products, a cart, checkout and order management. So every WooCommerce site is a WordPress site, and detection works in layers: the WordPress signals (/wp-content/, /wp-json/) tell you the CMS, and the WooCommerce signals (/wp-content/plugins/woocommerce/, woocommerce-* classes) tell you the store plugin running on top. You confirm both to identify WooCommerce.
Which signals are specific to WooCommerce rather than WordPress?
The WooCommerce-specific signals are: assets served from /wp-content/plugins/woocommerce/, woocommerce-* and woocommerce-page CSS classes on the body, wc-* scripts (wc-cart-fragments.js, wc-add-to-cart.js), the wc-ajax endpoint and cart-fragment requests, a woocommerce_params JavaScript object, and a generator meta tag reading WooCommerce with a version. WordPress alone gives you /wp-content/themes/ and /wp-json/; the woocommerce plugin path and the wc- prefixed scripts are what specifically name WooCommerce on top of the WordPress base.
What are WooCommerce cart fragments and why do they matter for detection?
Cart fragments are how WooCommerce updates the cart contents (like the cart count in the header) without a full page reload. The wc-cart-fragments.js script makes an AJAX request to a wc-ajax endpoint and swaps in the updated cart HTML. For detection this is useful because the wc-cart-fragments script and the wc-ajax request are distinctive WooCommerce behaviour you can watch fire in the Network tab, especially after adding an item to the cart, confirming the plugin is genuinely powering the store.
Why would I want to know if a site uses WooCommerce?
WooCommerce is the most widely used ecommerce plugin, running on self-hosted WordPress, so detecting it signals a flexible, owner-controlled store that is often small-to-medium sized. For agencies and developers it identifies WordPress and WooCommerce work and plugin or theme opportunities; for competitive research it reveals a rival's commerce setup; and for sales it qualifies a prospect's stack. Combined with the other plugins and tools a WordPress site loads, it paints a clear picture of how the store is built and run.
Analyse any website with StackOptic
Get the full technology stack, performance, security and SEO report in seconds — free.
Analyse a websiteRelated articles
How to Tell If a Website Uses Heap
Heap (Heap Analytics) autocaptures product events. Detect it via the cdn.heapanalytics.com script, the global heap object, heapanalytics.com beacons and _hp2 cookies.
How to Tell If a Website Uses Foundation
Foundation (by Zurb) is a responsive front-end framework. Detect it via its grid classes (row/columns, grid-x/cell), data-* component attributes and the foundation.css/js files.
How to Tell If a Website Uses Crisp
Crisp is a developer-friendly, affordable live-chat and messaging tool. Detect it via the client.crisp.chat/l.js script, the window.$crisp object and the CRISP_WEBSITE_ID value.