How to Tell If a Website Is Built With PrestaShop

PrestaShop is one of the most widely used open-source ecommerce platforms, particularly across Europe, powering a large number of independent online stores. To tell whether a site is built with it, the quickest answer is to type prestashop into the browser console — modern versions expose a global object by that name — or to look for a generator meta tag reading "PrestaShop" and asset paths under /modules/ and /themes/. This guide walks through every reliable signal, the platform's structure, and what a PrestaShop build tells you about the merchant.

What is PrestaShop?

PrestaShop is a free, open-source ecommerce platform first released in 2007, written in PHP and built around a theme-and-module architecture. It lets merchants run a self-hosted online store with full control over hosting, data and customisation, extended through a large marketplace of community and commercial modules for payments, shipping, marketing and more. It has historically been especially popular in France, Spain, Italy, Poland and across continental Europe and Latin America, where it competes with WooCommerce and Magento for the independent-merchant segment.

For detection, the key context is that PrestaShop is a self-hosted, merchant-operated platform aimed at small and mid-sized stores. Unlike a hosted SaaS such as Shopify, running PrestaShop means the merchant (or a small agency) manages the server, updates and modules themselves, which signals a degree of hands-on technical involvement and a preference for ownership and customisation over convenience. Finding PrestaShop therefore usually points to an independent online retailer — frequently European — with a real product catalogue and a stack of modules tailoring the store to its needs.

How PrestaShop renders and exposes itself

PrestaShop exposes a consistent set of front-end fingerprints. Modern PrestaShop (version 1.7 and the later 8.x line) defines a global JavaScript object named prestashop that carries front-end configuration — currency, language, customer state — and references to loaded modules; this is the single clearest signal. Themes load assets from a predictable structure: the active theme under /themes/<theme>/, modules under /modules/<module>/, and product imagery from /img/ with id-based paths (PrestaShop generates image URLs from the product ID, so you will see numeric, id-derived image paths).

The platform also tends to announce itself in metadata and routing. A <meta name="generator" content="PrestaShop"> tag is common (though security-conscious shops remove it), and PrestaShop's controller-based routing surfaces parameters like id_product, id_category and controller= in URLs or markup, even when friendly URLs are enabled. Session and cart state live in first-party cookies prefixed PrestaShop-. Knowing this structure — the prestashop global, the /modules/ and /themes/ paths, the generator tag, the id-based routing, and the PrestaShop- cookies — makes detection reliable even on a custom theme.

How to tell if a website uses PrestaShop

Confirm at least two of the following, ideally on a product or category page.

1. Use the console. Type prestashop and press Enter. A returned object (with properties like currency, language and modules) confirms PrestaShop 1.7+ immediately and is the fastest check.

2. View the page source. Search for prestashop. Look for the generator meta tag, references to /modules/ and /themes/<theme>/, and the prestashop object being populated inline.

3. Inspect asset paths. Theme CSS/JS under /themes/, module assets under /modules/, and id-based product images under /img/ are characteristic of PrestaShop's directory conventions.

4. Look at the routing. URLs or links referencing id_product, id_category or controller= indicate PrestaShop's controller routing, even with SEO-friendly URLs in place.

5. Check cookies. First-party cookies prefixed PrestaShop- confirm a live PrestaShop session.

What the PrestaShop signals look like

window.prestashop = { currency: {...}, language: {...}, modules: {...}, urls: {...}, … }
<meta name="generator" content="PrestaShop">
GET /themes/classic/assets/css/theme.css
GET /modules/ps_shoppingcart/...
GET /img/p/1/2/3/123-home_default.jpg   (id-based product image)
Cookie: PrestaShop-1a2b3c… = "…"

The combination of the prestashop global, the /modules/ and /themes/ paths, and the PrestaShop- cookies is conclusive.

PrestaShop versus other platforms — avoiding false positives

Keep the ecommerce platforms distinct. WooCommerce runs on WordPress (/wp-content/, woocommerce body classes, wc- scripts); Magento uses /static/, /media/catalog/ and the Magento_ module pattern; OpenCart uses route= URLs and catalog/view/theme/; PrestaShop uses the prestashop global, /modules/, /themes/ and id-based /img/ paths. The prestashop JavaScript object is unique enough that it removes ambiguity once you see it. The main subtlety is that security-hardened shops strip the generator meta tag and may obscure routing with friendly URLs, so rely on the prestashop global and the asset paths in those cases. PrestaShop 1.6 (older, now unsupported) lacks the consistent global, so for very old shops lean on the /modules/, /themes/ and id-based image paths instead.

How reliable is each PrestaShop signal?

The global prestashop object is definitive for modern PrestaShop. The /modules/ and /themes/ asset paths and id-based /img/ product images are strong because they reflect the platform's fixed structure. The PrestaShop- cookies are reliable corroboration. The generator meta tag is conclusive when present but often removed. The id_product/controller= routing is a good supporting signal. The weakest case is a heavily customised, security-hardened 1.6 shop with the generator stripped — there, the asset paths and cookies carry the proof. As a rule, the prestashop global or an asset-path match settles it.

What a PrestaShop build reveals about a merchant

Finding PrestaShop signals an independent, self-hosted online retailer, most often small-to-mid-sized and frequently European. Because PrestaShop is merchant-operated rather than a managed SaaS, its presence implies a business willing to handle (or pay a small agency to handle) hosting, updates and modules in exchange for control and lower per-transaction costs. The set of modules visible in /modules/ paths is informative — payment, shipping, marketing and SEO modules reveal how the store operates and which vendors it works with. If you sell ecommerce services — hosting, performance, security, module development, migration to or from PrestaShop, or marketing — a PrestaShop store is a clear, transacting prospect. An ageing PrestaShop 1.6 shop is also a strong migration or upgrade candidate, since that version is end-of-life.

PrestaShop in a typical store stack

PrestaShop sits within a self-hosted PHP commerce stack. Expect standard or managed PHP hosting (sometimes a PrestaShop-specialist host), a CDN for performance, and a collection of modules handling payments (often a local gateway plus PayPal or Stripe), shipping carriers, and marketing integrations. Analytics is commonly Google Analytics, and you may find a cookie-consent module for GDPR given the European user base. The theme — whether the default Classic theme or a commercial one — and the module set together characterise how sophisticated the store is. For an auditor, the valuable details are the PrestaShop version family (1.7/8.x via the global object versus legacy 1.6), the active theme, the visible modules (especially payment and shipping), and the hosting; together these reveal the maturity of the store and the services it might need.

A quick PrestaShop confirmation walkthrough

Open a product or category page with developer tools on the Console panel and type prestashop — a returned object confirms a modern PrestaShop store and reveals currency, language and module data. Switch to the Network or Elements panel and look for asset paths under /themes/ and /modules/, plus id-based product images under /img/. View the source for a generator meta tag and any id_product/controller= references. Finally, check the Application panel for PrestaShop- cookies. Two of these signals confirm PrestaShop and indicate roughly how current and customised the store is.

A quick PrestaShop detection checklist

• Type prestashop in the console; a returned object confirms PrestaShop 1.7+.
• View source for a <meta name="generator" content="PrestaShop"> tag.
• Look for /themes/, /modules/ and id-based /img/ product image paths.
• Check for id_product, id_category or controller= routing.
• Confirm PrestaShop- prefixed cookies.
• Use the presence of the global object to distinguish 1.7+/8.x from legacy 1.6.

Detecting PrestaShop at scale

Checking one store is quick, but mapping PrestaShop usage across a market — to prospect independent retailers, or to find ageing shops ripe for migration — calls for automation. StackOptic detects PrestaShop, its version family where exposed, and thousands of other technologies from a real browser. Pairing that with performance and security signals quickly surfaces the stores most in need of help, and because PrestaShop is concentrated in particular European markets, a regional scan can reveal striking adoption patterns that inform where to focus outreach. Re-running the scan over time also catches merchants migrating off an end-of-life version, which is a timely moment to offer upgrade or replatforming services. For related reading, see our guide to finding out what ecommerce platform a website uses and the full PrestaShop technology profile.