Toolstore Light
A free add-on that connects essential services and improves how they load in your online store.
Free to download, no registration, no recurring fee.
Overview
Toolstore Light connects the services needed to measure, promote and manage an online store without allowing them to slow down its initial page load.
It is made for store owners aiming for 100/100/100/100 in Lighthouse while continuing to use the external services their business depends on.
Bonus feature — exclusive to Toolstore: Enables your store’s own server to count unique and returning visitors.
- Performance-first service loading.
- Consent without server-side GTM.
- Google Analytics or Google Tag Manager.
- Microsoft Clarity.
- Meta Pixel.
- IndexNow.
- Google Customer Reviews.
- Google and Bing ownership verification.
Features
Explore what Toolstore Light does, why each feature exists and how its behaviour has been verified.
Consent without GTM dependency
Toolstore Light can work directly with supported consent platforms, without requiring their consent templates inside Google Tag Manager to control the services managed by the add-on.
PrestaShop
Installation
- Download the Toolstore ZIP file.
- Open the module manager in PrestaShop.
- Select “Upload a module”.
- Upload the ZIP file and complete the installation.
Test Log
This development log documents the foundations, feature verification, discovered conflicts and product decisions that shaped Toolstore Light. Entries follow the order in which the add-on was built and tested.
Customer-facing features link directly to their relevant verification records. Other entries document the technical foundations required for the add-on to operate reliably.
Runtime foundation
The first development stage established how Toolstore Light loads and controls external services without placing large amounts of integration logic directly in every storefront page.
View verification record
Why the foundation was needed
External services were previously added through separate integrations that placed their own scripts and configuration directly in the storefront source.
Toolstore Light needed one shared foundation that could control how and when supported services were loaded, while keeping the page source compact and the storefront’s initial loading phase undisturbed.
Foundation requirements
- Shared control of supported external services.
- Integration logic stored in an external runtime file.
- Only compact configuration published on each page.
- Test changes without affecting ordinary visitors.
- Reliable delivery of updated runtime files.
- Preserve existing settings during module upgrades.
Development record
- Version 0.1 — loading and test isolation. A separate GA4 property was used to verify that Toolstore could postpone an integration until the page had finished loading. The integration was also restricted to the activated test browser and did not appear during an isolated private-browser check.
- Versions 0.2–0.2.2 — consent and runtime delivery. Consent handling was added, but testing revealed that an older JavaScript file remained in cache after the module had been updated. Adding the module version to the file URL was not sufficient in the tested environment. The runtime filename was therefore changed so that the updated code could not be confused with the previous cached file.
- Version 0.3 — shared product foundation. The isolated prototype was replaced by the common Toolstore Light foundation. Configuration, test deployment and the external storefront runtime were brought together so that later integrations could use the same loading and consent controls.
Findings that changed the product
- Runtime updates must remain reliable even when the storefront, PrestaShop or the visitor’s browser retains an older asset.
- New configurations must be testable in one activated browser before they are published for all storefront visitors.
- Supported integrations need shared loading rules rather than separate inline implementations.
- Google Analytics and Google Tag Manager require an exclusive selection to reduce the risk of duplicate tracking.
Established foundation
By version 0.3, Toolstore Light had a shared external runtime, browser-isolated testing, consent-aware loading and a common configuration foundation for subsequent integrations.
Later development records document the individual integrations and verify their specific behaviour.
Toolstore Light is designed to prevent cache problems after an update. Version-specific runtime filenames stop an old cached file from remaining active when a newer version of the add-on has been installed.
Consent-controlled Google integration
Toolstore verified that a selected Google integration could remain blocked until the storefront was ready and the required statistics consent had been granted.
View verification record
Objective
Confirm that Toolstore sends no GA4 request before consent, loads the configured property after consent and does not alter the website’s existing analytics installation during an isolated test.
Verified behaviour
- No Toolstore GA4 request before statistics consent.
- No request while statistics consent remained denied.
- The separate test property loaded after approval.
- The test remained restricted to the activated browser.
Finding that changed the product
Testing revealed that an existing Google Tag Manager container could react to the same Google command as Toolstore’s direct GA4 integration, causing the test property to receive two requests instead of one.
Toolstore was therefore changed to make GA4 and Google Tag Manager mutually exclusive selections. Its Shadow Tags check provides an additional safeguard by warning when an existing tracking installation outside Toolstore may cause duplicate tracking or operate independently of the visitor’s consent choice.
Compact ownership verification
Google Search Console and Bing Webmaster Tools verification were added as passive homepage metadata without adding tracking scripts or consent-dependent behaviour.
View verification record
Objective
Publish only the verification values required by Google and Bing. Ownership verification must not start an external service or wait for visitor consent.
Expected output
<meta name="google-site-verification" content="...">
<meta name="msvalidate.01" content="...">Result
Both tags appeared in the homepage source with the configured values and without surrounding listeners, scripts or additional tracking logic. Empty configuration values removed the tags.
Microsoft Clarity consent and session fragmentation
Toolstore verified both consent-dependent and limited no-consent Clarity operation. Live testing also showed that, without storage consent, one real visitor could appear as several disconnected users instead of one continuous session.
View verification record
Normal consent mode
With statistics consent denied, no Clarity project script,
clarity.js or Clarity collection request was
observed. After consent was granted, Clarity loaded after the
DOM was ready.
Limited no-consent mode
Limited mode required an explicit website-owner decision.
Clarity loaded with denied storage signals and no
_cl cookies were created in the tested browser.
Field observation: fragmented visitors without consent
Live observations showed that Clarity data must be interpreted differently depending on the visitor’s consent state.
- Consent denied
- No Clarity cookies were created. Navigation between variants of the same product appeared as several disconnected users.
- Consent granted
- The repeated navigation appeared as one user and one continuous session containing the full path and the variant changes.
The observation showed that Clarity’s reported user count in limited no-consent mode could exceed the number of real visitors. One person could be represented by several disconnected identifiers as they moved between pages.
The higher number of live users shown by Clarity was therefore not necessarily a higher number of real visitors. In limited no-consent mode, one visitor could be represented by several disconnected identifiers.
Product changes
- Clarity received its own clearly separated configuration block.
- The Project ID field appears only when Clarity is enabled.
- Limited mode records that the website owner selected it.
- Repeated Cookiebot events do not load Clarity more than once.
Interpretation and identified need
Limited no-consent mode can provide page-level behavioural observations, but its user and session figures must not be interpreted as reliable counts of real visitors or continuous visits.
This finding identified the need for a separate store-owned traffic baseline that can count visits consistently without depending on Clarity’s ability to reconnect page views into users and sessions.
IndexNow identity and controlled submission
Toolstore established a verified server-side IndexNow identity and a controlled way to submit changed canonical URLs. Testing showed why this can be valuable when a store’s sitemap does not reflect a published change.
View development record
Why IndexNow required a separate model
IndexNow is not loaded in the visitor’s browser and is not controlled by visitor consent. It should notify participating search engines only when a published URL is created, changed or removed.
Foundation requirements
- Generate the ownership key inside Toolstore.
- Publish a matching verification file on the shop domain.
- Verify the key file before URL submission.
- Provide a controlled manual test before automation.
- Submit canonical URLs rather than variant URLs.
Store-specific observation: unchanged sitemap timestamp
During testing, a real price change was published on the canonical
product page while the URL’s lastmod value in the
store’s sitemap remained unchanged. The sitemap therefore provided
no updated timestamp for that change.
The canonical URL could still be submitted manually through IndexNow, providing a notification path that did not depend on the sitemap recording the price update.
This observation applies to the sitemap implementation used by the tested store. PrestaShop shops can use different sitemap modules and custom solutions, so change detection must be evaluated for each store rather than assumed to behave identically.
Outcome
The generated key, public verification address and controlled URL submission were established as prerequisites. Automatic notifications remained disabled until a later development stage.
Sitemap baseline and change observation
Toolstore learned to read one or several sitemap sources as a single URL set and preserve a trusted baseline between checks.
View development record
Objective
Detect added, updated and removed canonical URLs without interpreting individual PrestaShop product events. Sitemap indexes, compressed sitemaps and public sitemap lists needed to be accepted as sources on the same shop domain.
Safety rule
Every configured source is treated as part of one complete set. If a required source fails, Toolstore keeps the previous trusted baseline instead of treating missing input as deleted storefront URLs.
Failure and correction
The first 0.6.0 installation failed while constructing the sitemap observer. The observer was corrected and the following versions successfully read four sources, stored 1,913 unique URLs and recorded changes without submitting them automatically.
Automatic IndexNow notifications
Sitemap changes were connected to IndexNow through an opt-in daily process that never submits the initial baseline.
View verification record
Publication safeguards
- Automatic notifications are disabled by default.
- The initial sitemap baseline is never submitted.
- Only later added, updated or removed URLs are forwarded.
- The process runs at most once per local day.
Operational model
The first storefront visit after the configured time may start the daily check. A protected cron address remains an optional fallback for shops without regular traffic and its token can be rotated by the administrator.
Verified result
Four sitemap sources and 1,913 unique URLs were preserved during an automatic run. No false changes were detected, no unnecessary submission was made and subsequent page views did not start a second run on the same day.
Meta Pixel consent handling
Toolstore introduced a controlled choice between an existing GTM/sGTM implementation and direct Meta Pixel loading.
View development record
Direct browser mode
A directly configured Pixel waits until the DOM is ready and marketing consent is granted. No Meta request is made after denied consent and one PageView is permitted per page view.
Conflict prevention
Toolstore does not load a second browser Pixel when an existing implementation is detected. Websites using GTM or sGTM can declare that Meta is handled there instead of supplying a direct Pixel ID.
Product decision
Meta became its own configuration section. Irrelevant fields are hidden, consent withdrawal can send a revoke signal and the website owner chooses the delivery path explicitly.
Commerce event discovery
Toolstore mapped PrestaShop storefront behaviour to a neutral set of commerce events before connecting those events to any recipient.
View verification record
Events observed
page_viewview_item, including variant changesadd_to_cartbegin_checkoutpurchasefrom a completed PrestaShop order
Why the event model remained neutral
The storefront should identify one commercial event once. Recipient-specific formatting for GA4, Google Ads, Meta or Customer Reviews can then be applied later without creating several conflicting versions of the same order.
Result
Product IDs, variant IDs, SKUs, quantities, values and currency were observed locally. Events remained in browser memory and the Console, with no Google, Meta or Toolstore recipient.
Google Customer Reviews
Toolstore verified that a genuine PrestaShop order confirmation could create the required Customer Reviews opt-in data without storing customer identity in the diagnostic result.
View verification record
Readiness requirements
- Merchant ID
- Order reference
- Delivery country
- Customer email present but masked in diagnostics
- Conservative estimated delivery date
Safety requirements
- No Google recipient during readiness testing.
- No email address or customer identity stored in the result.
- The same order cannot trigger a second opt-in on reload.
- An existing Customer Reviews implementation blocks Toolstore’s render.
Verified result
A genuine order reached the PrestaShop order-confirmation hook two seconds after registration. The order reference, country, Merchant ID and estimated delivery date were correct, while the email value remained masked and external recipients remained empty during the preview.
Later tests recorded blocked while the previous module remained active and attempted after that module was disabled, confirming the duplicate-installation safeguard.
First-party commerce diagnostics
Commerce events were moved from a browser-only prototype to a local first-party endpoint on the website’s own server, still without any external recipient.
View development record
Neutral event envelope
Each event received a schema, unique event ID, timestamp, consent snapshot and source. Recipient-specific delivery was deliberately excluded from this stage.
Stored diagnostic scope
PrestaShop retained only sanitized validation results. SKU, order reference, customer email, IP address and browser identity were excluded from the persistent diagnostic table.
Development record
- Page views, products, carts and checkout reached the local endpoint.
- Variant changes produced updated
view_itemevents. - Genuine purchases were captured server-side from PrestaShop.
- A failed database write no longer consumed the one-time purchase test silently.
- A timestamp offset was corrected and verified against the order record.
Outcome
The complete sequence from page_view to a genuine
purchase was verified through the website’s own
server. This established the neutral event foundation required
for later server-side recipient adapters.
Clean module identity and controlled handover
The development module was replaced by a clean Toolstore package with isolated storage, disabled defaults and a controlled migration path from Toolstore Light.
View migration record
Copied deliberately
- Integration and verification values
- Clarity and Meta choices
- IndexNow identity and sitemap history
- Customer Reviews readiness and protected order history
Excluded deliberately
- Development test tokens
- Previous cron token
- Commerce diagnostic history
- Purchase observer state
- Automatic or live activation
Safety state
After import, Toolstore remained disabled, test-only and unable to submit IndexNow notifications, Customer Reviews opt-ins or Commerce events. A final synchronization was required before the controlled handover.
Verified handover
The initial migration copied 1,913 sitemap snapshots, 15 changes and 77 protected Customer Reviews orders. The final handover contained 79 protected orders, proving that the two orders placed between migration and handover were included. The previous module was then safely removed.
Privacy Engine and public privacy state
Toolstore separated consent input from the services that consume it and published a neutral, machine-readable description of the current privacy decision.
View verification record
Architecture
Cookiebot no longer needed separate direct connections to GA4, Clarity, Meta and Commerce. Its signals were translated once into neutral analytics and marketing states consumed by every Toolstore integration.
Published state
The browser-readable state reports schema version, active policy profile, consent source, current analytics and marketing decisions and explicit exceptions such as Clarity limited mode. It contains no recipient IDs or personal data.
Verified transitions
- No decision: fail-safe state while the CMP waits.
- Deny: analytics and marketing denied.
- Accept: analytics and marketing granted.
- Changing the decision updates the state without rebuilding each integration.
Consent solution discovery
Toolstore learned to detect and verify the site’s consent technology in one isolated browser instead of asking the website owner to select a technical adapter manually.
View development record
Discovery safeguards
Discovery runs in a temporary storefront session with Toolstore’s GA4/GTM, Clarity and Meta recipients disabled. The result is stored locally and visitor consent is not stored.
Activation rule
Detecting a script is not sufficient. Toolstore must identify a supported CMP and confirm that its consent signal is readable. Multiple or unclear signatures do not change the active adapter.
Result
Cookiebot runtime and script evidence were detected, the signal was readable and the Cookiebot adapter was configured automatically. The configuration was redesigned so the website owner chooses the privacy policy while Toolstore identifies the consent technology.
Multiple consent platform adapters
The neutral Privacy Engine was extended with foundations for Cookiebot, OneTrust and Usercentrics without changing the consent model used by Toolstore integrations.
View verification record
Common requirement
Every adapter must translate its real consent signal into the same neutral analytics and marketing decisions. If the signal model is unclear, Toolstore fails closed and does not activate the adapter.
Evidence used
- Cookiebot was verified live inside Toolstore on Montano.
- Usercentrics accept and deny events were examined against its modern Browser SDK.
- OneTrust pending, accept and deny states and service-to-group mappings were examined against OneTrust.
Regression result
After adding the additional adapter foundations, Montano still autodetected Cookiebot and returned denied/denied after rejection and granted/granted after acceptance. The existing production path was unchanged.
Every CMP speaks its own language. Toolstore must verify and translate that language rather than infer consent from the presence of a script, GTM container or standard category name.
Cookiebot: live Toolstore verification
Cookiebot was verified on Montano with Toolstore installed and controlling its own integrations. Denied statistics and marketing consent were translated to denied Toolstore states, while accepted consent produced granted states.
Google traffic from the store’s separate existing GTM installation remained observable after consent had been denied. This demonstrated that a banner decision does not by itself prove that every tag in an independently configured GTM container enforces the same decision.
OneTrust: vendor-site observation
The OneTrust signal model was examined on onetrust.com, using the vendor’s own production website.
The installation did not use the clean C0002/C0004 group model assumed by the first prototype. Its real groups and service mappings were defined by the website’s own OneTrust domain configuration.
Toolstore was therefore changed to read the installation’s actual groups and service mappings during discovery instead of hard-coding standard category identifiers. This verified the real OneTrust signal structure, but not a complete Toolstore installation on a OneTrust-controlled storefront.
Usercentrics: vendor-site observation
The Usercentrics V3 signal model was examined on usercentrics.com, using the vendor’s own production website.
After statistics and marketing were denied, Google Tag Manager remained classified as an essential service. Toolstore could therefore not use GTM consent as evidence that analytics or marketing had been granted.
The adapter was changed to evaluate individual service categories and consent signals. This verified the real Usercentrics signal structure, but not a complete Toolstore installation on a Usercentrics-controlled storefront.
Regional privacy policy registry
Consent technology and legal policy were separated so that the same CMP adapter can support explicitly defined regional behaviour.
View development record
Design boundary
Toolstore does not infer legal compliance from a country name and does not silently treat the United States or Brazil as simplified copies of European consent rules. Only defined and tested policy behaviour is offered.
Machine-readable declaration
The selected policy ID, profile and runtime version are published in the privacy state. A future Privacy Check can compare the declared policy, CMP signal and observed network behaviour.
Verified result
Existing installations retained the European policy during the upgrade. Unknown or manipulated policy values block rather than falling back to a permissive profile. Configuration and runtime versions were confirmed as synchronized in 0.18.1.
Configuration and status architecture
Toolstore’s configuration was reorganized so that each function owns its settings and controls while one compact status panel reports required actions.
View development record
Function-based controls
Consent discovery, Clarity decisions, IndexNow testing, sitemap observation, Commerce diagnostics and Customer Reviews readiness were placed with their corresponding configuration instead of being repeated in one large diagnostics section.
Compact status overview
The status panel reports whether an area is verified, requires a test or is blocked by an error. Each result links back to the relevant configuration section where the required action can be performed.
Outcome
The status overview was moved to the top of the configuration page while the detailed controls remained in a logical setup order. The change also preserved physically versioned runtime delivery and avoided unnecessary whole-store cache clearing on a normal save.
Global Privacy Control observation and enforcement
Toolstore learned to distinguish between merely observing a GPC signal and enforcing it under a policy that defines an opt-out response.
View verification record
Observation stage
Version 0.20 read GPC from the HTTP signal and browser API and
published the result in the privacy state. Under existing
prior-consent policies it remained observed_only
and did not silently change integration behaviour.
Enforcement stage
Version 0.21 added an explicit US opt-out/GPC policy. With active GPC, Toolstore records a do-not-sell-or-share request, marks the signal as enforced and blocks the external integrations controlled by Toolstore, including Clarity.
Policy isolation
Without GPC, the US profile retains its normal opt-out behaviour. With the Global prior-consent profile, GPC remains observed only. The new US policy therefore did not change existing installations or reinterpret policies that had not defined GPC enforcement.
WordPress
Toolstore Light for WordPress
The WordPress version of Toolstore Light is currently in development.
WordPress
Features
Available features will be published as development progresses.
WordPress
Installation
Installation instructions will be available at launch.
WordPress
Test Log
Testing is in progress. Results will be published here.