Category: Web Development

Elementor Pro CVE-2026-32475: The CVSS 9.0 File Upload Flaw That Gives Unauthenticated Attackers Code Execution on Any Site Running a Form

Posted on by di_admin

The Flaw Dropped on the Same Day as WordPress 7.1

August 19 was a busy day. WordPress 7.1 launched at WordCamp US in Phoenix. Elementor Pro shipped version 4.2.2. Those two things are connected in a way most coverage missed: the 4.2.2 release was not a feature update. It was the patch closing CVE-2026-32475, a CVSS 9.0 critical vulnerability that lets an unauthenticated visitor upload a PHP file through an ordinary contact form and execute arbitrary code on the server.

Patchstack published the advisory on August 19. Security researcher Tin Pham — known as TF1T — reported it on July 16 through the Patchstack Bug Bounty Program. The Elementor team had a fix prepared by July 17, Patchstack verified it on August 3, and the patch shipped five weeks after initial disclosure.

That gap matters. The window between Patchstack verifying a fix and the vendor releasing it publicly is exactly when targeted reconnaissance tends to happen.

Where the Bug Lives

The vulnerability is in modules/forms/fields/upload.php, inside the Forms module’s File Upload field. Two separate loops handle the same file submission — the validation loop and the processing loop — and they disagree about what to do with an empty file entry.

When PHP receives a multipart upload where the filename is blank, it reports UPLOAD_ERR_NO_FILE. The validation loop’s early-exit logic treats that empty entry one way. The processing loop treats it differently. An attacker crafts a two-part upload: the first part has an empty filename, the second is a malicious PHP payload. The validator sees the first part as a non-event and exits early. The processor sees the second part and moves it to disk.

The uploaded PHP file lands at wp-content/uploads/elementor/forms/ using PHP’s uniqid() function — time-based, not random. An attacker can brute-force the filename. On sites with autoresponder emails enabled on the form, the exact URL can appear in the confirmation email. Once the attacker hits that URL, the server’s PHP interpreter runs the payload with web server privileges. Full site compromise from there is straightforward.

Who Is Actually Exposed

Elementor Pro is installed on more than 12 million WordPress sites. Not all of them are vulnerable to this specific attack path. Patchstack is explicit: exploitation requires a published page with an Elementor form that has a File Upload field. That is a common configuration. Job application forms, support ticket attachments, client intake forms that ask for a photo or document — all of these qualify. The “Required” toggle being off is the default state, so no unusual setup is needed.

Running Elementor Pro without a File Upload form field? The immediate code execution path doesn’t apply. But that is not a reason to delay the update — 4.2.2 includes broader security enforcement improvements, and the precondition can be added to a site at any point.

August’s Third Unauthenticated RCE in the WordPress Ecosystem

This is the third critical unauthenticated or near-unauthenticated RCE advisory to hit WordPress in August 2026. Forminator Forms (CVE-2026-15748, CVSS 9.8) patched a pre-auth file upload flaw on July 31. WordPress core 7.0.4 patched an author-level RCE through malicious Postscript uploads on August 12. CVE-2026-32475 closed on August 19.

Three separate attack surfaces. Three separate patch windows. Each one a different reason a site running out-of-date plugins was exposed while neighbors running current versions weren’t.

The pattern Patchstack’s 2026 State of WordPress Security report documents is consistent: attackers weaponize disclosed vulnerabilities within hours. Disclosure is not a safe period. It is the starting gun.

What to Check Right Now

If you manage WordPress sites running Elementor Pro:

  1. Confirm the current version. Plugins > Installed Plugins > Elementor Pro. Anything below 4.2.2 is unpatched.
  2. Check for File Upload fields in published forms. Pages > All Pages, then inspect any Elementor-built page with a contact or submission form. If a File Upload widget is present and the page is live, that site was in the blast radius before the patch.
  3. Audit the upload directory. Look inside wp-content/uploads/elementor/forms/ for any .php files. A legitimate Elementor upload will not place PHP there — only a successful exploit will.
  4. Review server logs. Look for POST requests to the form endpoint followed by GET requests to wp-content/uploads/elementor/forms/*.php.
  5. Update immediately. The changelog entry in 4.2.2 reads “Improved code security enforcement in Form widget” — understated for a CVSS 9.0 patch, but it is the right version.

Managed hosting platforms that apply virtual patching — Patchstack vPatches, Wordfence firewall rules, server-layer WAF rules — blocked exploitation of the upload path before customers updated. If your stack doesn’t have that layer, the update window is the only protection.

The Broader Maintenance Argument

Every month in 2026 has produced at least one critical plugin vulnerability. The Patchstack model on disclosure timelines shows that once an advisory goes public, exploitation attempts begin within hours. Forminator had 300,000 vulnerable sites sitting unpatched weeks after the fix was available. Elementor Pro’s install base is forty times larger.

The question for any agency or developer managing a client fleet isn’t whether updates matter — it’s whether your current process can close a 9.0 CVE before attackers can act on the advisory. If the answer is “we update when we notice,” that is not a process. That is luck.

Google’s Generative AI Report Is Expanding in Search Console — and Cloudflare’s September 15 Deadline Affects Everything You’re About to Track

Posted on by di_admin

Two Moving Parts, One Narrow Window

Most WordPress site owners are still waiting on the Generative AI tab in Search Console. Some have had it since June. What matters now is not the rollout order — it is understanding what the report does and does not measure before Cloudflare quietly changes the defaults on the crawlers feeding Google’s AI answers.

What the Generative AI Performance Report Actually Shows

Google launched the dedicated Generative AI performance report in Search Console on June 3, 2026, initially as a direct response to the UK Competition and Markets Authority mandate under the Digital Markets Act. The rollout was limited to a subset of UK-based properties first. By August 11, the report was appearing across a significantly larger pool of Search Console properties globally — still not universal, but expanding fast.

The report lives under Performance → Generative AI in the left-hand navigation. It separates AI-specific impression data into its own dedicated view, pulling it out of the standard Performance report where it was previously buried with no way to isolate it. Historical data goes back to May 18, 2026 only. There is no retroactive backfill.

What it measures:

  • Impressions for AI Overviews, AI Mode, and generative features in Google Discover
  • Pages — which specific URLs are being cited inside AI-generated answers
  • Countries and Devices breakdowns
  • Date trends at hourly, daily, weekly, or monthly granularity

What it does not measure: clicks. No CTR, no click data, no query-level breakdown. That gap is real. Industry research puts organic CTR on AI Overview queries somewhere between 0.61% and 2.4% depending on the study period — structurally lower than standard organic results. A page can accumulate thousands of AI impressions and drive almost no measurable session traffic. Pair the GSC report with GA4 or your host’s raw logs. Reading AI impressions in isolation is how teams convince themselves they are winning while conversions flatline.

One terminology distinction worth getting right before touching any settings: the opt-out control added alongside this report (under Settings → Search generative AI) blocks your content from appearing in AI Overviews, AI Mode, and generative Discover features. It does not touch your standard organic rankings. It is also entirely separate from Google-Extended, which governs whether Google trains its models on your content. These are two different switches with two different scopes.

Cloudflare’s September 15 Deadline

On July 1, 2026, Cloudflare reclassified all AI crawler traffic into three behavioral categories: Search (indexing your content to answer questions later), Agent (real-time automated activity on a user’s behalf — an AI assistant fetching your pricing page), and Training (bulk content collection for model training or fine-tuning). Starting September 15, new defaults apply.

For new domains joining Cloudflare on or after September 15: Training and Agent crawlers are blocked by default on pages Cloudflare classifies as displaying ads. Search stays allowed.

For existing free-tier customers: the same defaults activate automatically on September 15 unless you configure your settings before that date. Existing paid (non-Enterprise) zones with configurations already in place are not automatically changed.

The critical catch is multi-purpose crawlers. Googlebot crawls for both search indexing and AI training under a single combined user-agent string. Blocking Training means Cloudflare enforces that restriction across Googlebot’s full combined behavior. You can inadvertently affect indexing on ad-supported pages without intending to. Cloudflare’s own Radar data for June 2026 illustrates exactly why publishers are drawing these lines: Anthropic’s crawl-to-referral ratio sat at approximately 4,580:1, OpenAI at 848:1. Google came in at 5:1. The disparity is structural. Bot traffic has surpassed human traffic on the internet for the first time — that is the context in which Cloudflare is setting September 15 as a deadline.

If your WordPress site runs AdSense, Mediavine, Ezoic, or any display ad network and you are on Cloudflare’s free tier, this default applies to your property in 26 days.

What to Check This Week on a WordPress Site Using Cloudflare

The two silent failure modes if you do nothing: Training crawlers get blocked on your ad pages (which may be fine, depending on your content monetization strategy), or Agent crawlers get blocked, cutting off AI assistants that users actively send to your site to fetch product details, service descriptions, or WooCommerce pricing. The second failure is invisible until a user reports it or you notice a pattern in referral logs.

Two actions, both under 15 minutes:

1. Search Console check. Open your property and look in the Performance section for the Generative AI tab. If the full report is not yet available, go to Settings → Search generative AI regardless — the opt-out toggle may be accessible even before the impression report appears for your property. Make a deliberate choice about that setting before defaulting into either direction.

2. Cloudflare bot audit. Log into your Cloudflare dashboard, select your domain, go to Security → Bots → AI Scrapers and Crawlers. Review your current settings for each of the three categories (Search, Agent, Training). If you previously enabled the legacy “Block AI Bots” toggle, confirm that Googlebot is not caught under a Training block — this is the specific configuration error Cloudflare has flagged as the most common oversight. Changes take effect immediately.

Neither action requires a developer. Both require a decision before September 15.

The Measurement Gap Nobody Is Talking About

The GSC Generative AI report shows impressions. Cloudflare’s new defaults can silently alter which crawlers reach your ad pages. If Training or Agent bots are blocked before Google finalizes its AI Overview citations, you may see impression counts drop without an obvious cause in Search Console. The report will show the outcome. It will not show the infrastructure decision that caused it.

AI Overviews average 13.34 source citations per response as of early 2026, up from approximately 6.8 in 2024. Brands cited inside AI Overviews receive 35% more organic clicks and 91% more paid clicks than non-cited brands appearing on the same SERP. The visibility has real downstream value. Losing it to an unreviewed Cloudflare default is an entirely avoidable outcome.

Google’s August 2026 Spam Update Is Live: The Third SpamBrain Sweep of the Year and What ‘Normal’ Detection Now Catches

Posted on by di_admin

Google’s Third Spam Sweep of 2026 Is Already Reshaping SERPs

The August 2026 spam update started rolling out August 18 at 9:27 a.m. Pacific. Google logged it as a ranking incident on the Search Status Dashboard and posted one line: “The rollout may take a few days to complete.” No blog post, no expanded policy notice, no new prohibited practices. Three spam updates in eight months — March, June, August — and none of them came with a policy change attached. SpamBrain just gets sharper each pass.

This is Google’s third confirmed spam update of 2026. It follows March’s update (completed in a single day) and June’s update (two days, which came after Google clarified that its spam policies extend to attempts to manipulate AI Overviews and AI Mode responses). The August rollout applies globally, covers every language, and Google declined to say what percentage of queries it impacts.

What This Update Targets — and What It Does Not

Spam updates and core updates are not the same animal. A core update recalibrates how Google evaluates overall site quality. A spam update improves how SpamBrain detects violations of policies that already exist. The rules didn’t change. The detection engine did.

Google confirmed through John Mueller on LinkedIn that the early-August SERP volatility many sites experienced was not a preview rollout. “We don’t roll them out beforehand,” Mueller stated. Those pre-August-18 fluctuations — documented by AccuRanker, Mozcast, and SEMrush, with some site owners reporting traffic drops of 70% or more on August 5 — remain unexplained by Google. If your traffic drop started before August 18, that’s a separate investigation.

This update does not target link spam. It does not address the site reputation abuse policy. It targets spam techniques against Google’s existing policies: keyword stuffing, hidden text, auto-generated low-quality content, and unnatural link patterns.

The SpamBrain Problem Most Coverage Is Missing

The uncomfortable signal this cycle comes from SEO analyst Marie Haynes, who has tracked SpamBrain behavior since the August 2025 spam update. Her observation: SpamBrain is increasingly catching sites that produce “scaled content produced primarily for rankings” — content that would not exist if search engines didn’t incentivize it. Sites with templated publishing workflows, topic-cluster builds driven by keyword density, or AI tools used for output volume without genuine expertise or named authorship are getting flagged even when individual pages pass a basic quality review.

That’s a structurally different problem than classic spam. Classic spam is obvious. This is architectural. If your editorial workflow is organized around ranking rather than reader utility, the August update may flag you regardless of whether any individual page looks spammy on its own.

Google has said explicitly that recovery from spam-related systems can take many months. Automated systems need time to reassess a site after problems are addressed. Panic-edits during an active rollout don’t accelerate that timeline.

What to Do Right Now

Pull Search Console’s Performance report and isolate data from August 18 forward. Separate organic search traffic from Discover and Google News traffic before drawing any conclusions — they behave on independent systems. Cross-check against GA4 and raw server logs; analytics anomalies masquerade as ranking drops more often than most teams expect.

If you confirm sustained drops tied to August 18 or later:

  1. Read Google’s spam policies in full and audit your site honestly against each section — not just the ones you’re confident about.
  2. Focus the audit on scaled content: templated pages, location-variant pages, AI-generated posts without original insight or named authorship, thin category archives.
  3. Check the Manual Actions panel in Search Console. Spam updates are automated, but manual actions occasionally run alongside major sweeps.

For WordPress operators specifically: if you’re running any plugin that generates content programmatically from templates or external data feeds, review output quality now — not just output volume. The question SpamBrain effectively asks is whether the content would exist if search engines didn’t. If the honest answer is no for a significant share of your index, you’re exposed.

Wait for the Search Status Dashboard to mark the rollout complete before making significant page removals or restructuring decisions. Moves made during an active rollout are made against incomplete data.

Forminator Forms CVE-2026-15748: The CVSS 9.8 Flaw That Left 300,000 WordPress Sites Exposed Since July 31

Posted on by di_admin

Half of Forminator’s Install Base Is Running a Pre-Auth RCE Hole

The patch has been available since July 31. The plugin updated to version 1.56.2. WordPress.org published the advisory. And as of mid-August, over 300,000 sites are still running a version of Forminator Forms that lets an unauthenticated visitor upload a PHP file and execute arbitrary code on the server.

That is not a theoretical threat. CVE-2026-15748 carries a CVSS score of 9.8. The plugin has over 600,000 active installations. Per WordPress.org install data reviewed by Defiant (Wordfence), approximately half have not applied the patch. The math is straightforward and unpleasant.

What the Exploit Actually Does

The vulnerability lives in handle_file_upload(), the function Forminator uses to process file attachments submitted through its drag-and-drop form builder. The flaw is not a single weak point — it chains three separate weaknesses.

First, the plugin’s dangerous-file-extension blocklist uses exact-key matching. An attacker can bypass it by supplying a pipe-alternative MIME type key — the blocklist doesn’t recognize the alternative key format, so the PHP file clears the check. Second, Forminator’s public submission handler trusts the upload field configuration passed in the request body. An attacker can forge a Select field value to inject and control the field configuration reaching handle_file_upload(). Third, because the submission endpoint is public and unauthenticated, no login or prior account is required. The only actual prerequisite is that the targeted form contains both a File Upload field and a Select field.

Successful exploitation drops an executable PHP file — effectively a webshell — into the site’s upload path. From there the attacker has server-level access: WordPress credentials, database contents, configuration files, the ability to install additional payloads. Full site compromise in the language of the advisory means exactly that.

The Exploitation Timeline Is the Real Urgency

Security guidance published by OOPSpam in early August put a number on how fast this kind of disclosure turns into active scanning: automated bots begin probing WordPress sites for newly disclosed plugin vulnerabilities within hours, routinely before site administrators have seen an alert. That compression between disclosure date and first probe is the operational problem. A vulnerability disclosed on a Friday afternoon can be hitting sites across an agency’s entire client roster before Monday morning.

CVE-2026-15748 was disclosed publicly alongside the July 31 patch. The EPSS score trajectory on CVEfeed shows exploitation probability climbing through August as the disclosure spread across security feeds. No confirmed in-the-wild exploitation has been reported as of August 18 — but the absence of a confirmed incident is not evidence that scanning isn’t happening.

With 300,000 exposed installs sitting in search engine indexes, the attack surface is large enough to attract automated tooling regardless of whether a targeted campaign is underway.

What Needs to Happen on Every Site You Manage

Update Forminator Forms to version 1.56.2 or later. That is the non-negotiable starting point. If you manage WordPress sites at scale, run a query across your fleet before anything else:

“bash wp plugin list --field=name,version --format=csv | grep forminator “

Or with WP-CLI across multiple sites:

“bash wp plugin update forminator --path=/var/www/html “

After the update, three additional checks matter.

Audit your upload directories. Navigate to wp-content/uploads/forminator/ and scan for any .php files that shouldn’t be there. If you find one, you have a compromise, not a vulnerability — the investigation scope changes immediately. A WAF or server-side rule blocking PHP execution inside wp-content/uploads/ is worth adding regardless of whether you find anything.

Review any forms combining File Upload and Select fields. That configuration is the exploit prerequisite. If a form doesn’t need file uploads, remove the field. If it does need file uploads, confirm the updated plugin is restricting file types server-side, not just client-side.

Check your upload root for .htaccess protection. On Apache, a file at wp-content/uploads/.htaccess containing php_flag engine off or an equivalent deny rule blocks PHP execution even if a file gets through. Nginx requires a location block. Neither is a substitute for patching — both are useful defense-in-depth layers.

The Pattern Behind the Specific Flaw

Forminator is the third high-profile WordPress plugin to surface a critical vulnerability in this patch window. Earlier this month, WooCommerce’s Apple Login authentication chain was broken by three concurrent plugin patches, and BdThemes plugins were pulled from WordPress.org entirely after a supply chain attack delivered rogue admin accounts without touching a single file on disk.

The Forminator flaw is structurally different from both of those but shares one characteristic: it exploits a gap between what the plugin assumed about its own input validation and what an attacker can actually supply. The blocklist bypass via pipe-alternative MIME type keys is exactly the kind of edge case that passes code review and fails under adversarial testing. File upload handling is consistently among the highest-risk surfaces in the WordPress plugin ecosystem — Patchstack’s 2026 security whitepaper identifies unrestricted file upload (CWE-434) as a recurring critical vulnerability category across the ecosystem.

For agencies managing sites at scale, the operational implication is not just “patch faster.” It is maintaining a continuous, accurate plugin inventory across every client deployment — because the gap between “we use Forminator” and “which version are all 40 of our client sites running” is where incidents start.

FAQ

Is my site vulnerable if Forminator Forms is installed but I have no forms with both a File Upload and Select field? The specific chained exploit requires both fields in the same form. A site running Forminator Forms without that combination is technically less exposed to this particular attack path. Update anyway — the version boundary is the clean line, and other vulnerabilities may surface in later advisories against older builds.

Will Wordfence’s free firewall block this attack? Wordfence released a firewall rule for CVE-2026-15748 alongside the public advisory. Free tier users receive firewall rules on a 30-day delay. That means free-tier sites running Forminator 1.56.1 or earlier were unprotected at the firewall level for the first month after disclosure. The patch is the correct fix — the firewall rule is a secondary layer.

How do I confirm the patch applied correctly? In wp-admin navigate to Plugins > Installed Plugins and locate Forminator. The version displayed should read 1.56.2 or higher. If auto-updates are enabled and the plugin shows an older version, the update may have failed silently — trigger a manual update and check server disk write permissions on wp-content/plugins/.

Google AI Overviews Now Cover Half of All US Searches — and the Click Data Should Change How You Build Content

Posted on by di_admin

The Impression Line Went Up. The Click Line Went Down.

BrightEdge tracked 12 months of data across a large publisher sample and found total search impressions rose 49% since Google AI Overviews expanded at scale. Clicks to those same pages dropped roughly 30%. More people are seeing Google search results pages than ever before. Fewer are leaving Google to read what’s on them. That gap is the defining SEO dynamic of 2026, and it’s not theoretical — it’s in every agency’s Google Search Console right now.

AI Overviews now appear on approximately 48 to 50% of all US Google search queries. That’s up from 6.49% in January 2025. A near 8x expansion in 15 months, confirmed by both BrightEdge data and Google’s own official disclosure that the feature reaches roughly 2 billion users every month globally.

The Pew Research Center ran the most methodologically rigorous primary study on actual user behavior: 900 US adults across 68,879 real Google searches. When an AI Overview appeared, users clicked a traditional organic result only 8% of the time versus 15% without one — a 47% relative decline. Only 1% of users clicked a link inside the AI Overview itself. A 26% session abandonment rate was measured. Those sessions didn’t end because a user clicked a competitor. They ended because Google answered the query completely and the user closed the tab.

The Informational Content Problem

Not every page type gets hit equally. AI Overviews are an answer-first feature and they trigger almost exclusively on informational intent. Ahrefs data shows health queries generate AI Overviews on 43% of searches. Home and garden: 50.4%. Educational guides, tutorials, how-to content, explanatory blog posts — these are the exact content formats WordPress-heavy sites tend to produce most.

E-commerce and transactional queries are largely spared. AI Overviews appear on roughly 3.2% of shopping queries (Google pulled back early after AI responses weren’t converting to sales). If your site’s traffic comes primarily from informational content — and most agency-built WordPress content sites do — the exposure is direct.

Seer Interactive’s longitudinal study across 2.43 billion impressions, 53 brands, and 5.47 million queries found organic CTR on AI Overview queries collapsed from 1.76% to 0.61% between June 2024 and September 2025. That’s a 65% drop. It has since partially recovered to 2.4% by February 2026 as Google iterated on the feature, but the gap between AIO-present queries (2.4% CTR) and AIO-absent queries (3.8% CTR) is now the structural baseline. Plan around it, not against it.

For context on severity: some sectors reported 40 to 70% organic traffic losses in a single year. Named publishers have disclosed specific figures — HubSpot estimated a 70 to 80% organic traffic decline, CNN dropped 27 to 38%.

Citation Is the New Position One

Here’s where the story shifts. Pages that get cited inside an AI Overview don’t just survive — they gain. Data from Digital Applied (March 2026) shows brands cited in AI Overviews earn 35% more organic clicks and 91% more paid clicks compared to non-cited competitors on the same queries. Seer Interactive found a 35% traffic lift for cited brands versus those not cited. Only 17% of AI Overview citations come from pages ranking in the organic top 10 — down from 76% in mid-2024. Being on page one no longer guarantees citation. Being structured correctly does.

Users who click through from an AI Overview have already read a summary and want depth. They convert 23% better than average organic visitors. These are not casual browsers. The traffic that survives AI Overviews is higher quality than the traffic that doesn’t.

The operational shift this demands: GEO — Generative Engine Optimization — is no longer a theoretical future concern. It’s the decision sitting in your editorial workflow today. Pages that lead with a direct, citable answer to the query intent, establish clear topical authority across a subject cluster, and use structured formatting that AI models can extract cleanly are the pages that get named in the summary rather than displaced by it.

What to Check in Search Console Right Now

Open Google Search Console and pull Performance data filtered to your top 50 informational pages. Sort by impressions. A page showing stable or rising impressions alongside falling clicks and a declining CTR percentage is the diagnostic signature of AI Overview suppression. The impressions tell you Google still considers your page relevant. The CTR collapse tells you users are getting the answer before they reach your result.

Pages where both impressions and clicks are falling simultaneously are a different problem — ranking loss, not AIO suppression. Treat them differently.

For pages in the suppression bucket, the restructure priority is: move the direct answer to the query to the first 60 words of the body content. Make it one clean paragraph Google can extract without surrounding noise. Follow it with depth that a summary can’t replicate — original data, specific examples, practitioner-level detail. The page’s job is no longer only to rank. It’s to earn the citation and then satisfy the user who clicks through wanting more than the summary gave them.

Ahrefs, Semrush, and Moz all now surface AI Overview presence for target keywords. Running weekly audits against your priority keyword set gives you early warning before traffic drops register in analytics — impressions start moving first, clicks follow with a lag.

Local intent queries remain largely safe. AI Overviews appear in roughly 7% of local searches. For Phoenix-area clients whose pages target hyper-specific geographic intent, the exposure is lower. Generic informational content on the same site is a separate calculation.

FAQ

What is Generative Engine Optimization (GEO)? GEO is the practice of structuring content so it earns citation within AI-generated search responses such as Google AI Overviews or AI Mode. It involves leading pages with direct, extractable answers, establishing depth and topical authority, and using clear formatting that AI systems can parse. Google’s own May 2026 guidance confirms GEO and traditional SEO are not separate disciplines — strong foundational SEO combined with content only your team can produce is what earns visibility across both surfaces.

If my page is cited in an AI Overview, does that help or hurt traffic? It helps, materially. Pages cited inside AI Overviews earn roughly 35% more organic clicks than non-cited competitors on the same query, and the users who click convert 23% better. Citation is currently the highest-value position on an AI Overview query — higher than holding the top unpaid organic slot below the summary.

Which content types are most at risk? Informational content — guides, tutorials, explainers, how-to posts — triggers AI Overviews on the vast majority of queries. Health, home improvement, education, and technology are the highest-frequency categories. E-commerce product pages and local intent queries see substantially lower AI Overview rates and less click suppression.

How do I know if my site is being affected? In Google Search Console, filter Performance to informational landing pages. Pages with stable or rising impressions but falling CTR and clicks are experiencing AIO suppression. Pages with falling impressions have a ranking problem. The two situations require different responses.

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

Posted on by di_admin

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

Posted on by di_admin

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

Posted on by di_admin

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.

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

Posted on by di_admin

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

Posted on by di_admin

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: