Google Dropped Three Search Changes in Five Days: September Spam Update, Multimodal Search Console Data, and AI Mode Monitoring Goes Global

Three separate Google announcements in five days. A spam update carrying a rollout window no previous 2026 spam update has used. Brand-new multimodal data inside Search Console that John Mueller confirmed was never counted anywhere before. And AI Mode background monitoring agents reaching every Google user on the planet, no subscription required. If your team was heads-down on other work this week, here is the breakdown of what landed and what to act on.

The September Spam Update Is Still Rolling and the Timeline Is Different

Google launched its September 2026 spam update on September 24 at 9:15 a.m. Pacific. Fourth spam update this year. The unusual detail is the stated window: Google says the rollout may take up to two weeks to complete. March 2026 finished in 19.5 hours. June ran 48 hours. August took three days. This one could still be propagating through the index on October 8.

The escalating pattern across all four 2026 spam updates is worth noting. No prior calendar year in Google’s public release history has had four spam updates. The gaps between launches have shortened too, with only 37 days between August and September. Each rollout has taken longer than the one before it. That combination suggests the detection work behind this update is either broader in scope or targeting a type of spam that takes more time to process consistently across a global index.

What Google has not disclosed: which spam policies this update targets. No named tactic. No associated blog post. No share of queries affected. The announcement on the Search Status Dashboard read verbatim: “Today we released the September 2026 spam update to Google Search. This is a normal spam update.” That phrase appeared in the August announcement too. It offers no diagnostic signal.

The two-week window creates a specific data problem for your team. Ranking movements visible right now may reflect early update passes, incomplete propagation, or unrelated SERP shifts. A single-day traffic swing is not enough to confirm a spam hit.

Open Search Console. Set the Performance date range to September 17 through today. Segment by page and query cluster rather than the sitewide total. Drops that concentrate on thin template pages or pages that exist primarily to capture keyword volume are a different finding than drops distributed across service pages or editorial content with original research behind it. Recovery takes months if this update touches you. Google’s own policy documentation is explicit about that timeline.

Search Console Now Contains Data That Was Never in Your Reports Before

Same day as the spam update. September 24. Google launched a multimodal search type filter inside Search Console’s Performance report.

This is not a reclassification of something already in your numbers. John Mueller confirmed directly in a reply on September 24 that the multimodal data was not previously counted anywhere in Search Console totals. Not grouped under Web results. Not folded into Image search. Nowhere. What appears in the new filter represents traffic your site was already receiving from image-initiated searches with no way to see it.

The filter covers four entry points: Google Lens, Circle to Search on Android, image uploads to Google Search, and Chrome’s right-click “Search this image” feature. It lives inside the Performance report under Web, which Google has now split into Text-based and Multimodal sub-types. Multimodal reporting is also rolling out to the Generative AI performance report, so you will eventually see impressions from AI Overviews and AI Mode triggered by image queries.

One limitation to set correctly from the start: there is no query data. Because multimodal searches primarily use images rather than text, the Queries tab is unavailable when this search type is selected. You see which pages received impressions and clicks from image-initiated searches, broken down by country and device. For a product page, that is actionable. You learn which URLs are appearing in visual discovery flows. You just cannot see what the triggering image was.

A practical note on your year-on-year Web impression reporting. Because this data was never previously included in any Web totals, sites with visual-search visibility may show a step change in total impressions starting late September. That is a reporting change, not a traffic change. Do not re-baseline year-on-year Web comparisons until Google clarifies how the top-level Web aggregate handles the two sub-types.

For any client with a product catalog, portfolio photography, real estate listings, or a visually-driven brand: check for the filter as soon as it appears in your property. Sites with clean product schema, descriptive alt text, and original image files are positioned to see meaningful data here. Sites running generic supplier stock photos with default filenames will likely see less. One technical note: the Search Analytics API does not yet list a multimodal search type parameter as of the September 24 launch date. Export manually for now and check the API documentation before assuming your Looker Studio or warehouse dashboards pull this automatically.

AI Mode Monitoring Just Became Free for Every Google User

September 28. Two days ago. Robby Stein, Google’s VP of Product for Search, announced on X that AI Mode information monitoring is rolling out to all users globally through the Google app. Google AI Ultra and Pro subscribers have had the feature since June. Now it reaches every user across all AI Mode languages and markets with no subscription required.

The mechanism is straightforward. A user tells AI Mode what to watch. Google’s systems then continuously scan websites, forums, social posts, and real-time data sources, along with a Shopping Graph containing more than 60 billion product listings. When something relevant changes, the agent sends a synthesized update. It runs in the background around the clock without the user returning to Search to check.

Stein’s examples were local discovery and commerce: new restaurants or pop-ups opening nearby, local activities with kids, back-in-stock alerts, and price drops. Every example involves content that changes on a schedule or without warning. Every example describes a scenario where a user has historically returned to a site or search on their own initiative to check for updates.

That return-visit behavior is the structural question for publishers and retailers on your client list. When Google’s agent delivers a relevant update as a push notification, the path back to the source website is optional. A price drop notification that contains the new price and a product description may satisfy the user’s need without a click. Whether Google includes a link back to the product page in the notification is something Stein’s announcement did not specify, and the June announcement that described agent updates as including web links was not repeated in the September 28 post.

What is actionable right now: audit the freshness and accuracy of structured data, product feeds, local listing hours, pricing, and event details. Inventory levels and price data that are current and schema-marked give Google’s agents something concrete to retrieve and potentially link back to. There is no Search Console reporting for monitoring-agent referral traffic yet and no business enrollment flow. This is a data hygiene and structured markup story at this point, not a new optimization channel with measurable output.


Frequently Asked Questions

My traffic dropped after September 24. Is it the spam update or the multimodal data change?

Possibly neither, or both. Two things happened on September 24: the September spam update began rolling out with a two-week window, and Search Console started counting multimodal traffic that was never previously included in Web totals. A site with visual-search visibility may actually see impression totals rise rather than fall. Drops that cluster on specific page types or query clusters are more diagnostic than a sitewide average. The two-week rollout window means the update is still active, and interpreting rankings before it completes introduces noise into the analysis.

Does adding the Web: Multimodal filter reduce my existing text-based impression numbers?

No. John Mueller confirmed the multimodal data was not counted anywhere before September 24. It is additive, not a reclassification. Text-based totals are not reduced. Use caution with year-on-year comparisons on overall Web impression totals until Google clarifies how the top-level Web aggregate handles the two sub-types going forward.

How do I check whether AI Mode monitoring agents are sending traffic to my site?

You cannot yet. There is no Search Console report for AI Mode monitoring referrals and Google has not described a measurement path for this traffic. The practical move is to verify that product feeds, local listings, and structured data are current and complete so that when monitoring agents retrieve information about your content, it accurately represents what a user would find on arrival.

Elementor 4.3 Beta Introduces Native MCP: AI Agents Can Now Build and Manage Your WordPress Site Directly

What Just Changed

Elementor 4.3 beta shipped September 15 with native MCP support. That is not a minor version note. Any MCP-compatible AI client, including Claude Code, Cursor, and Codex, can now connect directly to your WordPress site and execute Elementor page edits in real time, without you opening wp-admin.

Not “generate content.” Build pages. Reorder containers. Apply global style tokens. Create headers and footers with display conditions. Inspect what is on an existing page and rework the layout. These are governed write operations with review gates, not clipboard assistance.

Agencies managing multiple WordPress installs will feel this immediately. So will marketing teams who have been waiting for AI tools that can actually do the work rather than describe it.

The Protocol Underneath

MCP stands for Model Context Protocol, an open standard that lets AI applications call actions on external systems rather than just talking about them. The AI client connects to your site, discovers what actions are available, reads your page structure and design system, and executes multi-step tasks.

WordPress 6.9 introduced the Abilities API, specifically wp_register_ability(), which lets any plugin or theme declare what it can do in a standard registry. The WordPress MCP Adapter bridges that registry over MCP. Elementor 4.3 registers its own set of abilities into that system and exposes them to whatever AI client connects.

The result: Claude knows your page structure. It knows your global colors and typography. It reads widget schemas for every plugin installed on your site. The more capable your Elementor setup, the more capable the AI agent.

What the Agent Can Do in 4.3

The beta adds a dedicated Elementor MCP page inside the WordPress dashboard, under the Elementor menu. Access is restricted to site admins. Connection is per-site via an application password that Elementor generates automatically when you select your client.

Supported clients on launch: Claude Code, Claude Desktop, Codex, Cursor, and an open “Other” slot for any MCP-compatible tool. Elementor generates a setup prompt you paste into the client. The application password is embedded in that prompt.

Once connected, the agent can build new pages and full layouts with typed widgets and styling that match your design system. It can edit or redesign existing pages by pointing the agent at a URL and describing the change. It can create and manage theme parts including headers, footers, archives, and popups with display conditions. It can read and apply your global design tokens, classes, variables, hover states, and responsive breakpoints.

The cost follows your AI client’s pricing. Elementor basic elements are free under this connection. Pro elements within a generated layout require an active Elementor Pro plan.

The Ecosystem That Ran Ahead

Third-party MCP servers for Elementor have been shipping since mid-2025. EMCP Tools exposes up to 278 tools covering Elementor page building, plugins, users, media, and the database. Premium Addons for Elementor introduced 34 AI Abilities with support for 15 AI clients, including GitHub Copilot, Gemini CLI, Amazon Q, and Windsurf. Each ability is toggle-controlled at the individual level, so admins choose exactly what the connected AI can see and do.

The ecosystem moved quickly. What changes with Elementor 4.3 is that MCP support is now official. It ships with the plugin. It integrates into the Abilities API correctly. It is maintained by the team that owns Elementor’s core behavior. That distinction matters for agencies and developers who need a stable surface to build on.

What to Get Right Before Enabling This on Client Sites

The AI agent does not publish without your approval. The architecture requires you to review changes before they go live. Review only works if someone on your team is accountable for it.

Start on staging, not production. The first run on any site should be on a staging environment. Confirm the agent reads your design system correctly before it touches a live page.

Treat the connection as a deployment decision. Document which AI client is connected, what credentials are in use, and who has admin access to disconnect it. Agencies enabling this on client sites should own that documentation, not assume the client does.

Limit exposed Abilities. Elementor’s native implementation offers per-site connection control. Third-party implementations like Premium Addons let you toggle individual abilities off entirely. If you only need layout changes, do not expose database write access.

Run MCPSafetyScanner before connecting to any live site. Prompt injection and tool poisoning are real attack surfaces on MCP connections. Audit before you open the door.

What WordPress 7.2 Adds to This Picture

WordPress 7.2 Beta 1 is scheduled for October 20, 2026. The Abilities API that makes all of this work is expected to expand in 7.2, with native AI feature depth increasing through the tools registered against it. Elementor’s timing is intentional.

The WordPress MCP Adapter carries 1,692 stars on GitHub as of September 2026 and is actively maintained. It is the canonical bridge between the Abilities API and any MCP client, not just Elementor.

For developers: wp_register_ability() is the registration hook. Any plugin that properly registers against the Abilities API is automatically discoverable by a connected AI agent. That means a growing catalog of WordPress plugins are becoming AI-operable by default, not by special integration.

FAQ

Does Elementor MCP require Elementor Pro? The MCP connection itself is free. Basic sections and elements generate under the free plan. Pro elements within a generated layout require an active Elementor Pro subscription.

Does the AI auto-publish anything? No. Nothing publishes until the connected admin explicitly approves it. Changes are staged for review before going live.

My team uses a different AI client. Does it work? Elementor provides an “Other” configuration path for any MCP-compatible tool. The underlying protocol is standardized, so any compliant client can connect.

Is this production-safe? It is a beta release. Treat it accordingly: staging environments first, documented process, clear rollback plan. Do not enable on live client sites without testing the agent against your specific design system first.

Research assistance provided by Authority Plus

GiveWP CVE-2026-82222: The CVSS 10.0 Deserialization Chain That Makes Every Published Donation Form an Unauthenticated RCE Path

A Perfect Ten. That Is Not a Good Thing.

On August 28, 2026, Patchstack published CVE-2026-82222 against GiveWP — the fundraising and donation plugin with more than 100,000 active WordPress installations. The CVSS score is 10.0. That is the ceiling. No rounding, no reclassification pending. Maximum severity, network-accessible, no authentication required, no user interaction needed.

This is the first confirmed CVSS 10.0 WordPress plugin vulnerability of 2026, and it arrived on the same week that Everest Forms dropped its own CVSS 9.8 file-upload flaw affecting a separate 100,000 sites. The timing is coincidental. The underlying pattern is not.

What the Flaw Actually Does

Three separate weaknesses chain into one complete attack. None of them is exploitable in isolation the way a typical SQLi or auth bypass works. Together they hand an attacker arbitrary OS command execution on the server.

The first link is a broken safeUnserialize() helper inside GiveWP. The function was written to prevent unsafe deserialization of user-controlled data. It does not. Attacker-controlled serialized objects pass through it without meaningful filtering and get written into the site’s database during the donation processing flow. That is the storage step.

The second link is the donation processing flow itself. GiveWP’s payment gateway pipeline accepts and stores the serialized payload that safeUnserialize() failed to block. At this point the attacker’s object is sitting inside the database, waiting.

The third link is a gadget chain shipped inside GiveWP’s own bundled libraries. Gadget chains are sequences of existing class methods that, when triggered during deserialization, execute in a path the developer never intended — in this case, running arbitrary operating system commands. The gadget chain is not attacker code. It is GiveWP’s own code being redirected.

Versions 4.16.5.1 and earlier have a default attack path: one published donation form, one active payment gateway, and the site is fully exploitable with no credentials. GiveWP narrowed that path in versions 4.16.6 through 4.16.7.1, but the underlying deserialization flaw remained open. Version 4.16.7.2 breaks the chain at two independent points — blocking serialized data during donation processing and restricting object creation in the gadget chain path.

The Registration Bypass That Completes the Picture

Patchstack flagged a separate but related problem. GiveWP exposes an unauthenticated registration action at give_action=user_register. That action never consults WordPress’s users_can_register option. A site with public registration disabled can still have an account created through this endpoint. On sites where the vulnerability requires an existing account, this bypass restores the fully unauthenticated attack surface.

That combination — broken deserialization, a gadget chain producing OS command execution, and a registration endpoint that ignores your site’s own settings — is why this got a 10.0 and not a 9.8.

What Is at Risk on a Donation Site

GiveWP is not a generic contact form plugin. Sites running it are typically processing charitable donations, collecting donor personal data, and in many configurations storing or transmitting payment information via active payment gateways. The required condition for exploitation — “one published donation form and one active payment gateway” — describes a live fundraising site in normal operating state, not an edge-case configuration.

Successful exploitation gives an attacker a server shell. From there: database credential theft, donor record exfiltration, payment data access depending on the gateway integration, or use of the compromised server as infrastructure for further attacks. GiveWP has been targeted before. Attackers previously exploited a GiveWP vulnerability to breach the Pi-hole project indirectly, exposing the names and email addresses of 30,000 donors.

The Week’s Broader Context

CVE-2026-82222 was not the only critical form-related WordPress vulnerability disclosed this week. Everest Forms (CVE-2026-19598, CVSS 9.8) dropped August 26 with an identical class of flaw — insufficient file-type validation in the EVF_Form_Fields_Upload class, unauthenticated file upload, full RCE via PHP web shell. That vulnerability affects Everest Forms versions before 3.0.9.5 and hits more than 100,000 sites. Patch is version 3.0.9.5 or later.

Two CVSS 9.8-or-higher file-upload or deserialization RCE vulnerabilities in separate form plugins published within 48 hours of each other is not a coordinated attack campaign. It reflects the pace at which WordPress plugin security research is now running — and the speed with which researchers and threat actors both scan that research once it publishes.

What to Do Right Now

For GiveWP: update to version 4.16.7.2 immediately. If an immediate update is not possible, disable the plugin until the update can be applied. Check wp-content/uploads/ and any directories accessible via your web server for unexpected PHP files. Review administrator account lists for accounts you did not create — the give_action=user_register bypass can create accounts silently.

For Everest Forms: update to 3.0.9.5 or later. Inspect wp-content/uploads/ for recently created PHP files. Log review should focus on POST requests hitting form upload endpoints from unexpected IPs.

Rotate credentials — WordPress admin password, database password, hosting panel — if you have any reason to believe a vulnerable version was running on a site with active donation forms or public-facing Everest Forms file-upload fields. The Patchstack State of WordPress Security in 2026 whitepaper documented that the weighted median time to first exploit for heavily targeted vulnerabilities is five hours from disclosure. Both of these dropped August 26–28.

Confidence and Evidence Notes

All technical details on CVE-2026-82222 source from Patchstack disclosure data, BleepingComputer, and The Repository’s coverage of the GiveWP patch notes. The CVSS 10.0 score is confirmed across multiple independent trackers. The claim that versions 4.16.6 through 4.16.7.1 narrowed but did not close the attack path comes from The Repository’s patch analysis. The Pi-hole breach reference is confirmed by BleepingComputer’s prior reporting. No exploit code has been published as of August 28, 2026.

Confidence: High.