Skip to main content

Script Inventory

Introduction

Modern eCommerce websites rely on a complex web of JavaScript to function, ranging from core platform files (like your theme and checkout scripts) to external third-party tools for analytics, marketing, and customer support.

However, unmonitored scripts—whether internal or external—can cause significant issues. Bloated theme files can drastically slow down page load times, while unauthorized code injections can lead to severe security vulnerabilities like supply chain attacks and payment skimming (Magecart).

The Script Inventory feature in AuditIQ acts as an automated ledger, maintaining a comprehensive and up-to-date list of every single JavaScript file executing across your online store. This gives merchants and agencies absolute visibility into what code is running, where it is loading, and when it was introduced, ensuring both optimal performance and strict site security.

Understanding Your Script Inventory Data

The dashboard presents a clear, sortable table of all detected scripts (both first-party and third-party) across your monitored environments:

  • Hostname: The specific domain or subdomain (e.g., shop.example.com) where the script is actively running.

  • Script URL: The direct source link of the script itself. This helps you quickly identify whether a script belongs to your core platform (e.g., /static/frontend/theme/main.js), a known external marketing tool, or an unrecognized third party.

  • First Seen URL: The specific page on your website where AuditIQ first detected the script executing (e.g., https://shop.example.com/checkout). This is crucial for isolating exactly where a script was injected or called.

  • First Seen At: The exact date and time the script was initially discovered. A sudden appearance of an unknown script here can be an early warning sign of a compromised site, or it can simply help you verify when a new feature was deployed.

  • Last Seen At: The most recent date and time AuditIQ verified the script was still active. This is highly useful for verifying that a removed app, deleted tracking pixel, or deprecated core file is truly gone from your codebase.