Google clarified on August 15, 2026 that AI Overviews are counted and logged in the Search Console Performance report using the same methodology applied to other search result features. This is not a report change. Teams can still create a false before-and-after story by treating the documentation date as a measurement launch, combining standard and generative reports without labeling overlap, or promising query-level attribution that the available view does not provide.
Use this for SEO teams, agencies, content leaders, executives, publishers, ecommerce businesses, and anyone reporting organic or generative-search visibility from Search Console.
Quick answer
Annotate August 15 as a documentation clarification only. Preserve the unfiltered Performance totals as the reporting baseline, then inspect any available generative AI report separately by page, country, device, and date. Record report availability, filters, export time, freshness, and metric definitions. Never add the generative report to total Search figures unless the product explicitly defines the sets as disjoint.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
| Standard Performance | Unfiltered web report | Authoritative total baseline |
| AI report available | Pages, country, device, dates | Label as specialized visibility view |
| AI report unavailable | No dedicated navigation | Do not infer zero visibility |
| August 15 annotation | Documentation update | No artificial launch trend |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
| Create an unfiltered Performance baseline with explicit dates and filters. | Record property, report URL, date range, search type, filters, last update, export time, timezone, and report availability. | The standard Performance baseline matches the exported property and date range. |
| Annotate documentation clarifications separately from product changes. | Capture total clicks, impressions, CTR, position, top pages, countries, devices, and dates before opening a specialized view. | August 15 is labeled as a documentation clarification. |
| Review specialized AI visibility by its supported dimensions. | Document the August 15 clarification and separate it from actual product or data changes. | Specialized AI visibility is not added blindly to overall totals. |
| Prevent double counting and unsupported query or conversion claims. | Compare specialized generative report dimensions and totals without assuming missing query-level data. | Recommendations point to named page cohorts and measurable follow-up work. |
What to check first
- Record property, report URL, date range, search type, filters, last update, export time, timezone, and report availability.
- Capture total clicks, impressions, CTR, position, top pages, countries, devices, and dates before opening a specialized view.
- Document the August 15 clarification and separate it from actual product or data changes.
- Compare specialized generative report dimensions and totals without assuming missing query-level data.
- Add plain-language caveats for overlap, freshness, position methodology, small numbers, and stakeholder interpretation.
Field notes
- Keep exported files and screenshots with property, date range, and filter labels.
- Do not calculate uplift from a report that was not consistently available across both periods.
- Use page cohorts and content updates for decisions, not a single small daily value.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
snapshot,range,report,clicks,impressions,ctr,position,filters,note
A,28d,performance,19,1781,1.1%,19.2,web,baseline
B,28d,generative,available,available,n/a,n/a,page+country,specialized
C,2026-08-15,annotation,n/a,n/a,n/a,n/a,none,method_clarification
Why this usually happens
- Documentation dates are easily mistaken for feature-release dates.
- Specialized reports can overlap with the overall Performance totals.
- Stakeholders may expect conversion or query detail that the report does not expose.
Decision rule
Publish the report only when totals, specialized views, dates, filters, overlap, availability, and caveats are labeled well enough that a reader cannot mistake a methodology clarification for new traffic.
Production verification checklist
- The standard Performance baseline matches the exported property and date range.
- August 15 is labeled as a documentation clarification.
- Specialized AI visibility is not added blindly to overall totals.
- Recommendations point to named page cohorts and measurable follow-up work.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Create an unfiltered Performance baseline with explicit dates and filters.
- Annotate documentation clarifications separately from product changes.
- Review specialized AI visibility by its supported dimensions.
- Prevent double counting and unsupported query or conversion claims.
- Use page cohorts, internal links, and business outcomes to guide improvements.
Mistakes to avoid
- Do not change several production layers at once. Preserve the failing evidence and isolate one variable per test.
- Do not treat a successful request, quiet log, or correct screenshot as proof that the complete user outcome is correct.
- Do not leave debug logs, test records, broad credentials, temporary roles, or browser overrides active after verification.
- Do not close the work without recording versions, fixture IDs, UTC timestamps, owner, result, and rollback point.
Questions teams ask during testing
Can this be tested on staging?
Start on staging with production-like versions, roles, data volume, cache, browser behavior, and integrations. Finish with one controlled production fixture when the result depends on the real CDN, email provider, worker clock, crawler response, or browser storage.
What evidence should be retained?
Keep exact versions, stable IDs, UTC timestamps, sanitized requests or logs, expected result, actual result, decision, and final verification. Redact customer data, cookies, secrets, order keys, and full advertising identifiers.
When should the change be rolled back?
Roll back when a revenue, privacy, accessibility, security, publishing, or lead path fails and the cause cannot be isolated inside the approved maintenance window. Preserve the failed fixture before rollback.
What to tell the client or owner
Give the owner the affected versions, exact fixture, stable IDs, UTC timeline, before and after evidence, decision, rollback point, unresolved risks, and next review date.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, build an honest AI search report.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Reconcile specialized AI visibility with total Performance
Use the Search Console AI Overviews overlap reconciliation to align dates and filters, label unsupported dimensions, and prevent specialized AI impressions or clicks from being added twice.
Helpful references