Installing a CMP on PrestaShop is not simply about adding a cookie banner.
As with any CMS, the real work is identifying the third-party services used by the store and controlling their loading when consent is required.
On an ecommerce website, this distinction is particularly important because not every cookie serves the same purpose.
A PrestaShop store uses necessary cookies
A store needs to maintain a cart, manage a session and allow customers to authenticate.
These mechanisms should not be confused with an advertising pixel or marketing tracking tool.
The purpose of a CMP is therefore not to blindly block every cookie on the website.
You need to distinguish what is necessary for functionality requested by the user from what actually requires consent.
Additional modules are often where complexity begins
PrestaShop provides a foundation to which many modules are generally added.
Analytics, advertising, chat, video, reviews, maps, social networks and marketing tools can each introduce scripts and external requests.
The first step is therefore to inventory what the store actually loads.
The installed module list provides clues, but the browser remains the best source for observing what is actually sent to third-party domains.
A module may inject its script very early
The difficulty with a CMS is that the final page code does not come from a single file.
One module may add a script to the <head>, another to the page body and a tag manager may inject additional services.
The CMP therefore needs to load early enough to control integrations that need to be blocked.
As I explain in my article about loading order, a request that has already been sent cannot be undone afterwards.
tarteaucitron provides two approaches
With tarteaucitron open source, services can be integrated manually.
The service’s direct tag is removed and its loading is delegated to tarteaucitron.
This approach provides precise control but requires understanding which integrations are present on the store.
With tarteaucitron Pro, automatic detection can preserve many existing integrations as long as the Pro marker loads before them.
Automatic detection does not remove the need for an inventory
Automatic does not mean universal.
A CMP can recognize services it knows. A custom module developed for the store or an unsupported provider may require an additional integration.
I therefore always recommend knowing which services are installed even when automatic detection is used.
The browser can then be used to verify that the expected services actually remain blocked.
Pay attention to ecommerce marketing tools
Stores often use more marketing services than brochure websites.
Advertising pixels, retargeting, affiliation, conversion measurement and marketing automation may be added directly or through a tag manager.
The fact that these tools help measure a sale does not make them necessary for the shopping cart to function.
Their purpose and behaviour need to be analysed separately.
Payment is another subject
A store obviously needs a payment method.
An external component required to complete an order should not automatically be treated like a marketing tracker simply because it belongs to a third-party provider.
The question is not “is this a third-party domain?"but"why is this resource used and does its access to the device require consent?”.
This distinction avoids breaking essential functions through overly broad rules.
Google Analytics and Google Ads need conscious configuration
A store using Google Analytics, Google Ads or both can also use Google Consent Mode v2.
Consent Mode communicates consent states to compatible Google products.
However, it does not replace the CMP and does not automatically control the store’s other services.
The choice between Basic and Advanced implementation also deserves to be understood, as explained in my comparison of both modes.
Test the store before and after the choice
Once the CMP is installed, I would perform at least three tests.
On the initial load without a choice, services requiring consent should remain inactive. After “Reject all”, they should still remain blocked. After acceptance, authorized services should operate normally.
Several pages should then be tested: home, category, product, cart and checkout.
Some modules only trigger at a specific stage of the customer journey.
The purchase journey must continue to work after rejection
This is an essential ecommerce test.
Rejecting an advertising pixel should not prevent a product from being added to the cart.
Rejecting an analytics tool should not make it impossible to complete an order.
If an essential feature breaks when optional services are rejected, the website architecture deserves another look.
Use Network to identify requests
The Network tab in DevTools can precisely track requests made by the store.
When an unexpected call appears, the Initiator column can often identify the module or script responsible.
This is particularly useful on PrestaShop, where the source of a tag is not always obvious from the template alone.
I explain the method in my guide to testing a CMP with DevTools.
A PrestaShop CMP mainly needs to remain verifiable
There is no magical property that makes a CMP specifically “PrestaShop”.
The implementation mainly needs to load the CMP early enough, control the services used by the store and remain maintainable as modules are added or removed.
An ecommerce website evolves frequently. A new marketing tool installed six months later may change the behaviour observed today.
Consent control therefore needs to be part of website maintenance, not only the initial installation.
