Who Else Loads When the Basket Opens? A Third-Party Script Audit for UK Checkouts
Third-party scripts rarely arrive with a clear warning. They come attached to a campaign, a support widget, a review request or a payment feature, and each is approved on its own merits. Over time, the checkout becomes a meeting point for domains that no single person owns. That is the side door: not a malicious implant, but an accumulation of small, plausible additions.
For UK small and medium-sized businesses, the commercial risk is easy to see. A script running on the basket page can observe form fields, set cookies, change layout or delay the payment step. The regulatory risk is less visible but no less real. UK GDPR and PECR expectations apply to what is collected and when; payment card data brings PCI DSS scope into the conversation. The audit below is not a legal opinion. It is a practical way to establish what loads, for whom, and on which pages before the 2026 seasonal trading period puts the site under strain.
Begin with the pages that carry money and identity
Do not start with a site-wide crawl. Start with the pages where a failure would matter: login, password reset, account details, enquiry forms, basket, checkout, payment confirmation and any page that accepts a file upload. In a private browser window, open developer tools and record the network requests. Disable cache so that you see the full load. Note every external domain, the script file, the page it appears on, the cookies it sets and the business owner who requested it. A simple spreadsheet is enough. The point is to replace impressions with evidence.
Follow the container, not just the template
Most SMEs do not hard-code every script. They use a tag manager. Export the container and compare its tags with what the browser actually requests. Pay attention to custom HTML tags, older pixels that were meant to be retired, duplicate analytics properties and tags that fire on all pages because nobody set a page rule. Check whether preview or debug modes are still enabled. A tag manager is a legitimate tool, but it concentrates power. If two people can publish a tag without review, the checkout has a side door with a shared key.
Test consent as a customer would
Consent behaviour is where policy and reality often separate. Use a fresh browser profile, clear cookies and load the site as a new visitor. Choose the most privacy-protective option first. Then inspect the network panel: which domains still load, which cookies are written, and which requests carry identifiers? Repeat with analytics accepted but advertising rejected. Finally, accept everything and compare. Record screenshots with dates. The question is not whether a consent banner appears. It is whether non-essential scripts remain silent until the correct choice is made. Pay particular attention to checkout, where consent tools sometimes exempt everything as strictly necessary without evidence.
Put guardrails around the weakest link
Technical controls will not replace a register, but they reduce the blast radius. A Content-Security-Policy can limit which domains may supply scripts and where data may be sent. Start in report-only mode, collect violations for a week, then enforce a policy that reflects the scripts you have actually approved. Subresource Integrity helps for static libraries with pinned versions; it is less useful for dynamic tag managers, which is precisely why those containers need tighter change control. Where a vendor offers first-party hosting or a documented allowlist, use it. Review whether advertising tags need to run on checkout at all. Often they do not.
Decide what to remove, replace or isolate
Every entry in the inventory should end with a decision. Remove tags with no owner or clear purpose. Replace overlapping tools, such as two chat widgets or three review scripts, with one. Isolate payment-related scripts to the pages that need them and keep advertising and session-replay tools away from card entry and account recovery. If a script must remain, document why, who approved it and when it will be reviewed. Server-side tagging can move collection away from the browser, but it does not remove the need for consent, contracts and a data map. It changes the plumbing, not the accountability.
Make the register survive the next campaign
The audit is only useful if it becomes part of normal operations. Add third-party scripts to the change process, alongside new starters and software renewals. Give each script a named owner, a purpose, the pages it may run on, its consent category, the contract or data processing agreement that covers it, and a review date. Keep an emergency removal note: how to disable the container, which tags to pause and who can publish the change. Repeat a spot check each quarter and before major trading periods. If a privacy complaint or checkout incident arrives, the register will not answer every question, but it will shorten the first hour considerably.
The checkout should have fewer guests than it does. Finding out who is already inside is an afternoon's work, provided someone is given the authority to ask for evidence and act on the answer.
