WooCommerce’s Apple Login Has Been Broken Since August 1 — Three Plugin Patches Hit the Payment Path This Month

The E-Commerce Blind Spot in Last Week’s WordPress Security Coverage

While the community was focused on 7.0.3, 7.0.4, and the BdThemes supply chain incident, three separate WooCommerce plugin patches landed quietly in the first week of August. All three touch what security teams call the “money path” — authentication, subscriptions, and payment processing. None of them required a plugin update to exploit when the attack window opened.

The most urgent is CVE-2026-8457. It has been sitting in every WooCommerce Social Login installation through version 2.8.7 since before August 1, when Wordfence researcher Rafie Muhammad of Awesome Motive disclosed it publicly.

What CVE-2026-8457 Actually Does

WooCommerce Social Login offers one-click login through Facebook, Google, Amazon, PayPal, and Apple. The Apple login handler is where the flaw lives. When a user authenticates via Apple, Apple issues a signed identity token — an id_token — that the plugin is supposed to validate against Apple’s public keys before trusting anything in it.

The plugin does not do that. It decodes the base64 payload of the id_token, accepts whatever email address is inside it, and issues an authenticated WordPress session for whatever user account holds that email. No signature verification. No issuer, audience, or expiry claim validation. The login nonce required to invoke the Apple flow is already sitting in a localized JavaScript object on the login page, visible to anyone who loads it unauthenticated.

Combine those two failures and the attack is trivial: grab the public nonce, craft a token payload containing an admin email address, submit it. The plugin issues an admin session. No credentials. No interaction from the victim. A CVSS score of 9.8 (CWE-289, Authentication Bypass by Alternate Name) reflects that accurately.

Administrator accounts are not excluded from this path. On a WooCommerce store, admin access means order data, customer PII, stored payment configurations, and full plugin control — everything that sits behind a dashboard login.

The patch is version 2.8.8. It exists. The only question is whether your installations are on it.

The Pattern Behind the Timing

This is not an isolated disclosure. On August 5, Automattic’s internal security review produced an advisory for WooCommerce Subscriptions — every version prior to 9.1.0. The advisory used language that is unusually direct for a vendor release: “an unauthorized user could assume site control.” That is not a data exposure edge case. That is a path to admin on subscription-powered stores.

Less than twenty-four hours later on August 6, a second WooCommerce advisory covered Stripe for WooCommerce. Also found through Automattic’s internal review, also patched immediately. Both are now at fixed versions.

Three WooCommerce advisories in six days. All found and patched before confirmed external exploitation. That is a working security pipeline doing its job. It also means agencies managing WooCommerce client sites had a narrow window to apply updates before the details were public — and some of those sites almost certainly missed it.

What to Check Right Now

For the Social Login plugin specifically, version confirmation is not enough if the plugin ran below 2.8.8 after August 1. Check your server access logs for POST requests to the Apple login AJAX handler during that window. Look for admin sessions that do not correspond to recognized browser fingerprints or IP ranges. If a rogue administrator account exists that you cannot attribute, treat the installation as compromised, not merely patched.

For WooCommerce Subscriptions, the 9.1.0 update is the fix. Run wp plugin get woocommerce-subscriptions --field=version on each site. Any response below 9.1.0 needs immediate action.

For Stripe for WooCommerce, the WooCommerce Developer Blog advisory from August 6 is the reference. Run a quick post-update smoke test: live card, saved card, 3-D Secure prompt, one refund. That ten-minute sequence catches every regression on the payment path.

Agencies managing multiple WooCommerce client sites should have a documented patching timeline. Not because regulators are watching — because a WooCommerce store that processes card payments and sits on a vulnerable Social Login installation is a PCI compliance problem, not just a security one. The authentication bypass at CVSS 9.8 with zero user interaction required is exactly the class of flaw that card brand forensic investigators ask about after an incident.

The Broader Signal

Automated bots began probing WordPress sites for CVE-2026-8457 within hours of public disclosure on August 1. That is not an estimate — that is the documented pattern for every CVSS 9.x WordPress plugin vulnerability disclosed in 2026, with the exploitation window now measured in hours rather than days. WordPress reported more than 250 weekly plugin vulnerability disclosures through 2026, and 43% are exploitable without authentication.

The WooCommerce ecosystem specifically carries multiplied risk. A vulnerable plugin on a single-store installation is a contained problem. The same plugin deployed across forty client sites managed by one agency is a fleet-wide exposure the moment the CVE goes public. Inventory first, then patch. Do not start from a vulnerability feed and work backward to “do I have this plugin” — that logic is already too slow for 2026’s disclosure-to-exploit timeline.

WordPress 7.1 Ships in 48 Hours: What wp_knowledge and AI Guidelines Actually Do

The Update Everyone Is Watching for the Wrong Reason

WordPress 7.1 releases in 48 hours — August 19, the closing day of WordCamp US right here in Phoenix. Virtually every roundup you’ll find this week is focused on the enforced iframed editor, the new Tabs and Playlist blocks, and responsive styling without CSS. Those are real and those ship. But the more durable technical change in this release barely makes the headlines: wp_knowledge, a new custom post type that becomes WordPress’s first native storage layer for editorial standards, brand voice, and AI memory.

If you maintain multi-author sites, run an agency with content guidelines stashed in a shared Google Doc, or are building anything that touches the AI Client added in WordPress 7.0, this one is worth understanding before you update.

What wp_knowledge Actually Is

The confusion most teams will hit right away: this is not a user-facing AI feature. No chatbot. No content generator. No model baked in.

wp_knowledge is a storage primitive. Think of it the way wp_template, wp_block, and nav_menu_item work — low-level content types that prevent fragmented parallel implementations across the plugin ecosystem. Right now, every plugin that needs to store AI context or editorial standards ships its own post type, its own permissions model, and its own REST surface. That is the fragmentation wp_knowledge is designed to close.

The merge proposal from core committer Greg Ziółkowski, published on Make/Core in June and confirmed for the 7.1 release, defines a non-public, headless, REST-only custom post type with a type taxonomy (wp_knowledge_type) and three built-in slugs:

  • guideline — pure text, the authoritative source of truth for brand standards, tone of voice, and image direction
  • memory — durable context explicitly saved or approved for future AI sessions
  • note — private freeform working text, not surfaced to AI tools by default

The REST collection endpoint lives at /wp/v2/knowledge. Any plugin, WP-CLI script, or AI integration that knows to ask for it gets the same structured data without any custom implementation. Autosave is intentionally disabled because wp_knowledge is headless storage rather than a live editor session, but revision history is retained. Administrators manage site-wide entries. Contributors and authors only manage their own rows. Subscribers see nothing. The wp_maybe_grant_knowledge_caps filter makes the permission model extensible for teams with more granular access requirements.

One historical parallel worth noting from the Make/Core proposal: this is the same pattern WordPress used with the Abilities API and the AI Client in the 7.0 cycle — prototype in the plugin, harden through community feedback, then merge the storage layer into core. The names (wp_knowledge, wp_knowledge_type, the three type slugs, the capability namespace) freeze at 7.1 Beta 1 and become long-term compatibility commitments. That is the right moment to have argued about naming. That window is now closed.

Guidelines: What It Looks Like in the Editor

Guidelines is the first feature built on top of wp_knowledge. Site admins define editorial rules, brand voice requirements, and content standards in one place. Those guidelines then appear directly in the block editor as an editorial checklist for writers. The same data, over the same REST endpoint, is accessible to any AI tool configured to reference it.

Practical upside for agencies and multi-site operators: guidelines can be exported and imported between sites. If you manage a network of client properties that all need to follow similar editorial standards, that consistency now has a canonical home in WordPress rather than living in a PDF that nobody opens. WordPress.com engineer Artur Piszek built a Telegram agent for WordCamp Europe 2026 that ran entirely on Guidelines — every behavior including personality, schedule lookups, and user memory stored as a published guideline rather than custom application code. Desktop Mode, WordPress Workspace, and several other Automattic products already use the storage mechanism.

One thing confirmed in the RC3 build: the Guidelines feature ships with no connection to any specific AI provider. WordPress 7.1 includes no AI model and no pre-configured provider. AI-assisted drafting that follows your guidelines requires a connected provider through Settings > Connectors, identical to the 7.0 setup.

The AI Client Gets Streaming and Embeddings

Separate from wp_knowledge, WordPress 7.1 also updates the AI Client with two new primitives: generation streaming and embeddings support.

Streaming lets AI responses return text in real time rather than waiting for the full generation to complete. The Make WordPress AI team is explicit in the roadmap post that streaming in 7.1 is introduced at the PHP AI Client layer first. It requires server configurations that support long requests, which are not standard across hosting environments. The 7.1 implementation is the foundation. Hosts and plugin developers build production support on top of it in subsequent releases.

Embeddings are the bigger long-term play. An embedding is a numerical vector representation of content that captures meaning rather than keywords. The Make WordPress AI team’s own example is precise: a user searching “how do I reset my password?” can now surface a page titled “Account recovery steps” even though the two strings share zero words. Recent versions of MySQL and MariaDB added native vector storage support, and the 7.1 AI Client embeddings implementation is built to use it. For content-heavy WordPress sites with large archives, this is the first concrete signal that native semantic search is on the platform roadmap. The vector search experiment continues inside the AI plugin, but client-level embeddings support merging into core is the required infrastructure step.

What This Means for SEO and AI Optimization

The Guidelines system has a search visibility angle that most teams have not processed. Google’s current E-E-A-T evaluation places significant weight on publisher trustworthiness and consistency of content standards. When AI tools assist with drafting, inconsistent brand voice and factual drift are real risks to those trust signals over time. wp_knowledge gives you a single source of truth that both human editors and AI tools draw from during content creation.

The secondary dimension is GEO — generative engine optimization. AI crawlers that index WordPress sites increasingly surface structured, authoritative summaries as direct answers in AI Mode and AI Overviews. A site whose content is governed by explicit, structured editorial guidelines stored in a format that AI tools can retrieve is producing a more coherent, consistent signal profile than one where brand guidance lives in a Slack channel. Whether that translates to measurable citation improvement in AI search surfaces is not yet proven at scale, but the architectural alignment with how AI indexing systems work is sound.

What to Do Before and After Updating

The block compatibility testing guidance from earlier this month still stands. Test on a staging copy before pushing to production, especially if you’re running blocks built on Block API version 2 or earlier. The enforced iframed editor is the most common source of visual regressions in pre-production testing.

Specific to the AI features in 7.1:

After updating, check Settings > Connectors to confirm your AI provider connection survived the upgrade. If you’re on a managed host, confirm whether PHP streaming support is in scope for your plan — the streaming implementation requires server-level long-request support that shared hosting environments often cap. Embeddings require both a provider that supports embedding generation and, depending on your database configuration, vector storage support at the MySQL or MariaDB layer.

The Guidelines admin UI ships via the Gutenberg-side work in the block editor. Navigate to your site editor after updating to verify it appears and that your user roles have the expected access levels. If you are building a plugin that stores any kind of AI context or editorial data, the core team’s guidance is unambiguous: build on wp_knowledge rather than shipping your own post type. The names, capability namespace, and REST surface freeze at the 7.1 branch and become long-term compatibility commitments that will be maintained.

Frequently Asked Questions

Does wp_knowledge require an AI provider to be useful?

No. The storage layer works independently of any AI connection. Human editors see guidelines as an editorial checklist in the block editor without any provider configured. The AI-assisted drafting that references those guidelines does require a connected provider through Settings > Connectors.

Will my existing editorial guidelines in Google Docs migrate automatically?

No automated migration exists. You will need to create guideline entries manually in the new WordPress interface, or build a WP-CLI script that reads your existing documentation and writes to the /wp/v2/knowledge endpoint. The export/import feature lets you move guidelines between WordPress sites once they are in the system.

Is embeddings support ready for production use in 7.1?

Not yet at the host level. The Make WordPress AI team added embeddings support to the PHP AI Client as an initial release to let developers and hosts begin building support. Full production use requires vector storage at the database layer and a provider that generates embeddings. The vector search experiment in the AI plugin is the closest working implementation available today.

Does the wp_knowledge data get indexed publicly by search engines?

No. The post type is non-public and headless. It generates no frontend output and no public queries. Search engines cannot crawl it directly.

Google’s 2026 Core Web Vitals Update Tightened INP Measurement — and 44% of Sites Are Still Failing the Combined Test

Google Rewired How INP Is Measured — Your Individual Metric Numbers Don’t Tell the Full Story

The thresholds didn’t move. LCP is still 2.5 seconds, INP is still 200ms, CLS is still 0.1. What changed is the measurement plumbing underneath INP, and it matters because borderline sites are now crossing the fail line without touching a single line of code.

Google’s 2026 update tightened how INP samples latency on input-heavy pages. The old behavior let a cluster of fast interactions buffer a handful of slow ones. The revised methodology weights sustained latency more heavily, meaning an e-commerce filter that stutters at 320ms no longer gets masked by 40 fast scroll taps earlier in the same session. For WordPress builds carrying page-builder JavaScript, this is the practical consequence: interactions that were previously smoothed into a passing score now surface as individual failures in field data.

As of the May 2026 CrUX release — published June 9 — only 55.9% of tracked origins pass all three Core Web Vitals simultaneously. Break that down: 68.6% pass LCP individually, 81.3% pass CLS, 86.6% pass INP. The gap between those strong individual numbers and the combined 55.9% is the real lesson. Most sites fail because one metric drags down two solid ones.

TTFB Is Now a Named Diagnostic in PageSpeed Insights

TTFB didn’t become a Core Web Vital. But Google elevated it to a named diagnostic inside PageSpeed Insights in this same cycle, and that changes what your client reports look like. If you’re running managed hosting with a warm cache, your TTFB will be under 200ms and the diagnostic stays green. If you’re on shared hosting or a misconfigured PHP-FPM pool with too few workers, you’ll now see TTFB flagged explicitly — a number that used to sit buried in a Lighthouse waterfall gets its own callout.

WordPress has a structural TTFB problem. Only about 65% of WordPress sites pass even the generous 800ms threshold per CrUX field data. That’s not a code problem — it’s an infrastructure one. No amount of WP Rocket configuration rescues a response that takes 1.2 seconds before the browser sees the first byte. The fix lives at the server level: a caching layer that serves static HTML without hitting the PHP-FPM workers, ideally with edge caching through a CDN so cached content doesn’t travel from a Phoenix data center to a visitor in Atlanta.

A useful quick check: run curl -I https://yourdomain.com and look for the X-Cache: HIT or CF-Cache-Status: HIT header. If you’re getting misses on repeated cold requests, your cache isn’t warming properly regardless of what the plugin dashboard says.

Where WordPress Builds Bleed INP

Page builders deserve direct scrutiny here. Elementor alone ships over 21 MB of unzipped code into a standard WordPress installation. Every widget, animation conditional, and style option that loads globally adds JavaScript to the main thread. The 2026 INP measurement change means that if a visitor opens a mega-menu, clicks a filter, and then hits an AJAX-powered cart button in the same session, all three interactions are weighed — and the worst one defines the INP score. Under the old averaging, those bad interactions had cover. They don’t anymore.

The sites that feel this update first: WooCommerce builds with client-side filters, comment-heavy editorial sites, dashboards, anything with a persistent sticky header that hooks into scroll events, and WordPress installs stacking page-builder JavaScript from multiple plugins. If your theme loads frontend.min.js, a slider library, a form widget, a chat script, and a cookie bar in sequence before the first interaction is possible, each of those is competing for the main thread.

The diagnostic path is specific. Open Chrome DevTools, start a Performance recording, click the exact element flagged in your Search Console field data, then stop the trace and look at the INP attribution breakdown. The processing time segment is where most WordPress sites lose — it’s almost always a long task from a builder script blocking the main thread after the click. Conditional asset loading via Asset CleanUp or Perfmatters, scoped to the page templates that actually use a given widget, is the first lever. Removing a page builder is a longer project, but the cleanest fix on high-traffic landing pages where the conversion math justifies it.

The Diagnostic Workflow That Actually Reflects Field Reality

Lab tools lie. PageSpeed Insights will score your site on a cold Lighthouse run that has nothing to do with your CDN-cached, Redis-warmed production state. A 99 in Lighthouse and “Poor” in Search Console can coexist on the same URL without contradiction.

Start at Search Console → Experience → Core Web Vitals. This report reflects 28-day rolling CrUX field data, segmented by mobile and desktop, grouped by URL pattern. Find the failing URL group with the most impressions — that’s where to spend the optimization effort. Then run that specific URL through pagespeed.web.dev to see both field and lab views side by side. The Chrome Web Vitals Extension lets you walk through real interactions on your staging site and watch INP update live as you click through a user flow — useful for identifying which exact component is burning time.

Field data updates gradually over that 28-day rolling window. A caching fix deployed Monday won’t read green in Search Console by Thursday. Make the change, wait a full reporting cycle, then compare like for like. Chasing a perfect lab score while ignoring real-user trends is how teams spend two weeks optimizing something visitors never actually felt.

The Fix Sequence for WordPress Sites

TTFB first. If your server response sits above 600ms consistently, fix infrastructure before touching image formats or JavaScript deferral. Verify your caching layer is warming by checking response headers. Confirm your PHP-FPM pool’s pm.max_children isn’t capping at 5 workers under traffic load — at that ceiling, requests queue behind one another and TTFB inflates for every concurrent visitor beyond worker count. Evaluate whether your host actually ships a server-level caching layer or whether you’re relying entirely on a plugin against shared infrastructure.

LCP second. Identify the LCP element on your high-traffic pages — it’s almost always a hero image or a large block background. Add fetchpriority="high" to the <img> tag if your theme doesn’t set it. Serve WebP or AVIF from your CDN origin. Confirm width and height attributes exist on all above-the-fold images so the browser doesn’t reflow the layout as they load. A 150ms TTFB reduction from a properly warmed cache alone can shift a borderline 2.6-second LCP into the green.

INP last, and only after LCP is clean. Profile specific interactions using the DevTools Performance panel. Defer what isn’t needed on initial load. For plugin-heavy WordPress builds, open Query Monitor → Assets → Scripts filtered to frontend output, sort by size, and identify what’s loading on every page regardless of whether it’s used. Every plugin that hooks a global click listener or registers a jQuery document-ready callback is competing for the same thread that needs to be free when a user taps a button.

What the 55.9% Combined Pass Rate Actually Means for Competitive Search

If more than 44% of the web is failing at least one Core Web Vital in real-user field data, passing all three puts your pages in the top half on a signal Google explicitly uses as a tiebreaker on competitive queries. That doesn’t mean CWV alone moves rankings — content relevance and authority still dominate. But in a category where two pages have comparable content and link profiles, the one that passes field-data CWV consistently gets the edge. The sites getting quietly outranked right now aren’t usually losing on content. They’re losing on the infrastructure and JavaScript decisions that were made two years ago and never revisited.

WordPress Shipped Two Core Security Patches in Eight Days: XSS2Shell, an Author-Level RCE, and What to Verify Before 7.1 Drops

Two Consecutive Core Patches, One Critical Window

WordPress shipped two security releases in eight days. Version 7.0.3 landed on August 6 with twelve vulnerability fixes. Version 7.0.4 followed on August 12, addressing a remote code execution vulnerability affecting every WordPress installation running version 4.7 or above. WordPress 7.1 ships August 19 at WordCamp US in Phoenix. Both patches need to be confirmed before that release arrives.

XSS2Shell: The Login Screen Flaw That Needs No Credentials

The headline fix in 7.0.3 is CVE-2026-64638, scored CVSS 8.9. Discovered and responsibly disclosed by the team at pwn.ai, the vulnerability lives in wp-login.php and exploits a parser disagreement between two sanitization functions: wp_strip_all_tags() and PHP’s native strip_tags(). A tag-like construct containing whitespace immediately after the opening angle bracket survives as text rather than being stripped, letting a crafted username inject JavaScript into the failed-login error page.

No authentication required. No existing session needed. An attacker sends a target a crafted URL, JavaScript executes in the browser under the site’s own origin, and credential harvesting begins on a legitimate hostname.

The escalation path goes further. For targets already logged in as Administrator, the XSS is weaponized through WordPress’s Application Password system. An attacker-controlled link triggers the native Application Password approval control inside an active admin session, creates an API credential, redirects it to an attacker-selected success_url, then uses the REST API to upload a plugin archive. The extracted PHP is requested directly. Full code execution on the server.

A nonce-based Content Security Policy using strict-dynamic does not block this path. The University of Toronto’s Information Security advisory is explicit: the technique “clobbers DOM properties consumed by already-trusted scripts rather than introducing new script sources.” CSP is not a compensating control here, and neither is WAF coverage alone.

What 7.0.3 Fixed Beyond the Headline

Twelve vulnerabilities total. Alongside CVE-2026-64638, the release addressed:

  • Contributor+ stored XSS in the Post Content block
  • Contributor+ stored XSS in Quick Edit on large-user sites
  • Contributor+ stored XSS in the Post Date block
  • Privilege escalation on Multisite networks with user registration enabled — registered users could create sites they have no business creating
  • Author+ CSS injection bypassing the safe CSS attribute filter (credited to Anthropic)
  • An email address confirmation bypass
  • A server-side request forgery bug in URL validation

The SSRF is worth calling out on its own. Patchstack describes it as “the first step in an attacker going from ‘just your WordPress site’ to digging around in your internal network.” For sites running on shared or cloud infrastructure with access to link-local metadata endpoints — common in AWS and GCP environments — SSRF is a lateral movement primitive, not just a site-level risk.

7.0.4: An Author-Level RCE That Arrived Six Days Later

Before teams had finished verifying 7.0.3 deployments, WordPress released 7.0.4 on August 12. CVE-2026-65640 is a remote code execution vulnerability exploitable by any user logged in at Author level or above, spanning every WordPress version from 4.7 through current 7.0.3. Managed hosting providers pushed patches immediately across shared and standalone installs. Self-managed installs on cloud infrastructure require manual action.

If your site grants Author access to contributors, guest writers, or freelance editors — and especially if those accounts share credentials or skip two-factor authentication — this is a live code execution path right now.

AI Is Finding These Faster Than Teams Can Patch Them

The pace deserves direct acknowledgment. The wp2shell chain patched in 7.0.2 was found by Searchlight Cyber running OpenAI’s GPT-5.6 Sol model against WordPress Core in ten hours for roughly $25. The XSS2Shell chain followed from pwn.ai’s autonomous pentesting system. The Author+ CSS injection in 7.0.3 is credited to Anthropic.

WordPress’s HackerOne intake hit 450 reports in July 2026 alone. Historically the monthly count sat in the dozens. The pipeline from patch publication to weaponized exploit has compressed. Once a high-impact diff is public, the patch itself reconstructs the vulnerability. Attackers using the same AI tooling that found these bugs can reproduce them faster than most teams can confirm auto-updates ran.

What to Verify on Your Site Right Now

Check your WordPress version directly at Dashboard > Updates or via wp core version --allow-root in WP-CLI. Do not trust what your hosting control panel reports without a direct verification.

For 7.0.4 specifically: audit every account holding Author, Editor, or Administrator roles. Remove unused accounts. For 7.0.3’s XSS2Shell chain, disable Application Passwords under Settings > General if your site has no active REST API integrations — this removes the demonstrated escalation path at no operational cost.

On deployments where plugin management is handled through CI/CD pipelines rather than the WordPress admin, define DISALLOW_FILE_MODS true in wp-config.php. This blocks the plugin-upload stage of the XSS2Shell chain and is sound hardening independent of this specific vulnerability.

The Multisite privilege escalation in 7.0.3 only affects networks with user registration enabled. Check Network Admin > Settings > Allow new registrations if you run a multisite install and have not already confirmed the patch is live.

BdThemes Plugins Pulled from WordPress.org: The Poisoned API Attack That Left No File Fingerprints

The Attack That Left No File Fingerprints

Seven BdThemes plugins were quietly pulled from the WordPress.org directory on August 7 and 8, 2026. No code was altered in the repository. That is what makes this one different from every other plugin compromise covered in the last two months.

Wordfence Threat Intelligence was notified on August 7 after discovering attackers had poisoned a remote promotional API feed used by several popular BdThemes plugins. The attack vector was Biggopti, an internal component bundled with all seven plugins to display promotional banners inside the WordPress admin dashboard. Biggopti fetches JSON from a DigitalOcean Spaces bucket controlled by BdThemes. Attackers obtained write access to that bucket and swapped legitimate JSON responses for crafted payloads designed to execute JavaScript inside any logged-in administrator’s browser.

The XSS flaw was introduced by BdThemes itself. Wordfence traced it through SVN history to March 1, 2026, when a script added to Prime Slider version 4.1.9 began concatenating a remotely supplied display_id field directly into an HTML id attribute without escaping it. A neighboring attribute in the same code block is escaped correctly. Wordfence characterizes the discrepancy as an oversight, not intent. A sanitizer added in May left the flawed attribute untouched.

What the Payload Actually Does

The injected script fires on every wp-admin page load for any logged-in administrator. No click required. No unusual navigation, no suspicious email link.

The JavaScript payload, a file named w2.js, contacts a C2 server at ia-cdn[.]com/fz/c with the victim site’s origin to fetch targeting instructions. From there the chain runs without further interaction: the script uses the administrator’s own active session token to create a new administrator account via the WordPress REST API, installs a fake plugin carrying a webshell named emer-run.php, and deploys two persistence modules. The first grants unauthenticated administrative access through a URL parameter. The second hooks database queries to hide the rogue accounts from the WordPress user list and adjusts account counts to match, making forensic identification harder inside a standard admin interface.

A second payload hosted directly on BdThemes’ own infrastructure derived administrator credentials from the victim’s hostname. Responders can compute exactly what credential format to hunt for once the hostname is known.

Scope and Affected Plugins

The seven affected plugins:

  • Element Pack Addons for Elementor — 100,000+ active installs
  • Prime Slider Addons for Elementor
  • Pixel Gallery Addons for Elementor
  • Ultimate Post Kit Addons for Elementor
  • Ultimate Store Kit for WooCommerce, EDD, and Elementor — 6,000+ active installs
  • Live Copy Paste for Elementor — 6,000+ active installs
  • Smart Admin Assistant

BdThemes claims 350,000+ active installations across its portfolio. Wordfence found timestamps in the poisoned records suggesting the campaign may have started as early as June 23, 2026, meaning sites that ran any of these plugins during that window are exposed even though the API endpoints returned clean JSON by August 8. All seven plugins remain closed on WordPress.org pending a full review. BdThemes has not published an official statement.

Connection to the Wider Campaign

Wordfence linked the ia-cdn[.]com C2 infrastructure to the same threat actors behind the Advanced Responsive Video Embedder backdoor (CVE-2026-18072) and the OptinMonster compromise, both of which surfaced in the two months prior. The end goal across all three campaigns is consistent: establish covert administrative persistence and remote code execution across WordPress environments at scale.

The direct upload of malicious JSON and JavaScript into BdThemes’ own storage bucket rather than a third-party CDN points to a serious breach of the vendor’s cloud credentials or internal infrastructure. This is not a CDN hijack. The vendor’s own upstream is what was compromised.

What to Check Right Now

If any of the seven plugins are or were active on a site at any point since late June, the investigation does not start at the plugin folder. File integrity scanning will not flag the initial compromise. The malicious content never lived in reviewed code.

Start here:

  1. Check WordPress admin accounts for usernames with bd_ prefixes or email addresses ending in @wordpress.org.
  2. Inspect wp-content/mu-plugins for unfamiliar files, particularly anything resembling emer-run.php or class-wp-query-* filenames that do not correspond to installed plugins.
  3. Query the database for the options fz_emer_login_tokens and fz_emer_done_v1.
  4. Review all plugin installation events and admin account creations going back to June 23, 2026, not just the August patch window.
  5. Treat any backup from that period as potentially containing rogue accounts or webshell files.

Wordfence Premium, Care, and Response customers received detection signatures and WAF rules on August 7. Free Wordfence users are scheduled to receive those same protections after the platform’s standard 30-day delay. If your site runs a free Wordfence tier and any of these plugins were active, manual investigation is the only available path right now.

This attack changes one operational assumption: a plugin’s safety record on WordPress.org no longer tells you anything about the safety of the remote services that plugin phones home to on every page load.

Arizona’s Green Business Reality in 2026: Three Forces Reshaping How Local Companies Approach Sustainability

Three separate decisions arrived within eight months of each other. A statewide Climate Action Plan is now in live implementation. A 19-year renewable energy mandate was repealed by the Corporation Commission. And a surprise moratorium froze data center tax incentives as of July 1, 2026. For Phoenix-area businesses, these are not distant policy events. Each one carries direct operational and financial implications that are active right now.

The Statewide Climate Action Plan Is No Longer Just a Document

Arizona published its Comprehensive Climate Action Plan (CCAP) on December 1, 2025. The Governor’s Office of Resiliency developed it with Arizona State University and Northern Arizona University, funded by $3 million in EPA Climate Pollution Reduction Grant dollars. The plan sets a net zero statewide GHG emissions target by 2050, identifies 71 measures across seven major emitting sectors — electricity, transportation, buildings, industry, forestry, land use, and waste — and projects that full implementation would reduce emissions by 4.2 billion metric tons from the 2000 baseline.

The 2026 calendar has specific delivery milestones. This year is designated for designing the energy-efficiency-as-a-service program structure, establishing utility and contractor partnerships, and creating energy audit protocols. The CCAP also schedules 2026 as the launch year for enhanced coordination of existing efficiency programs including Efficiency Arizona, the Weatherization Assistance Program (WAP), and LIHEAP. By 2027, the plan calls for creating an Arizona Green Bank with direct financial assistance tools and a revolving loan fund. Businesses planning capital projects tied to energy efficiency or clean technology should note that the financing infrastructure is being assembled now. The 2027 Green Bank target is not speculative — it is a scheduled CCAP milestone.

The Corporation Commission Eliminated Arizona’s Renewable Energy Mandate

On March 4, 2026, the Arizona Corporation Commission voted to repeal the Renewable Energy Standard and Tariff Rules (REST Rules), in effect since 2007. The mandate required APS, TEP, and UniSource Energy Services to source a minimum percentage of retail electricity from renewables, peaking at 15% after 2024. The ACC stated that those three utilities collected more than $2.3 billion in REST surcharges from customers since inception, with above-market legacy solar contracts continuing to burden ratepayers. The Commission pointed to APS’s Solana Generating Station contract at 15 cents per kWh against today’s utility-scale solar average of roughly 2.5 cents per kWh as a concrete illustration of the cost disparity.

The repeal is not yet final. The notice of final rulemaking must clear Attorney General review, and legal challenges from renewable energy stakeholders are expected. Existing renewable contracts stay intact. Utilities retain the ability to procure renewables through All-Source RFP and Integrated Resource Plan processes, which market economics broadly support. But the policy backstop is gone. Businesses that relied on utility-funded distributed generation incentive programs — rooftop solar rebates, for example — should verify with their utility provider whether those programs survive without the REST surcharge funding mechanism that previously paid for them.

Arizona Paused Data Center Tax Incentives Starting July 1, 2026

Arizona’s FY 2026-2027 state budget (HB 4168), signed June 13, 2026, enacted a three-year moratorium on the state’s data center sales tax exemption. The Arizona Commerce Authority cannot accept new applications from July 1, 2026 through June 30, 2029. Governor Hobbs arrived at this as a compromise from her initial request to eliminate the exemption entirely. In the two weeks before the July 1 cutoff, the ACA received 113 new applications — nearly matching the 123 total applications submitted across the program’s entire run from 2013 through June 14.

Arizona is part of a national pivot. Over 300 data center-related bills were filed in 30 states in just the first six weeks of 2026. Arizona joined Illinois and Ohio in enacting moratoriums around the same period. The existing sustainability criteria under A.R.S. Section 41-1519 — energy-efficiency and water-conservation requirements — remain applicable to already-certified facilities. Operators should verify their certification records with the Arizona Commerce Authority and confirm that ongoing sustainability requirements are being met. When the moratorium expires in 2029, new applications will face a revised framework that almost certainly carries tighter sustainability conditions than the program’s original structure.

Local Businesses Have a Practical Pathway: The Green Business Boot Camp

Policy change creates compliance pressure and early-mover opportunity simultaneously. Local First Arizona’s Green Business Boot Camp runs seven-week cohorts for locally-owned businesses and nonprofits statewide, targeting a 20% reduction in energy use, water consumption, waste generation, or transportation emissions. Participants benchmark baseline use through ENERGY STAR Portfolio Manager and build a sustainability project plan with weekly expert instruction and one-on-one support continuing for a full year after graduation.

Two new cohorts open this fall. The statewide virtual Cohort 23 runs September 22 through November 10, 2026, on Tuesdays from 4 to 5 p.m. A Verde Valley in-person cohort begins September 29. Participants can access low-cost, short-term microloans through the Green Community Fund, developed in partnership with the Community Investment Corporation, to finance their sustainability projects directly from what they build in the program.

Three Variables to Track Through the Rest of 2026

The Attorney General’s review of the ACC’s REST repeal is the most active legal variable right now. A successful challenge restores the mandate and its associated utility incentive funding. The 2027 Arizona Green Bank is the most significant near-term financing development for businesses with sustainability capital projects on the planning horizon. And the data center moratorium’s June 2029 end date will produce a revised, sustainability-conditioned incentive framework. Businesses in the planning stage for Arizona data center investments should be building sustainability compliance documentation now, before the new framework is written without their input.

Frequently Asked Questions

Does the ACC’s repeal of the renewable energy mandate mean Arizona utilities will stop buying solar?

No. Existing renewable contracts remain in place, and market economics still favor solar for many new procurement decisions. The repeal removes the compliance mandate and the surcharge-funded incentive programs, not the underlying cost competitiveness that has made utility-scale solar the lowest-cost generation source in most Arizona procurement processes. Utilities continue to file All-Source RFPs that will include renewables based on cost and reliability.

Can existing Arizona data centers still use their sales tax exemptions?

Yes. The moratorium only prohibits new applications. Facilities already certified under A.R.S. Section 41-1519 retain current exemption status. Operators should verify their certification records with the Arizona Commerce Authority and confirm that ongoing energy-efficiency and water-conservation requirements are being met to maintain eligibility.

What is the Arizona CCAP’s relationship to city-level plans like Phoenix’s Climate Action Plan?

The state CCAP is designed to complement, not replace, existing city and county climate plans. Phoenix, Tucson, Tempe, Mesa, Flagstaff, and multiple tribal nations have developed their own plans. The statewide CCAP provides a framework for resource alignment and policy consistency across those jurisdictions, including coordination on water security, clean energy, and transportation infrastructure investments.


Sources:

Two New Google Search Console Features Require a Decision From Every WordPress Site Owner This Month

Two Separate Tools. Both Need a Deliberate Look.

Google pushed two distinct Search Console features this summer that share nothing except the dashboard they live in — and both land directly on WordPress site owners and the agencies managing them. The first is platform properties, a brand-new property type that lets you track how your Instagram, TikTok, X, and YouTube content performs inside Google Search and Discover, verified through a platform login rather than a DNS record. The second is the Generative AI Controls toggle, a Settings-level switch that determines whether your site’s content can appear in AI Overviews, AI Mode, and Discover’s generative AI features. Neither is optional in the sense that ignoring them means operating blind on two surfaces where your site’s visibility now lives.

Platform Properties: Social Content Has Always Had Search Visibility. Now You Can Measure It.

On July 7, 2026, Moshe Samet, Product Manager Lead for Search Console, published the official announcement on the Google Search Central Blog. By July 29, 2026, the feature completed its global rollout to all accounts. The announcement confirmed what was already quietly building: Google increasingly surfaces Instagram Reels, TikTok clips, X posts, and YouTube videos directly in Search results and the Discover feed, but until now that visibility was completely unmeasured from the site owner’s side. Platform properties close that gap.

The setup is simple and does not involve DNS records or HTML file uploads. Open the property selector dropdown in Search Console, click Add property, select one of the four supported platforms — Instagram, TikTok, X, or YouTube — and complete the on-screen account authorization. Each handle or channel is its own separate property, so a brand running both YouTube and Instagram adds two properties. Google’s help documentation notes that ownership is periodically re-checked for security; if a connected token expires, reporting pauses until re-verification. Allow up to 48 hours after linking before the Performance report starts populating.

The reports surface three things: clicks and impressions per post (filterable by search query), an Insights-level summary of traffic trends and top-performing posts, and an Achievements section tracking 28-day milestones. What these reports do not show is in-platform engagement — views, likes, and follower counts still live in TikTok Analytics, Instagram Insights, and YouTube Studio. The new Search Console data answers a narrower but often more commercially useful question: which of your social posts are earning visibility in Google Search, and what queries are triggering those appearances. If a YouTube tutorial is the asset actually ranking for a high-intent query rather than the blog post you spent three hours writing, this is where you find out.

One operational note for agencies: there is no bulk setup path. Each platform property is verified individually, account by account. Google’s announcement does not reference an API for programmatic setup. For teams managing a portfolio of client accounts with active social channels, budget the setup time accordingly before promising clients a live dashboard.

Generative AI Controls: The First Toggle That Separates AI Features From Organic Rankings

The AI Controls feature is a few weeks older but still rolling out across accounts. On June 3, 2026, Google launched a dedicated Generative AI performance report in Search Console alongside a property-level opt-out toggle — initially limited to a subset of UK site owners following a binding conduct requirement from the UK’s Competition and Markets Authority. As of July 2026, the setting has been appearing on U.S. and international accounts, with rollout continuing on a per-property basis. The toggle lives at Settings → Search generative AI inside Search Console.

Three states are available: Include (the default — your content is eligible to appear in AI Overviews, AI Mode, and AI Overviews in Discover), Exclude (your content is blocked from all three surfaces), and Inherit from parent (child properties follow the parent property’s setting). Setting a property to Exclude removes it from AI-generated answer surfaces while leaving standard organic rankings, featured snippets outside of AI features, and the Gemini app completely untouched. Google has confirmed the toggle is not used as a ranking signal for traditional Search — a meaningful assurance given how blunt prior tools were.

This is the first mechanism to surgically isolate generative features from everything else. Robots.txt’s Google-Extended token blocks AI model training but not AI Overviews appearances. The nosnippet directive removes content from AI features but simultaneously strips your organic snippet. The new GSC toggle handles AI surfaces only, with no organic-snippet tradeoff. That separation is what regulators pushed for, and what Google has now shipped.

For most WordPress sites — lead generation pages, service sites, WooCommerce stores, agency portfolios — the default Include setting is the right call. AI Overviews now reach over 2.5 billion monthly users per Google’s own figures, and AI Mode has surpassed one billion monthly users. Being cited in an AI answer builds brand visibility even on sessions that produce no immediate click. The case for Exclude is narrower: subscription publishers or premium-content operators whose revenue model depends directly on clicks and whose content is detailed enough to be fully summarized without a visit may have a real argument. Before touching the toggle either way, open the Generative AI performance report to check your current impressions data — the report has been recording since May 18, 2026, and gives you actual page-level visibility to anchor the decision.

What WordPress Teams Should Do Before the End of the Week

The checklist is short. Open Search Console for every property you manage. Check the property selector for the Add property option and connect any active social or video channels as platform properties — one per handle, one per platform. Then navigate to Settings → Search generative AI on each property and confirm the toggle state is deliberate, not just a default no one has reviewed. Google has indicated page-level controls for the AI toggle are planned for March 2027, which would add URL-level exclusions on top of the current property-wide binary. For now, the site-level decision is what you have — and it is worth making explicitly rather than letting a default run indefinitely.

Frequently Asked Questions

Do I need a website to use platform properties?
No. Platform properties can be verified using only a qualifying Instagram, TikTok, X, or YouTube account. No domain ownership is required.
Does the Generative AI Controls toggle affect my rankings in standard Google Search?
No. Google has explicitly confirmed the setting is not used as a ranking signal for standard organic results. Opting out only removes your site from AI Overviews, AI Mode, and AI Overviews in Discover.
Does the AI Controls toggle also block the Gemini app?
No. The toggle governs Google Search products only. The Gemini app is explicitly excluded from its scope. Google-Extended in robots.txt is the separate mechanism for Gemini model training.
If I don’t see platform properties or the AI Controls toggle in my account yet, is something wrong?
No. Both features are rolling out gradually across accounts. If the options are not yet visible in your property selector or Settings panel, expect them to appear in the coming weeks.

Sources:

WordCamp US 2026 Is 8 Days Away in Phoenix: Record AI Programming, WordPress 7.1 Launch Day, and What the Schedule Means for Your Sites

Eight days from now, the Phoenix Convention Center becomes the largest gathering of WordPress professionals in North America. WordCamp US 2026 runs August 16 through 19 at 100 N 3rd St downtown. For web teams already based here in Phoenix, this is not an event you watch on WordPress.tv after the fact.

It is, quite literally, in your backyard.

A Four-Day Format and What Actually Changed

The Sunday-through-Wednesday structure departs from the traditional weekend WordCamp format. Organizers made that call deliberately. Sunday, August 16 is Contributor Day, a full working session where developers, designers, documentation writers, accessibility contributors, and translators work directly on the WordPress project itself. No prior contribution history required. Monday, August 17 is Showcase Day, focused on how agencies and organizations run WordPress at real scale. Past Showcase Days have featured teams from Wikimedia and CANCOM walking through how they manage high-traffic systems. The main conference runs Tuesday August 18 and Wednesday August 19, 9 a.m. to late afternoon both days, closing Wednesday evening with a keynote, raffle, and the official WCUS Social.

Out-of-state attendees arriving Saturday get two full days in Phoenix before Contributor Day starts. The format functions more like a focused workweek than a weekend conference, which changes how you plan the trip.

AI Owns the Program. By a Wide Margin.

At WCUS 2025 in Portland, AI was one of three tracks. In Phoenix, it became its own dedicated track. At least 18 sessions across the schedule are AI-focused or AI-adjacent, making it the largest AI showing at any flagship WordCamp to date. Event co-lead Megan Marcel, Automattic’s Head of Global Events, described it directly as “our biggest AI programming to date.”

These are not trend panels. The sessions cover guardrails for AI-assisted development, preparing WordPress sites to serve AI agents as visitors rather than humans, the EU AI Act’s implications for client work, machine translation changing editorial workflows, and the legal and privacy questions of deploying AI tools in client environments. Speakers from companies including Elementor are presenting. The stated framing is AI as a tool to handle with care, not a headline to chase. The AI focus has been building across 2026’s flagship WordCamps: WordCamp Asia in Mumbai opened with a keynote from Automattic’s former Head of AI, and WordCamp Europe in Kraków ran multiple AI sessions and workshops. Phoenix is the culmination of that trajectory.

The four tracks across Tuesday and Wednesday: AI, Honing Your Skills, Technical WordPress, and the new WP101 beginner track. WP101 transitions to “WordPress 202” on the final day. Co-leads Megan Marcel and Raquel Manriquez designed that track specifically to bring in newcomers, with a focus on students from nearby Arizona State University.

WordPress 7.1 Ships on August 19. The Last Day of WCUS.

That is not a coincidence. WordPress has a tradition of tying major releases to flagship WordCamp closing days. WordPress 7.1 is confirmed on track for August 19, 2026, the final day of WCUS 2026 in Phoenix. If your client sites are currently in staging testing the enforced iframed editor or the new block additions shipping in 7.1, the release itself will happen while conference sessions are still running. Our earlier breakdown of what to test before the 7.1 update lands covers the specific staging checklist your team needs before that date: WordPress 7.1 Drops August 19: The Forced iframed Editor, New Blocks, and What Your Site Must Test Before Updating.

Made on WordPress: A Marketplace of Actual Operators

New in 2026 is the Made on WordPress marketplace, running inside the Sponsor Hall on August 18 and 19. This is not a vendor booth section selling to the WordPress market. It is a curated area for small businesses and merchants that actually run their operations on WordPress. Organizers describe the intent as capturing the energy of a farmers market, putting attendees face to face with the actual people behind the actual things. Vendors are being sourced through sponsor nominations and direct outreach to local Phoenix businesses.

For Phoenix-based web teams, pay attention to who shows up in that marketplace. These are business owners publicly demonstrating they are invested in the WordPress ecosystem, and they are local.

On the Floor: Happiness Bar and Career Corner

The Happiness Bar runs throughout the conference as a free drop-in help desk staffed by volunteer WordPress experts. Bring a real, stuck problem. The Career Corner inside the Sponsor Hall posts active job listings with company reps present. The Technical WordPress and Honing Your Skills tracks cover modern development workflows, automated testing with tools like WordPress Playground, plugin pipelines, pricing structures, and how agency models are shifting as clients ask for more ongoing value.

Every session gets recorded and published to WordPress.tv after the event.

Practical: Venue, Hotel, Tickets

Phoenix Convention Center, 100 N 3rd St, Phoenix, AZ 85004. The official room block is at the Sheraton Phoenix Downtown, a five-minute walk from the venue, starting at $159 per night. General admission is $100. Student tickets are $25. A Micro-Sponsor ticket at $750 covers the true per-attendee cost and places you on the official WCUS sponsor page. Tickets are at us.wordcamp.org/2026/tickets. Phoenix Sky Harbor Airport (PHX) is less than five miles from the convention center and about 15 minutes on the Valley Metro light rail.

Frequently Asked Questions

When and where is WordCamp US 2026?
August 16 through 19, 2026 at the Phoenix Convention Center, 100 N 3rd St, Phoenix, AZ 85004. Contributor Day is Sunday August 16, Showcase Day is Monday August 17, and the main conference days are Tuesday August 18 and Wednesday August 19.
What tracks are available at WordCamp US 2026?
Four tracks run across the two main conference days: AI, Honing Your Skills, Technical WordPress, and the new WP101 beginner track. WP101 transitions to “WordPress 202” on Wednesday, August 19.
How much do tickets cost for WordCamp US 2026?
General admission is $100. Student tickets are $25. A Micro-Sponsor ticket that covers the full per-attendee cost is $750 and includes a listing on the official WCUS sponsor page.
Is WordPress 7.1 releasing during WordCamp US 2026?
Yes. WordPress 7.1 is scheduled to release on August 19, 2026, the final day of WCUS 2026 in Phoenix. The release will coincide with the conference’s closing day.

Sources:

Google’s Official AI Search Guide Debunks Six Common Tactics: What Actually Earns Your WordPress Site AI Overview Citations

Two Years of AI SEO Hype, Settled in One Google Document

On May 15, 2026, Google published its first official guide to optimizing for generative AI features in Search. The document, titled “Optimizing your website for generative AI features on Google Search,” now lives permanently under a new “Generative AI fundamentals” section of Search Central documentation and was last updated July 10, 2026. Not a blog post. Not a tweet. Official policy documentation — and it changes the calculus on a category of optimization services that has commanded real budgets over the past two years.

The core position is unambiguous. Google’s AI Overviews and AI Mode run on the same core ranking and quality systems as traditional Search. There is no parallel optimization track. Your page either earns organic visibility through standard SEO, or it does not enter the retrieval pool those systems draw from.

How Google’s AI Systems Actually Retrieve Content

Two techniques power content retrieval inside AI Overviews and AI Mode. Retrieval-augmented generation (RAG) pulls relevant, recently indexed pages from the Search index to ground responses in real web content. Query fan-out generates a set of concurrent sub-queries from a single user prompt — if someone asks “how to fix a lawn full of weeds,” the system fans out into queries like “best herbicides for lawns,” “remove weeds without chemicals,” and “how to prevent weeds.” Both mechanisms depend entirely on the Search index. A page that is not indexed, or that ranks poorly, does not get retrieved regardless of what other optimization was applied to it.

Google addresses the terminology debate head-on. The guide defines AEO (answer engine optimization) and GEO (generative engine optimization) and then states: “From Google Search’s perspective, optimizing for generative AI search is optimizing for the search experience, and thus still SEO.” That is a direct quote from permanent documentation, not an interpretation.

Six Tactics Google Explicitly Says to Drop

The mythbusting section names deliverables with “you don’t need to” language that rarely appears in Google’s public writing. Each item below maps to a currently active service category in the AEO/GEO market.

llms.txt files. Google states you do not need to create machine-readable files, AI text files, markup, or Markdown to appear in generative AI search. Google may crawl the file but does not treat it specially. Ahrefs analyzed 137,000 sites in May 2026 and found that 97% of existing llms.txt files received zero traffic from any source — no bots, no humans. Of the 3% that received any traffic at all, AI retrieval bots accounted for just 1.1% of requests. Slackbot fetched more llms.txt files than PerplexityBot did. Google’s Search Advocate John Mueller described it as “a temporary crutch, perhaps to save some tokens” built for AI coding tools parsing developer documentation — not a Search ranking input.

Content chunking. There is no requirement to break articles into small pieces, and no ideal page length. Google’s systems can understand the nuance of multiple topics on a single page and surface the relevant passage directly to the user in an AI response. Over-fragmenting produces skeletal content that loses editorial depth without improving retrieval probability.

AI-specific rewriting. Google’s retrieval systems understand synonyms and general intent. Rewriting pages to sound machine-friendly is not a recognized optimization category inside Google’s AI pipeline. Write for readers.

Special AI schema. No special schema.org markup is required for generative AI visibility. Standard structured data remains valuable for rich results eligibility in traditional Search — but it is not an AI citation lever for Google’s surfaces.

Inauthentic brand mentions. Seeking manufactured references across blogs and forums is called out by name in the mythbusting section. Google’s core ranking systems focus on quality, and its spam systems block manufactured signals. The guide states that seeking inauthentic mentions “isn’t as helpful as it might seem.”

Long-tail variation pages. Creating pages primarily to target every AI sub-query cluster violates Google’s scaled content abuse spam policy. The guide is explicit: you do not need to capture every query variation to earn AI Overview visibility.

What Actually Earns AI Citations on Google

The positive case is simpler and harder to sell as a service. Google’s own framing: “Creating content that people find unique, compelling, and useful will likely influence your website’s presence in generative AI search in the long run more than any of the other suggestions presented in this guide.”

Non-commodity content is the differentiating concept the guide introduces. Google draws a specific contrast between a commodity article (“7 Tips for First-Time Homebuyers”) and content with genuine original insight (“Why We Waived the Inspection and Saved Money”). Generic advice that mirrors hundreds of competing pages does not have a reliable place in an AI answer that is supposed to provide information better than a standard SERP.

Technical prerequisites remain unchanged. Pages must be crawlable and indexed. JavaScript must render correctly — incomplete server-side rendering leaves AI crawlers with a skeleton of the actual page. Duplicate content disqualifies. Page experience signals apply the same way they always have, including Core Web Vitals and mobile rendering. A server returning a 400ms+ TTFB creates an LCP ceiling that no amount of content quality overcomes.

For WordPress teams specifically: verify crawlability and indexing in Search Console’s Core Web Vitals and Coverage reports. Check that your theme renders critical content without requiring JavaScript execution. If you run a heavily plugin-dependent build with multiple scripts blocking the main thread, the INP penalty showing up in your field data is the same signal AI retrieval systems respond to. Run PHP 8.2 or 8.3 — not because Google asks, but because the TTFB improvement from leaving PHP 7.4 is the fastest single-action performance gain available without touching a line of theme code.

The Critical Caveat: This Guidance Covers Google Only

Google’s guide is explicit about its scope. It describes how Google’s AI features work. ChatGPT, Perplexity, Claude, and Bing Copilot each run their own retrieval architectures with their own citation behavior. The “still SEO” position is accurate for Google’s surfaces and only for Google’s surfaces.

The dynamics outside Google are genuinely different. Roughly 85% of AI references across non-Google engines originate from third-party pages rather than brand-owned sites. Perplexity and ChatGPT weight community sources, recency signals, and licensed data in ways that do not map directly to Google’s index-based system. If those platforms are part of your traffic picture, they warrant separate analysis that Google’s guide does not address.

Using Search Console’s Generative AI Performance Report

Google now provides a dedicated Generative AI performance report inside Search Console. It shows impressions and appearing pages for generative AI features. If your impression counts are rising while clicks and CTR fall, you are already seeing the AI Overview effect — content being surfaced and consumed inside the AI response without producing a click-through. That data is now directly available to diagnose and act on, using the same query-level view familiar from the standard performance report. The guide points to this report as the recommended monitoring tool for AI Overview visibility.

FAQ

Does my WordPress site need a llms.txt file to appear in Google AI Overviews?

No. Google’s official AI optimization guide states explicitly that llms.txt files receive no special treatment in Google Search. The file neither helps nor harms AI Overview visibility. You may maintain one for third-party AI tools or developer documentation workflows, but it carries zero weight as a Google Search signal, and independent data from Ahrefs confirms AI bots are not seeking it out.

Is AEO or GEO a separate practice from SEO for Google Search?

Not according to Google’s own documentation. The May 2026 guide states directly that optimizing for generative AI search on Google is optimizing for the search experience — still SEO. For non-Google AI platforms like ChatGPT or Perplexity, retrieval behavior differs enough that separate strategy work is warranted. But for Google’s surfaces, the same foundational SEO that earns organic rankings also earns AI citation eligibility.

What content actually gets cited in Google AI Overviews?

Google’s guide centers on non-commodity content: pages with unique perspective, first-hand experience, original data, or insight that is not replicated across competing pages. Technically, pages must be crawlable, indexed without errors, eligible for snippets, and delivering acceptable Core Web Vitals in field data. Generic how-to content built from common knowledge has lower citation probability than content that provides something no other page provides.


Sources:

WordPress 7.1 Drops August 19: The Forced iframed Editor, New Blocks, and What Your Site Must Test Before Updating

Eleven Days Away and Already Causing Problems

WordPress 7.1 ships August 19, 2026 — the final day of WordCamp US in Phoenix — and for the majority of sites the update will land without drama. For developers running custom blocks, older plugins, or editor-side JavaScript that touches window or document directly, the situation is different. One change in this release has no flag to disable and no opt-out path remaining.

The Forced iframed Post Editor: No More Escape Hatch

Every editor in WordPress except the post editor has been running inside an iframe for years. The site editor, template editor, all block previews — already isolated. WordPress 7.1 completes the transition. The post editor is now always iframed, regardless of theme type, Block API version, or whether the Gutenberg plugin is active.

The Core team merged PR #74042 on July 10, 2026, deleting the old theme and apiVersion conditions from the logic entirely. In WordPress 7.0 an escape hatch still existed: a single block registered at API version 2 in the active post could pull the canvas back out of the iframe on the fly. In 7.1, that escape hatch is gone. Staying on apiVersion: 2 does not opt you out — it just guarantees console warnings and broken editor behavior.

The practical consequence is specific. Any editor-side script calling document.querySelector('.my-plugin-panel') is now executing in the parent frame, not the canvas. The fix is straightforward but requires a full audit: swap document for ref.current.ownerDocument and window for ref.current.ownerDocument.defaultView. Ryan Welcher’s published walk-through on the WordPress Developer Blog demonstrates five concrete failure patterns — viewport detection, click-outside handlers, editor styles, admin body-class CSS, and unmaintained third-party libraries — with broken and fixed versions of each.

WooCommerce’s block-based checkout and cart blocks are already on apiVersion: 3 in recent releases, so core WooCommerce stores are lower risk. The higher-risk group is third-party WooCommerce extensions that add custom meta boxes or ship their own admin scripts: WooCommerce Subscriptions, Bookings, and certain payment gateway plugins. Classic meta boxes registered with add_meta_box() carry a separate consequence in 7.0 and 7.1 — they disable collaboration mode for the entire post type, not just posts where the meta box appears.

What Is Actually New for Site Owners

The breaking change gets the headlines but 7.1 ships real editorial capability too.

Responsive styling without CSS is the headline feature most content teams will notice. Hover, focus, and active interactive states are now configurable from inside the block editor. A button’s hover color, a heading’s font size at mobile breakpoints — these now live in Global Styles and per-block settings where they persist across theme switches. Viewport breakpoints are also theme-configurable, and Gutenberg 23.5 replaced the fixed desktop/tablet/mobile toggle with a freely resizable device preview. The custom CSS workaround a lot of teams have been maintaining for years becomes unnecessary.

Two new Core blocks are confirmed in beta: Playlist (including waveform visualization) and Tabs. Table of Contents was on the roadmap but had not appeared in the confirmed beta feature list as of early August. Real-time collaborative editing — Google Docs-style simultaneous co-authoring — is absent again. It was pulled from WordPress 7.0 twelve days before that release and the 7.1 roadmap is candid: open strategic questions about storage mechanism and feature scope remain unresolved. What did ship for collaboration is the Notes system, which gained @mentions, inline rich-text formatting (bold, italic, code, links), notes anchored to specific text selections rather than whole blocks, and support for multiple parallel conversations on the same block.

Media handling gets a genuine overhaul: HEIC and AVIF format support, a new crop-and-rotate modal, client-side processing that converts HEIC and GIF-to-video before upload, and upload queues that survive a dropped connection. The Media Library also gets infinite scrolling back — it was removed in WordPress 5.8 — now as the default with a per-user opt-out in user preferences.

Developer Surface: Abilities API, AI Primitives, and React 19

The Abilities API introduced in WordPress 7.0 expands with input coercion, custom validation hooks, and a new invocation lifecycle action. More consequentially, three Core read abilities now ship: core/read-settings, core/read-content, and core/read-users. Before these existed, any AI integration built on the MCP Adapter could call a model without being able to answer foundational questions — what posts exist, who are the site’s admins, what URL is the front page. That gap is closed.

The AI Client gains streaming for generation responses and embeddings support for semantic and vector search. MySQL and MariaDB both support native vector storage; the WordPress AI plugin is already running vector search experiments on top of it. Paired with wp_knowledge — a new Core custom post type with three sub-types (guideline for brand standards, memory for durable approved context, note for private working text) and REST routes at /wp/v2/knowledge — this gives AI plugins structured access to site-specific context without each plugin inventing its own storage pattern.

React 19 arrives in Core with this release, moving from React 18. If you maintain custom blocks or admin screens with compiled JSX, enable the gutenberg-react-19 experiment flag in Gutenberg 23.4+ now. TypeScript type changes surface at build time; behavioral differences in concurrent rendering surface at runtime.

One more wave worth catching: roughly 20 @wordpress/components — including BoxControl, BorderControl, FontSizePicker, RangeControl, ComboboxControl, ToggleGroupControl, and CustomSelectControl — hard-deprecate the __next40pxDefaultSize prop. The 40px control size is now the permanent default and the prop becomes a no-op. Plugins passing it continue to function but generate deprecation warnings. Plugins relying on the old smaller default without the prop need a layout review before August 19.

How to Test Before the Release Lands

Three testing routes, none of them production:

  1. Install the WordPress Beta Tester plugin, select the Bleeding edge channel and Beta/RC Only stream, and pull the current RC build from your dashboard.
  2. Run wp core update --version=7.1-RC2 via WP-CLI on a staging instance already cloned from production.
  3. Use WordPress Playground at playground.wordpress.net for a zero-install disposable environment — the fastest route for plugin compatibility checks that do not require persistent data.

The testing priority list: custom blocks at Block API v2 or lower, any editor-side plugin JavaScript, WooCommerce extensions with meta boxes, and custom admin styles that target body classes or use window-scoped event listeners. For most sites running mainstream plugins with active maintenance, confirm the plugin author has published a 7.1-tested release, test on staging, then update production a week or so after the release to let the community surface any undiscovered regressions first.

RC2 is due August 12. Dry run August 18. Release August 19, during WordCamp US. The window to catch and fix compatibility problems before your users encounter them is exactly this week.

FAQ

Will WordPress 7.1 break my existing site?

Most sites running mainstream, actively maintained plugins will update without issues. The highest-risk scenarios involve custom blocks built on Block API v2 or lower, plugins running JavaScript that references document or window inside the editor canvas, and third-party WooCommerce extensions registering classic meta boxes. Test on a staging copy before production.

What exactly breaks with the enforced iframed post editor?

Editor-side JavaScript calling document.querySelector() or referencing the global window object now executes in the parent frame, outside the canvas. Fix: replace document with ref.current.ownerDocument and window with ref.current.ownerDocument.defaultView. There is no opt-out flag and no apiVersion escape hatch remaining in 7.1.

How do I test my site for 7.1 compatibility before August 19?

Install the WordPress Beta Tester plugin and switch to the Bleeding edge channel; run wp core update --version=7.1-RC2 via WP-CLI on a staging clone; or use WordPress Playground for a zero-install test environment. Never test on production.

Is real-time collaboration in WordPress 7.1?

No. It was pulled from WordPress 7.0 before release and is not in 7.1. Open strategic questions around storage mechanism and feature scope remain unresolved per the official roadmap. The Notes system received the collaboration investment this cycle.

What new blocks ship with WordPress 7.1?

Two new blocks are confirmed in beta: Playlist (with waveform visualization) and Tabs. Table of Contents was on the original roadmap but had not appeared in the confirmed beta feature list as of early August 2026.


Sources: