How to investigate invalid AdSense traffic without creating more of it

Start an invalid-traffic investigation by reducing the suspected source of harm and preserving evidence. Do not click an advertisement to test it, ask readers to support the site through ad clicks or buy more visits to make the numbers look normal. Those actions can create the very problem you are trying to understand.

Google's definition of invalid traffic covers artificial impressions and clicks, including accidental clicks and the publisher's own clicks on live ads. A suspicious spike is a reason to investigate, not proof that every visitor in a country, referral source or device group is fraudulent.

Separate the account notice from your own hypothesis

Read the notice in the AdSense account and record its exact wording, date and affected scope. An earnings adjustment, an ad-serving limit and an account closure are different events. Do not assume a remedy described for one applies to the others. Keep the account's current instructions beside the incident record so the response follows the actual notice.

Write down what changed before the first anomaly: a new promotion, traffic supplier, page template, ad placement or plugin. Include the time zone used in each report. If traffic data and earnings data use different reporting boundaries, a daily comparison may conceal the sequence rather than reveal it. Preserve the original exports before changing filters.

Make a short hypothesis list with evidence for and against each possibility. A new referral source could be relevant; so could a button that moved beside an ad on small screens. Listing both prevents a premature explanation from steering every later check. Do not describe a third party as an attacker without evidence supporting that conclusion.

Investigate sources and placements separately

Google's prevention guidance recommends meaningful traffic segmentation and checking implementations across browsers and platforms. For an operator, the useful next step is a comparison of similar pages and periods: the affected page against an unaffected page, and the period after a change against the period before it.

Use data already available through the site's permitted measurement setup, ad reports and relevant server records. You do not need to add a new analytics service merely to begin. Look for an identifiable source or implementation change, then document what the data can and cannot show. A burst of requests is not, by itself, a record of paid ad clicks.

Inspect the rendered layout without interacting with live advertisements. Check narrow screens, navigation menus, sticky elements, consent states and slow loading. A hypothetical download button that shifts when an ad arrives can create a very different problem from a traffic supplier sending automated visits. The response should address the observed mechanism, rather than apply the same fix to both.

Keep internal testing separate from genuine audience activity. Ask developers to use appropriate test arrangements and the ad provider's guidance. A well-intentioned colleague checking whether an advertisement opens correctly should not become part of the traffic-quality incident. Record which changes reached production and when, so the next report can be interpreted against the correct version.

Contain a plausible cause and keep a record

If a newly purchased traffic campaign coincides with the anomaly, pause that campaign while examining its placement and delivery records. If a specific layout makes accidental interaction plausible, correct that layout and verify the page in the affected state. A narrow, reversible intervention is easier to evaluate than changing every ad position and every acquisition source at once.

Preserve relevant timestamps, page paths, campaign identifiers and before-and-after screenshots of your own implementation. Exclude unnecessary personal data from the working incident file. If information must be sent through an official support route, supply concise evidence about what happened and what changed, rather than an unsupported theory about Google's private detection systems.

Avoid claiming that a firewall rule can remove all invalid activity. A server-side block and an ad system's classification are different controls. Overbroad restrictions can also exclude genuine readers. Review the effect on normal page access, particularly if a rule targets an entire network, location or device class instead of the actual problematic behavior.

Decide whether the intervention worked

Keep comparable reporting periods and document the date each intervention began. Review traffic composition, affected ad units and account notices together. A lower estimated earnings figure is not a reliable verdict on its own. Reconcile estimates and finalized earnings before treating an adjustment as a new incident or a successful repair.

Google says ad-serving limits can be applied while it assesses traffic quality or addresses concerns. That makes a promise of immediate restoration inappropriate. Follow the instructions shown for the account and continue monitoring; do not open a replacement account or alter identifying details as an improvised workaround.

Close the incident with a factual record: the original symptom, the supported cause if established, the changes made, the observations afterward and remaining uncertainty. Add a simple prevention check to the regular publishing routine. If the problem began with a promotion, review the traffic source before the next campaign; if it began with layout, review the template before the next release.

This process protects a revenue model rather than replacing one. Compare the continuing cost of monitoring and moderation with the site's broader monetization choices. The decision should rest on usable evidence and sustainable operations, not on a promise that any tool can make ad traffic risk disappear.