A website can be up, return 200 OK on every check and still be serving content you did not put there. An injected card skimmer, hidden spam pages or a defacement message do not change the status code, so a check that only looks at the status code stays green. Keyword monitoring closes part of that gap: on every check it confirms that the response contains the text it should and does not contain the text it should not.

Published estimates of how long these compromises last vary widely, because they measure different things. Jscrambler reported in July 2021 that Magecart web skimming attacks “remain active for 22 days on average before being detected” (it gives no methodology). Gemini Advisory's 2021 annual report (archived copy) put the average length of infection for the Magecart infections active in 2021 at 171 days. In the British Airways case, the UK Information Commissioner's Office penalty notice found that the skimming script was active for 15 days, from August 21 to September 5, 2018. None of these is a general rule, but all of them are measured in days or months, not minutes.

This article covers what breaches cost, how defacement, SEO spam and payment skimmers show up in the data, what PCI DSS now requires for payment page scripts, and exactly what Site Qwality keyword monitoring can and cannot catch. Figures come from 2024 to 2026 sources unless a sentence names an older year, and every source is listed at the end.

The Financial Stakes: Breach Costs and Regulatory Enforcement

The IBM Cost of a Data Breach Report 2026 is the 21st edition. It is based on Ponemon Institute research with 602 organizations in 17 industries and 16 countries and regions, covering breaches from March 2025 to February 2026, and IBM published it on July 29, 2026. The global average cost of a breach rose 12% to a record $4.99 million, and the US average reached a record $11.5 million. Detection and escalation ($1.64 million) and lost business ($1.54 million) made up 63% of the cost.

The mean time to identify and contain a breach rose to 247 days (183 to identify and 64 to contain), up from 241 days in the 2025 report and reversing a five-year decline. Customer personally identifiable information was involved in 52% of breaches. Organizations that used AI and automation extensively in security operations had an average breach cost of about $4 million, compared with $5.93 million for those that did not use them, a saving of $1.93 million, and they shortened identification and response to 215 days against 280 days. Healthcare remained the costliest industry for the 13th consecutive year at $6.64 million, followed by financial services at $6.29 million.

IBM also tracks how attackers get in. Phishing was the top initial attack vector for the fourth year in a row. Supply chain compromise came second, with an average cost of $4.96 million and an average of 258 days to identify and contain. That matters for website compromises: when a third-party JavaScript library, WordPress plugin or payment integration is compromised, your site becomes the delivery vehicle even though you did not change a line of your own code.

On the regulatory side, the DLA Piper GDPR Fines and Data Breach Survey, January 2026 (its 8th annual) counts cumulative GDPR fines of €7.1 billion across the jurisdictions it surveys, from May 25, 2018 to January 10, 2026, with about €1.2 billion issued in the year beginning January 28, 2025, broadly matching the previous year. The largest single fine remains Meta's €1.2 billion penalty from the Irish Data Protection Commission, announced on May 22, 2023, for unlawful EU-to-US data transfers. The same survey counts an average of 443 breach notifications a day between January 28, 2025 and January 27, 2026, up 22% from 363 a day, and the first time the average passed 400 since GDPR took effect.

Article 33 of the GDPR requires controllers to notify the supervisory authority within 72 hours of becoming aware of a personal data breach. The European Commission's Digital Omnibus proposal (COM(2025) 837, published November 19, 2025) would change Article 33 to 96 hours, limit notification to breaches likely to result in a high risk, and route reports through a single entry point that ENISA would build. As of October 17, 2026 it is still a proposal: the European Parliament's legislative observatory lists it as awaiting a committee decision.

Website Defacement and SEO Spam

Sucuri's SiteCheck Malware Trends Report 2024 is built from 70.8 million website scans run through SiteCheck, Sucuri's public remote scanner that any user can submit a URL to. It detected 1,176,701 infected websites, an infection rate of 1.66% across those scans. Because people choose which sites to scan, the sample is not a random cut of the web, but the mix of what it found is informative:

  • SEO spam: 422,741 websites.
  • Japanese SEO spam (reported separately): 117,393 detections.
  • Defacement: 8,452 websites, about 0.8% of infections. Of these, 7,513 involved direct visual modification, where attackers replaced a site's content with their own messages or images.
  • Magecart-style card stealers: 18,622 websites.

Visible defacement is the rare case. The common compromises are quiet: spam pages and injected code that the site owner often does not see. In the Japanese keyword hack, Google's documentation on web.dev explains, the attacker “typically creates new pages with autogenerated Japanese text on your site” that are monetized with affiliate links and appear in Google Search. Hackers also use cloaking: “Hackers will try to trick you into thinking the page is gone or fixed when it's still hacked.” Google notes that the URL Inspection tool in Search Console can reveal the hidden content, and that the hacker will typically add themselves as a property owner in Search Console.

When Google detects a hacked page it can warn searchers. Google's Search Help describes the “This site may be hacked” label, and the Security Issues report lists the categories Google flags, including hacked content. Google does not publish a figure for how much traffic a site loses, so we do not quote one.

WordPress: The Most Targeted CMS

W3Techs reports that WordPress is used by 39.6% of all websites (and 58.4% of sites whose CMS it can identify), as of October 17, 2026. Most of the risk sits in plugins. The Patchstack State of WordPress Security in 2026 report (updated February 25, 2026) counted 11,334 new vulnerabilities in the WordPress ecosystem in 2025, a 42% increase on 2024. Of those, 91% were in plugins and 9% in themes, and only 6 were in WordPress core. Patchstack found that 46% of vulnerabilities did not receive a fix from the developer in time for public disclosure, and that the median time to mass exploitation for heavily exploited vulnerabilities was 5 hours.

The Melapress WordPress Security Survey 2025 is a vendor-run survey of 264 respondents, so treat it as indicative rather than representative. In it, 96% said they had experienced a security incident, 64% a breach, and 50% named website defacement as a top concern. Of those concerned about defacement, 37% did not use activity logs.

Magecart and Payment Card Skimmers

Magecart-style skimmers are JavaScript added to a checkout page that copies card details while the purchase completes normally. Sansec states that as of 2022 it had identified over 70,000 compromised stores that contained a digital skimmer at one point in time. Recorded Future's 2024 payment fraud report counted nearly 11,000 unique e-commerce domains with Magecart infections in 2024, a threefold increase from 2023. Its 2025 report (published February 2026) counted more than 10,500 unique e-skimmer infections active at any point in 2025, which it describes as stable compared with 2024, and estimates that they compromised at least 23.4 million transactions. For scale, Symantec's 2019 Internet Security Threat Report counted 4,818 unique websites compromised with formjacking code every month in 2018.

Detection is slow because nothing breaks. Jscrambler describes the shopper and the company as both unaware that the attack has taken place. Three documented cases show the range:

  • British Airways, 2018: the ICO found that an attacker who gained access on June 22, 2018 edited a JavaScript file on the airline's website, and that the skimming code was active for 15 days (August 21 to September 5, 2018). It believed the attacker potentially accessed the personal data of approximately 429,612 individuals. The ICO proposed a penalty of £183.39 million in July 2019 and imposed a final penalty of £20 million in October 2020. In July 2021, BA settled the group action brought by affected customers, and the terms were not disclosed.
  • National Baseball Hall of Fame, 2018 to 2019: according to the notification it filed with California, a malicious script was injected into its online store between November 15, 2018 and May 14, 2019, and the Hall of Fame learned of it on June 18, 2019.
  • Páramo, 2019 to 2020: The Register reported that a skimmer on the British outdoor clothing retailer's website went undetected for nearly eight months despite regular security scans, and that 3,743 people's full card details were stolen between July 2019 and March 2020.

Third-Party Code: Polyfill.io, CosmicSting and Browsealoud

Much of the code on a modern page is not yours. The Verizon 2026 Data Breach Investigations Report (May 19, 2026) found that 48% of breaches involved a third party, up from 30% in the 2025 report. That metric, third-party involvement, is broader than supply chain attacks: it combines several kinds of business relationship, one of which is a vendor in the software supply chain. Cloudflare reported in July 2024 that its typical enterprise customer uses an average of 47 third-party scripts, and a median of 20. Sonatype's 2026 State of the Software Supply Chain report identified more than 454,600 new malicious open-source packages in 2025, taking its cumulative total to over 1.233 million.

Three incidents show how a trusted dependency becomes the attack:

  • Polyfill.io, 2024: Sansec reported on June 25, 2024 that more than 100,000 sites embedded the cdn.polyfill.io script (a PublicWWW count) after a Chinese company bought the domain in February 2024. The injected code redirected mobile visitors to a sports betting site through a fake Google Analytics domain, and only ran on specific mobile devices at specific hours. Censys still detected 384,773 hosts embedding a script linked to the domain on July 2, 2024. That is a point-in-time count of hosts, not sites.
  • CosmicSting, 2024: one week after Adobe released a fix for the critical Magento and Adobe Commerce flaw (CVE-2024-34102), Sansec found that only a quarter of stores had been patched, which means about 75% were still exposed. By July 12, 2024, Sansec reported that 5 to 30 stores were being infected every hour.
  • Browsealoud, 2018: the UK National Cyber Security Centre confirmed that the third-party JavaScript library Browsealoud was compromised on February 11, 2018, and that anyone who visited a site embedding it inadvertently ran cryptocurrency mining code.

Dwell Time and the Detection Gap That Keyword Monitoring Fills

Mandiant's M-Trends 2026 report, based on more than 500,000 hours of incident investigations in 2025, puts the global median dwell time (the time from compromise to discovery) at 14 days, up from 11 days in the previous report. Mandiant attributes the rise largely to long-term espionage and North Korean IT worker operations. For comparison, the M-Trends 2018 report, covering October 2016 to September 2017, put the global median at 101 days. These figures describe intrusions that Mandiant investigated, not all compromises.

Who finds the compromise matters for monitoring. Across all 2025 investigations in M-Trends 2026, organizations first detected malicious activity internally 52% of the time (up from 43% in 2024). An external entity such as law enforcement or a security vendor notified them 34% of the time, and the adversary announced the compromise, for example in a ransom note, 14% of the time. In other words, 48% of the time someone other than the victim's own team found out first. For the previous report, M-Trends 2025, the median dwell time was 11 days when including all intrusions and 26 days when an external entity notified the victim.

General dwell-time figures say little about content-level compromises that return a normal status code. A site carrying an injected skimmer or spam pages returns 200 OK and looks fully functional. The payment still works, the customer gets the goods and the merchant is paid. In Jscrambler's description of a Magecart attack, neither the shopper nor the company is aware that it has taken place. Cloaked SEO spam can persist because the page shows different content to different visitors, so the owner looking at the site sees nothing wrong.

The same gap exists without an attacker. CMS failures, plugin conflicts, template errors, cached error pages, partial deploys and upstream API failures can all strip key content from a page while returning a healthy HTTP status code.

PCI DSS and Payment Page Scripts

PCI DSS v4.0.1 requirements 6.4.3 and 11.6.1 concern scripts on payment pages, and the PCI Security Standards Council states that they became effective on March 31, 2025. The standard itself is behind a license click-through, so we describe them from the Council's SAQ A-EP for PCI DSS v4.0. Requirement 6.4.3 says each script loaded and executed in the consumer's browser must be authorized, have its integrity assured and be listed in an inventory with a written justification. Requirement 11.6.1 calls for a change- and tamper-detection mechanism that alerts on unauthorized changes to HTTP headers and payment page contents as received by the consumer's browser, run at least once every seven days or at a frequency set by the entity's targeted risk analysis.

The Council also changed SAQ A, the questionnaire for merchants that embed a payment processor's form or iframe. It removed requirements 6.4.3 and 11.6.1 from SAQ A and added an eligibility criterion that merchants must confirm their site is not susceptible to attacks from scripts, and its FAQ 1588 explains how to meet it. The Council states that this does not remove or diminish the underlying requirements. These requirements target scripts running in the browser, which is a different job from checking the content your server returns.

How Site Qwality Keyword Monitoring Works

Keyword monitoring is part of every HTTP uptime monitor in Site Qwality, at no additional cost, and the free tier includes it. On each check it looks in the response for the text you specify and fails the check when the result does not match your rule. You can set:

  • Presence (must contain): the check fails when expected text is missing, such as a legal disclaimer, a trust badge or your brand name. This catches a bad deploy, a cached error page or a CMS change that strips content without any server error.
  • Absence (must not contain): the check fails when unwanted text appears, such as spam keywords, a known malicious script name or a defacement message.
  • Case-sensitive matching: optional per monitor, to tell “Apple” from “apple” or to notice your brand name changing capitalization.
  • Regular expressions: Rust regex syntax (no lookahead or backreferences, matched within a single line), so one pattern can cover a category of content, such as email addresses or script-injection signatures, instead of one fixed string.

A monitor holds one keyword and one mode, so to watch a URL for both missing and unwanted text, create two monitors. A failed check alerts you through Slack, Microsoft Teams, email, SMS or a webhook. How soon you find out depends on the check interval: the free tier checks every 5 minutes, and paid uptime plans check as often as every 30 seconds. See the keyword monitoring page for details and pricing for plans.

A keyword rule only detects what you thought to write a rule for, so pick text that is stable and meaningful, such as a footer line, a legal notice or a script you expect to load. It has limits that matter for the threats in this article:

  • A rule reads the response of the URL you monitor. It can flag an unexpected script tag or domain in that page's HTML, but it does not read the separate script files the page loads from other hosts, so it does not replace the script inventory and tamper detection that PCI DSS requirements 6.4.3 and 11.6.1 describe.
  • Content that an attacker serves only to search-engine crawlers will not normally appear in your monitor's request. For cloaked SEO spam, use Google Search Console's Security Issues report and URL Inspection tool alongside your monitors.
  • Site Qwality is not a malware scanner or a web application firewall. A failed rule tells you that a page no longer matches what you expect, and your security tooling and your host work out how it happened and fix it.

For flows that need a real browser, such as a login or checkout journey, Site Qwality's synthetic monitoring runs custom Playwright scripts on a schedule. It is a separate product from keyword rules.

Conclusion: Content Integrity as a Monitoring Concern

The data points one way: the gap between “the website is up” and “the website is serving what you intended” is real and measurable. Breaches take months to identify and contain (247 days on average in IBM's 2026 study), nearly half of the intrusions Mandiant investigated were first discovered by someone other than the victim, and Patchstack puts the median time to mass exploitation of heavily exploited WordPress vulnerabilities at 5 hours. An uptime check returns green throughout all of it.

A keyword rule on your homepage, checkout and login pages is cheap, takes a few minutes to set up and answers one question on every check: is the page still saying what it should? Create a free Site Qwality account and add a presence rule for a line that should always be on your page and an absence rule for text that should never be there.

Sources