An unfamiliar script is present on the homepage, articles, forms and checkout. Because it appears globally, its source is likely a shared template, hook, plugin, database option, cache injection or external tag system.
Unknown does not automatically mean malicious. Analytics, consent and accessibility tools also load globally. Establish ownership and behaviour before removing it.
Preserve the exact public markup
Save the logged-out HTML from an affected page with timestamp and response headers. Record the script URL, inline content, attributes and its position in the document.
Compare two templates and a logged-in view. If the code disappears for administrators, that selective condition increases suspicion.
Do not execute an unfamiliar URL directly or paste the script into an online decoder.
Trace the script’s initiator
If the script tag exists in initial HTML, search the WordPress codebase and database for a distinctive URL or string. If JavaScript creates it later, use the browser network initiator chain to find the parent script.
Check whether a service worker or browser extension inserts it. Repeat in a clean disposable profile to eliminate local extension effects.
External domains should be verified against the documented integrations, not judged only by their name.
Inspect global WordPress insertion points
Review theme header.php, footer.php, functions.php, child-theme code, must-use plugins and snippets plugins. Search callbacks attached to wp_head and wp_footer.
Check active plugins that add header/footer scripts, analytics or adverts. Inspect their settings and recent changes.
Do not edit a parent theme or plugin file to delete one line. Preserve evidence and fix the source layer so updates do not restore or conceal the change.
Search database-controlled markup
Global scripts can live in widget blocks, reusable blocks, theme modifications, page-builder templates or wp_options. Use read-only database searches or WordPress-aware tools that preserve serialised data.
Search for the exact external hostname or distinctive code fragment, not generic terms like script.
Before changing an option, export it and identify its owner. Deleting a large settings array can break the site beyond the injected field.
Review tag manager and CDN modifications
A tag-manager container can add JavaScript without changing WordPress. Review published versions, custom HTML tags, users and consent triggers.
Some CDNs offer script optimisation or application injection. Confirm enabled apps, workers and transformation rules.
If an external account was compromised, revert to a known version, revoke unknown sessions and strengthen access. WordPress cleanup alone will not prevent reinjection.
Determine what the script does
Analyse in an isolated environment. Record domains contacted, storage created, DOM changes, redirects and form/checkout access.
Code that reads payment fields, downloads executables, creates hidden iframes or redirects visitors demands immediate containment. A legitimate but obsolete analytics script may require planned removal rather than an incident response.
Do not submit live checkout data while an unknown script can observe the page.
Clean and verify globally
Preserve filesystem/database evidence, remove confirmed malicious code at its source, close the entry route and rotate affected credentials. Purge relevant page/CDN caches after the origin is clean.
Retest representative templates, languages and WooCommerce pages from fresh profiles. Search public HTML and network requests for the old hostname and monitor for reappearance.
Check transactional email templates too if the same database-controlled footer or tracking integration can populate them.
When to request help
Request an assessment when script ownership is unclear, it appears only to visitors or touches checkout. Send the public URL and script hostname as text, without credentials or copied executable payload.
The repair should establish ownership, remove all insertion paths, protect sensitive journeys and verify the code is absent from every shared template.