DEV Community: Billion Web Studio

The PHP Vulnerability Behind PHP2Shell: Who Is at Risk and What to Do Now

Billion Web Studio — Fri, 23 Oct 2026 15:46:06 +0000

Two critical flaws in PHP itself, CVE-2026-109618 and CVE-2026-109619, were patched on 21 October 2026. Here is how to tell if your website is exposed, and the steps to take today.

On Wednesday, 21 October, the PHP project shipped four security releases in a single afternoon and asked every PHP user to update immediately. By Thursday, US Google searches for "PHP vulnerability" had reached their highest point of the week, and the bug had a nickname: PHP2Shell.

If your website runs on WordPress, WooCommerce, Drupal, Joomla, Magento, Laravel or almost any other PHP software, this one concerns your server, not your plugins.

This guide explains the PHP vulnerability in plain English, shows who is exposed and who is not, gives you the commands to check your own server, and lists what to do today and over the next few weeks. Every fact comes from PHP's own advisories, government security agencies or the vendors involved.

Key Takeaways

Two critical flaws in the PHP runtime, CVE-2026-109618 and CVE-2026-109619, can let an attacker who is not logged in run code on a web server. PHP rates both 9.2 on CVSS v4.0.
The fix is a PHP update: 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your Linux vendor's patched package. Updating WordPress, a plugin or a theme does not fix it.
Every PHP installation that serves web requests is in scope. PHP rates the risk highest for Apache with mod_php.
PHP 8.1 and older get no official release. You need a vendor backport, PHP's source backports or an upgrade.
Amazon and Cloudflare have seen exploit attempts. As of 23 October, CISA has not added either CVE to its Known Exploited Vulnerabilities catalog, and no successful break-in has been publicly confirmed.
After patching, restart every PHP worker, then check your logs back to 17 October.

What happened, in plain English

PHP is the language behind the server side of most websites. W3Techs finds it on 69.3% of websites whose server-side language it can detect (data dated 23 October 2026).

Researchers found that when PHP runs out of memory or hits a fatal error in the middle of a request, it can leave behind scraps of half-built or already-freed data. A carefully built request can make PHP reuse those scraps in a way the attacker controls. The result is remote code execution: the attacker runs their own commands on your server, with the same permissions as your website.

No login is needed, and no plugin bug is needed. The weakness sits inside PHP itself, underneath WordPress, Drupal or Laravel.

Here is how the week unfolded:

19 and 24 August: Wiz Research says it found the first of the bugs on 19 August and reported them to PHP on 24 August. PHP's advisories credit several researchers.
17 October: Amazon's honeypot network recorded a PHP2Shell exploitation attempt four days before disclosure.
20 October: PHP posted an advance notice of a critical release, with both flaws rated CVSS v4.0 9.2.
21 October, 03:02 UTC: Cloudflare switched on managed WAF rules for free and paid plans.
21 October: PHP released the fixed versions and published its security advisory.
23 October: PHP added an informational note about a third, much narrower issue (CVE-2026-115560), covered in the mitigation section below.

The technical detail

The two CVEs are separate bugs with the same root theme: PHP's error handling can leave memory in a state that a later step trusts by mistake.

CVE-2026-109618, "RCE via OOM corruption" (GHSA-w8hw-w9fx-j79w). PHP aborts a request with longjmp() when it runs out of memory. If that happens while request memory exists but is not fully set up, request cleanup can read or act on invalid data. The advisory lists ways to force the out-of-memory condition, such as multipart requests without a usable declared length, parts carrying many headers, empty file fields and deeply nested field names. PHP confirmed unauthenticated code execution against Apache mod_php with default limits.

CVE-2026-109619, "RCE via stale global state" (GHSA-6wmf-4rv5-p3rp). Long-lived PHP workers keep some global state that points into memory owned by one request. If a fatal error, a timeout or an out-of-memory event leaves that state behind, the next request handled by the same worker can use freed memory before normal setup resets it. Session upload progress, which is on by default, is one confirmed path. PHP confirmed it against both mod_php and PHP-FPM, and the application does not even need to call session_start().

Affected versions. PHP's advisories list 8.2 before 8.2.35, 8.3 before 8.3.36, 8.4 before 8.4.27 and 8.5 before 8.5.12. PHP 8.1 and older are past end of life, so the project did not ship releases for them. Wiz reports that releases dating back to PHP 5.4 are affected by at least one of the issues.

Severity. PHP scores both flaws 9.2 on CVSS v4.0. On the older CVSS 3.1 scale, NVD gives CVE-2026-109618 a 9.8 and CVE-2026-109619 an 8.1. Red Hat rates CVE-2026-109618 "Important" at 8.1, because reliable exploitation needs precise heap manipulation and timing. The scores differ, but the advice is the same everywhere: patch.

Exploitation status. Reports differ, so here is exactly who said what:

Amazon says it saw an attempt on 17 October and "broad exploitation attempts in the wild" after disclosure, while noting it is unclear whether any would have succeeded.
Cloudflare says it observed attack traffic targeting its customers.
Canada's Cyber Centre said on 21 October that a proof of concept is public but it had not identified active exploitation.
Neither CVE appears in CISA's Known Exploited Vulnerabilities catalog as of 23 October.

In short, attackers are trying. Treat the risk as real, without assuming every unpatched site has already been breached.

Who is in danger

PHP's advisory puts it plainly: all PHP installations serving web requests are at risk. How exposed you are depends mostly on how PHP runs on your web hosting setup.

Hosting setups

Apache with mod_php. Highest risk, according to PHP, because the attack can run before any application code does. In a phpinfo page or WordPress Site Health, this shows as "Apache 2.0 Handler".
PHP-FPM behind Nginx or Apache. Exposed. PHP's source analysis suggests the out-of-memory bug can be reached, though no complete FPM exploit has been shown, and the session upload progress path was confirmed against FPM.
php-cgi, FrankenPHP and LiteSpeed. All named in PHP's at-risk list.
Shared hosting. Your host patches PHP. Your job is to confirm it happened.
Managed WordPress platforms. Automattic says sites on WordPress.com, WordPress VIP, WP Cloud and Pressable are already protected, with nothing for customers to do.
cPanel and WHM servers. cPanel's EasyApache 4 25.91 release fixes ea-php74 through ea-php85. cPanel also patched its own internal PHP, which runs the cPanel interfaces and Roundcube webmail: versions 138.0.18, 136.0.50 and 134.0.66 include PHP 8.4.27, and 110.0.153 carries backported fixes for PHP 8.1.34.
Plesk servers. On 21 October, a Plesk staff member said the fixes would be included in Plesk PHP packages but gave no ETA. Check Plesk's announcements for your Obsidian version before you assume you are covered.
AWS. AWS's bulletin says Elastic Beanstalk managed platform updates apply the fix in the next maintenance window. Lightsail instances cannot be updated in place, so AWS advises creating new instances from updated blueprints and migrating. Lambda functions using custom runtimes or container images need a rebuild and redeploy.
Docker and other containers. Rebuild on a patched base image and redeploy. A patched host does not patch the PHP inside your container.
XAMPP and other local stacks. These bundle their own PHP. The risk is low while they only listen on your own machine, but any copy reachable from a network needs the same update.

CMSs and frameworks

Because the bug lives in the PHP runtime, every PHP application running on an unpatched version is in scope. Datadog's analysis notes that any PHP script exposes the vulnerable path, even one that only prints a response. Wiz demonstrated unauthenticated code execution against the latest WordPress, Drupal and Joomla container images.

That covers every major PHP CMS and framework:

CMSs and commerce platforms: WordPress and WooCommerce, Drupal, Joomla, self-hosted Magento Open Source and Adobe Commerce, PrestaShop, OpenCart, TYPO3, Craft CMS, Statamic, MediaWiki, phpBB and Moodle.
Frameworks: Laravel, Symfony, CodeIgniter and CakePHP, plus any custom PHP application.

None of these need their own patch to close the hole. WordPress.org said directly that no WordPress update is required or planned. The same logic applies to the others: the fix is in PHP, so updating the CMS, a theme or a plugin does not close it.

Who is not affected, and why

Hosted website builders such as Shopify, Wix and Squarespace. You never manage a PHP runtime on these platforms, so there is nothing for you to patch. The provider looks after its own stack.
Static sites and JavaScript stacks with no PHP anywhere. A Next.js or Astro site with no PHP server is out of scope. A headless WordPress backend behind it is not, because that backend still runs PHP.
Servers already on 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or on a vendor package that lists both CVEs as fixed, with every PHP worker restarted since.
PHP 8.6 RC4. PHP says this release candidate includes the fixes. Earlier 8.6 test builds do not, and no 8.6 build belongs in production yet.
Command-line-only PHP. PHP's advisory targets installations that serve web requests, so cron jobs and CLI scripts are lower priority. They usually share the same package, though, so they get patched along with everything else.

How to check if the PHP vulnerability affects your server

Work through these steps in order. The goal is to confirm the PHP that actually serves your website, which is not always the one your terminal shows.

Step 1: Find the PHP version that serves your site. Start inside your CMS:

WordPress: Tools, then Site Health, then the Info tab, then Server. Note the PHP version and the PHP SAPI. "Apache 2.0 Handler" means mod_php. "fpm-fcgi" means PHP-FPM.
Drupal: Reports, then Status report.
Joomla: System, then System Information.

Step 2: Check the server itself. If you have SSH access:

# Version of the command-line PHP (can differ from the web runtime)
php -v

# Is Apache loading PHP as a module (mod_php)?
apachectl -M 2>/dev/null | grep -i php

# Which PHP-FPM services are running?
systemctl list-units --type=service | grep -i fpm

# Is session upload progress still on? (CLI config; check FPM pool files too)
php -i | grep -i "session.upload_progress.enabled"

# The PHP version Composer sees, useful in CI and deploy scripts
composer show --platform | grep "^php "

Step 3: Read the package changelog, not just the version number. Linux distributions often backport fixes without changing the upstream version. On Ubuntu 24.04 LTS, for example, the fixed package is php8.3 version 8.3.6-0ubuntu0.24.04.13. That looks "old", yet it is patched. Search the changelog for the CVE numbers:

# Debian and Ubuntu
apt changelog php8.3-fpm 2>/dev/null | grep -m3 -E "CVE-2026-10961[89]"

# RHEL, AlmaLinux, Rocky Linux and CloudLinux
rpm -q --changelog php-fpm | grep -m3 -E "CVE-2026-10961[89]"

# cPanel EasyApache packages
rpm -qa 'ea-php*-php-fpm' | sort
rpm -q --changelog ea-php81 | grep -m3 -E "CVE-2026-10961[89]"

# Plesk (adjust the version folder)
/opt/plesk/php/8.3/bin/php -v

Step 4: Confirm the workers restarted after the update. A patched package on disk does nothing until PHP reloads it.

systemctl status php8.3-fpm | grep Active
systemctl status apache2 | grep Active    # httpd on RHEL-based systems

If the "active since" time is earlier than your update, restart the service.

On shared or managed hosting, ask your host in writing: "Has the PHP that serves my site been patched for CVE-2026-109618 and CVE-2026-109619, and have the PHP workers been restarted?" A clear yes with a date is what you want.

What to do now

1. Update PHP. Move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or install your distribution's patched package. The PHP project is blunt about this:

"There are no complete mitigations, updating is the only safe choice."

2. Restart every PHP worker. Restart PHP-FPM pools, Apache, LiteSpeed and any container running PHP.

3. Deal with old branches. PHP 8.1 and older get no official release. Your options:

A vendor backport. Ubuntu Pro covers older LTS releases, including PHP 7.4 on 20.04, and cPanel shipped backports for ea-php74, ea-php80 and ea-php81.
PHP's own minimal source backports for 7.4, 8.0 and 8.1, if you build PHP from source.
An upgrade to a supported branch, tested on a staging site first.

If none of these is possible soon, the UK's NCSC advises organisations to consider taking the system offline until it can be fully mitigated. WordPress.org gives the same advice for self-managed servers on PHP older than 8.2.

4. If you cannot patch today, reduce exposure. PHP lists interim measures that cut off specific attack paths. None of them makes a server safe on its own:

Set session.upload_progress.enabled=0 in php.ini or the FPM pool configuration, then restart every worker. Do not rely on ini_set() or .user.ini for this. PHP's 23 October note recommends keeping it off until the next regular release anyway, because of the narrower CVE-2026-115560 issue.
On PHP 8.5, set fatal_error_backtraces=0 and restart.
Keep post_max_size low (PHP suggests 8M without uploads, 32M with them) and keep upload_max_filesize below it.
PHP also suggests memory_limit=-1 enforced with php_admin_value, paired with a container or cgroup memory limit. Talk to your host first: removing the PHP memory limit means a runaway script can consume far more server memory.
If your site never accepts file uploads or multipart forms, block multipart requests at the proxy or WAF, as both PHP's advisory and Amazon suggest.
Turn on WAF rules. Cloudflare's managed rules cover free plans automatically, and paid plans should confirm the managed ruleset is set to block. AWS WAF users should run the latest PHP managed rule group. Vercel applied rules automatically for PHP traffic it serves or proxies. Every one of these vendors says a WAF does not replace patching.

5. Check your logs back to 17 October. Amazon recommends starting investigations from 17 October, not the disclosure date. Look for:

POST form uploads containing the string PHP_SESSION_UPLOAD_PROGRESS (Amazon).
Unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses, oversized or malformed PHPSESSID cookies, and unexplained PHP worker churn (Wiz).
"Allowed memory size ... exhausted" errors reported at "Unknown on line 0", and Apache AH00052 segmentation fault lines (Datadog).
A web server process starting a shell, plus unexpected files, accounts, processes or outbound connections (Datadog and Canada's Cyber Centre).

Clean logs do not prove a server is safe, and noisy logs do not prove it was breached. Memory errors happen on healthy sites too.

6. If you find signs of compromise, take the site offline, restore from a backup made before 17 October onto a patched server, rotate database, admin, SFTP and API credentials, and follow a checklist such as WordPress.org's guide for hacked sites.

7. Fix the habits that made this hard. Once the emergency passes:

Know which PHP branch every site runs and when its support ends. PHP's supported versions page shows 8.2 security support ending on 31 December 2026, 8.3 on 31 December 2027, 8.4 on 31 December 2028 and 8.5 on 31 December 2029.
Plan any 8.2 site's move to 8.4 or 8.5 now, while you have a few weeks rather than a few hours.
Set a written patch window for critical runtime fixes. Amazon advises measuring response to critical internet-facing flaws in hours, not days.
Keep tested, off-server backups and a staging copy of every important site.
Treat outdated runtimes as a known risk. OWASP's Top 10 lists vulnerable and outdated components as a core web application risk for exactly this reason.

What we're doing for our clients

For the sites we build and look after, our website maintenance routine this week is the same checklist as above. We confirm the PHP runtime and SAPI for each site rather than trusting the CLI version, check package changelogs for both CVE numbers, restart workers and verify the restart time, and review logs from 17 October onward. Sites still on PHP 8.2 get an upgrade plan to a newer branch before 8.2's security support ends on 31 December 2026.

If you run a WordPress or WooCommerce site and are not sure what your host has done, our WordPress development team can run these checks with you.

FAQ

What is PHP2Shell and how does it affect my website?

PHP2Shell is the nickname for two critical bugs in PHP itself, CVE-2026-109618 and CVE-2026-109619. On an unpatched server, an attacker who is not logged in could run code with your website's permissions. That puts your files, database and customer data at risk. Your site is affected only if the PHP serving it has not been updated.

Do I need to update WordPress, Drupal or Joomla to fix it?

No. The fix is in PHP, not in the CMS. WordPress.org says no WordPress update is required or planned. Keep your CMS updated for its own security fixes, but only a PHP update closes PHP2Shell.

Will a security plugin or a firewall protect my site?

A security plugin cannot be relied on, because the attack happens in PHP's own request handling, which can run before WordPress loads. A network WAF from Cloudflare, AWS or Vercel can block known attack patterns, and it is worth turning on while you patch. Every one of those vendors says a WAF does not replace the PHP update.

My site is on shared hosting. What should I do?

Ask your host in writing whether the PHP serving your site has been patched for both CVEs and whether PHP workers have been restarted. Then check the PHP version in your control panel or in WordPress Site Health. If your host cannot confirm a date, consider moving to a host that can.

Is there a script that tests whether my server is vulnerable?

Running exploit code from the internet against a live server is risky and may itself be harmful. A safer check is the one in this guide: confirm the serving PHP version, look for both CVE numbers in your package changelog, and confirm the restart. Commercial scanners such as Tenable's Nessus have also added detection plugins.

My server shows an older PHP version number, but my host says it is patched. Who is right?

Possibly both. Linux distributions backport security fixes without changing the upstream version number. Ubuntu 24.04's patched PHP 8.3 package, for example, still reports 8.3.6. The package changelog is the reliable record, so search it for the two CVE numbers.

My site runs an end-of-life PHP version. Do I have to take it offline?

Not necessarily, if you can get a patched build. Check for a vendor backport through Ubuntu Pro, cPanel or another long-term support vendor, or build from PHP's source backports. If you cannot get a fix quickly, the UK's NCSC and WordPress.org both suggest considering taking the server offline until you can upgrade.

Has anyone actually been hacked through PHP2Shell yet?

As of 23 October, no successful compromise has been publicly confirmed. Amazon and Cloudflare have reported exploit attempts, and CISA has not added the CVEs to its Known Exploited Vulnerabilities catalog. That can change quickly, which is why patching comes before waiting for proof.

Why do PHP, NVD and Red Hat give different severity scores?

They use different scoring systems and assumptions. PHP scores 9.2 on CVSS v4.0. NVD scores CVE-2026-109618 at 9.8 on CVSS 3.1, while Red Hat scores it 8.1 because reliable exploitation needs precise heap manipulation. All three agree it needs patching.

The bottom line

The PHP vulnerability behind PHP2Shell is serious because it sits below everything you normally patch. Your CMS can be fully up to date while the PHP underneath it is not. Five steps get you clear: find the PHP that serves your site, confirm the fix in the package changelog, restart the workers, check your logs back to 17 October, and plan your move off any branch that is near end of life.

If you'd like a second pair of eyes on your setup, get in touch with Billion Web Studio.

Ganesh Shanmugam is the founder of Billion Web Studio, a website development company building for businesses in the USA, the UK, Dubai and the wider UAE, Canada, Australia and India.

How to Build a Website With AI: A 12-Point Checklist Before You Launch

Billion Web Studio — Fri, 23 Oct 2026 15:45:26 +0000

Learning how to build a website with AI takes an afternoon. Type a few lines into an AI builder and you get a polished homepage before your coffee cools. The trouble arrives weeks later: no enquiries, half the pages missing from Google, and a quote button that some visitors can't use at all.

We're Billion Web Studio, a website development company led by founder Ganesh Shanmugam. This checklist gives you the 12 checks we'd hand any business owner before they publish an AI-built site, in the order you'll meet them. You'll also get real before-and-after examples, the Google and legal rules that apply in the US, the UK and the UAE, and a plain test for when a developer is worth paying.

Key Takeaways

AI is great at first drafts of layouts, copy and code. It is weak at your facts, your legal duties and everything that happens after launch.
Own the domain, the code and the data before you write a single prompt, so you can leave the tool later.
Google doesn't punish content for being AI-written. It punishes pages mass-produced to game rankings that add nothing for readers.
Delete every testimonial, figure and badge the AI invented. Fake reviews are banned in both the US and the UK.
Check what crawlers actually receive. Content that only appears after JavaScript runs can be invisible to AI assistants.
Test accessibility, security and forms by hand. AI code runs fine and still fails these checks surprisingly often.
Bring in a developer when the site takes payments, holds personal data or carries most of your leads.

How to Build a Website With AI Without Paying for It Later

Most guides on how to build a website with AI stop at "write a prompt, pick a style, publish." That gets you a website. However, it doesn't get you a website that ranks, converts and stays safe.

So here is the honest split.

What AI tools do well:

Turn a rough brief into a tidy layout in minutes
Write a first draft of page copy that you then fix
Produce standard parts such as menus, service cards and contact sections
Speed up small code changes for anyone who can read the result

What they do badly:

Know anything true about your business that you didn't tell them
Follow search, accessibility and privacy rules unless you ask, and sometimes even when you do
Set up tracking, so you can see which page brought which lead
Look after the site once it's live

The 12 checks below follow the order of a real project: before you prompt, while you build, before you launch, and after launch. First, though, pick the route that fits your situation.

Before You Prompt: Decide Who Owns What

1. Own your domain, code and data from day one

Lock-in is the cost nobody shows on the pricing page. Some AI builders keep everything on their own platform, so leaving later can mean starting again.

Before you sign up, get a clear yes or no to each of these:

Is the domain registered in my name, in a registrar account I control?
Can I export the code, or sync it to a repository I own?
Can I host the site elsewhere if prices rise or the tool closes?
Can I download form entries, customer records and images in a standard format?

If any answer is no, you're renting your website rather than owning it. That's fine for a one-off event page. For the site your sales depend on, it's a real risk.

2. Match the tool to the job

When you plan how to build a website with AI, the first real decision is which kind of tool to use. "AI website builder" covers very different products. Prompt-to-site builders such as Wix, Squarespace and Webflow give you a hosted site with a visual editor. App builders such as Lovable, Bolt and Replit generate full code, often with a database and logins. Coding assistants such as GitHub Copilot, Cursor and Claude Code help someone who already reads code work faster.

The more code the tool writes for you, the more of its bugs you own. A hosted builder patches its own platform. A generated app hands you the code along with the responsibility. Building by describing what you want and accepting the code unread even has a name: vibe coding. It's great for prototypes. For anything holding customer data, it's a gamble.

While You Build: Feed the AI Real Facts

3. Write prompts with facts only you know

A vague prompt gets a vague website. The AI fills every gap with safe, generic copy that could belong to any company in your trade. Here is the difference, using a made-up plumbing firm called Harbor Plumbing.

Generic prompt:

Make a website for a plumbing company. Modern design, professional, with services and contact pages.

Prompt with real business facts:

Build a site for Harbor Plumbing with Home, Services, Areas, About and Contact pages. We serve Austin and Round Rock, Texas. Services: same-day water heater replacement, slab leak detection and whole-home repiping. Most visitors have an urgent leak and arrive on a phone, so put the phone number and a short quote form at the top of every mobile page. Tone: calm and plain, no buzzwords. Do not invent reviews, awards, years in business or statistics. Write [ADD FACT] wherever you need something I haven't given you.

The second prompt does three things the first can't. It supplies facts, it tells the AI what matters to real visitors, and it forbids invention. That last line matters most, as the next check shows.

4. Delete every claim the AI made up

AI builders love filler proof. "Trusted by hundreds of happy clients." "Award-winning service." A glowing quote from "Sarah M., satisfied customer." They look real, yet none of them came from you.

Publishing them is a legal problem, not just an awkward one. In the US, the FTC's final rule banning fake reviews and testimonials, announced on 14 August 2024, covers reviews from people who don't exist, including AI-generated ones. It also lets the FTC seek civil penalties against knowing violators. In the UK, the DMCC Act brought in an explicit ban on posting or commissioning fake reviews, and the CMA can now fine a business up to 10% of its global turnover.

So search the whole draft for figures, names, logos and badges, and confirm each one. If you can't prove it, delete it. Modest real proof beats impressive invented proof every time.

5. Make the content yours, not the model's average

Does Google penalise AI-written pages? Not for being AI-written. In February 2023, Google said that appropriate use of AI or automation isn't against its guidelines. What breaks its rules is content made mainly to manipulate rankings.

The trap to avoid is Google's scaled content abuse policy, last updated on 28 August 2026. One of its named examples is using generative AI to churn out many pages without adding value for users. On small business sites, the usual culprit is a stack of "plumber in [town]" pages where only the town name changes.

What turns an AI draft into content worth ranking:

Your own photos of real jobs, staff and premises
Prices, timelines and processes specific to you
Answers to the questions customers ask on the phone every week
A named person who stands behind the advice

Google's AI optimisation guide, updated on 10 July 2026, calls this non-commodity content that is helpful, reliable and people-first. In other words, the parts an AI can't guess are exactly the parts that rank.

Before You Launch: Check What AI Tools Skip

6. Fix the SEO basics by hand

AI builders usually add a title tag and a sitemap. Rarely do they get them right for your business. Check every important page for:

A specific title tag naming the service and the place
One H1 that says what the page offers, followed by H2s and H3s in order
Internal links between related services, areas and guides
An XML sitemap submitted in Search Console
No leftover noindex tags, which test setups sometimes leave behind

Here is a typical title tag fix:

Before: Home | Welcome to Our Website

After: Emergency Plumber in Austin, TX | Same-Day Water Heaters

Next, run your key pages through the URL Inspection tool in Search Console to confirm Google can fetch and index them. Also drop any promise of FAQ snippets that an AI tool or plugin makes. Google stopped showing FAQ rich results from 7 May 2026, so FAQ markup no longer earns a special listing. Keep the FAQ itself, though, because readers still use it.

7. Make sure crawlers can read your pages

Most owners have never heard of this check. Many AI app builders produce single-page apps: the server sends an almost empty HTML shell, and JavaScript paints the content in the browser.

Google can render JavaScript, and its JavaScript SEO basics explain how to make that work. AI crawlers are a different story. Vercel's study of AI crawler traffic, published in December 2024, found that none of the major AI crawlers, including OpenAI's GPTBot and Anthropic's ClaudeBot, rendered JavaScript. Its advice was to server-render critical content.

The quick test: open your page, right-click, choose View Page Source and search for a sentence from your main content. If the sentence isn't there, any crawler that skips JavaScript sees an empty page. In that case, ask for server-side rendering or static pages.

8. Check speed against Core Web Vitals

AI tools happily stack up animations, autoplay hero videos and several font families. Each one adds load time on an average phone.

Google's Core Web Vitals set clear pass marks, measured at the 75th percentile of page loads:

Largest Contentful Paint (LCP): 2.5 seconds or less
Interaction to Next Paint (INP): 200 milliseconds or less
Cumulative Layout Shift (CLS): 0.1 or less

Run your key pages through PageSpeed Insights and read the mobile result first, not desktop. Typical fixes include compressing images, removing unused scripts and fonts, and reserving space for images so the layout doesn't jump.

9. Test accessibility, because AI code often fails it

Accessibility problems are everywhere, not only on AI-built sites. The WebAIM Million 2026 report found detectable WCAG 2 failures on 95.9% of the top million home pages, with an average of 56.1 errors per page. Low-contrast text appeared on 83.9% of those home pages, and 16.2% of all home page images had no alt text.

Because AI models learned from that same web, they repeat its habits. The two we spot most often in generated code are clickable divs pretending to be buttons, and images with missing or useless alt text.

In the US, the legal risk is real. The Justice Department's guidance on web accessibility says the ADA applies to all the goods and services that businesses open to the public offer, and that inaccessible websites can shut people out. Plaintiffs filed 3,117 website accessibility lawsuits in US federal court in 2025, a 27% rise on 2024, according to Seyfarth Shaw's annual count.

Aim for Level AA of WCAG 2.2, the current W3C standard. Run a free WAVE scan, then tab through every page using only your keyboard. Be wary of accessibility overlay widgets that promise instant compliance. In April 2025, the FTC ordered accessiBe to pay $1 million and barred it from claiming its automated tools can make any site WCAG-compliant without evidence.

10. Treat AI-written code as untrusted until tested

AI code looks finished. It runs, it demos well, and it passes a glance. Security, however, is a separate test. Veracode's 2026 GenAI Code Security Report, released on 28 July 2026, found an average security pass rate of 56%. Put the other way, the models failed nearly 44% of the time when given no security-specific guidance.

There is a real-world example, too. CVE-2025-48757 records that sites generated by Lovable up to 15 April 2025 could ship with database access rules weak enough to let unauthenticated attackers read or write their tables. Lovable disputes the record, saying each customer is responsible for protecting their own app's data. Either way, the responsibility lands on you, the site owner.

Even developers don't take AI output on trust. In Stack Overflow's 2026 Developer Survey, 48% said they trust AI when they can easily check the answers. If you can't check the code yourself, someone else needs to.

At minimum, before launch:

No API keys or passwords in front-end code
Database access rules switched on, then tested from a logged-out browser
HTTPS on every page and spam protection on every form
Packages up to date, reviewed against the OWASP Top 10 risks
No customer data pasted into AI prompts

Privacy and cookies need the same care. AI builders readily add analytics tags, ad pixels and chat widgets, often without asking for cookie consent. In the UK, the Data (Use and Access) Act 2025 added an exception for analytics used only to improve your service, provided you explain it clearly and give a simple, free way to object. Advertising cookies still need consent. Meanwhile, the ICO can now fine up to £17.5 million or 4% of global turnover under PECR. In the UAE, the Personal Data Protection Law, in force since 2 January 2022, generally prohibits processing personal data without its owner's consent, with limited exceptions.

11. Test every form and track every lead

A beautiful site that loses enquiries is worse than a plain one that captures them. AI builders sometimes wire a form to nothing at all, or to an inbox nobody reads.

Before launch:

Submit every form yourself and confirm the email arrives with every field filled
Check the thank-you message, and make sure spam protection isn't blocking real people
Mark form submissions, calls and WhatsApp clicks as key events in Google Analytics 4
Tag campaign links so you know which ad or post sent each lead

Also, keep an eye on GA4's new AI Assistant channel. Since 13 May 2026, it shows visits from chatbots such as ChatGPT, Gemini and Claude. If your site is live but quiet, my guide on why a website isn't generating leads walks through the usual fixes.

The graphic below pulls checks 6 to 11 into a single test run you can do in one sitting with free tools.

After Launch: Stay Visible, Safe and Current

12. Plan for AI search without chasing myths

AI assistants now send real visitors, and getting cited follows mostly the same rules as ranking. Google's AI optimisation guide says you don't need new AI text files, special markup or Markdown copies to appear in its AI features, and that Google Search ignores them. That includes llms.txt. Structured data isn't required either, and there is no special AI schema to add.

What does help: pages that are indexed and eligible to show a snippet, content crawlers can read (check 7) and original expertise (check 5). If you'd rather keep your content out of Gemini, the Google-Extended token controls use for Gemini training and grounding. According to Google, it doesn't affect inclusion or ranking in Search.

Keep hosting, backups and updates on someone's calendar

An AI builder gets you to launch day. After that, somebody still has to answer these questions:

Who renews the domain and watches the security certificate?
Where are the backups, and has anyone tried restoring one?
Who updates plugins, packages and integrations?
Where do you test changes before they go live?

Re-run your pre-launch test after every big edit. Regenerating a section with AI can quietly overwrite the titles, alt text and tracking you fixed by hand.

Know when to bring in a developer

Knowing how to build a website with AI also means knowing where AI should stop. The decision tree near the top covers the main triggers. In short, bring in help when the site takes payments or logins, stores personal data, carries most of your leads, or replaces an older site that already ranks. Moving a site that ranks without a redirect plan can wipe out years of search traffic.

A developer doesn't have to replace AI, either. Often the best value is AI for the draft and a developer for the review: structure, security, tracking and speed.

That review work is what we do every day at Billion Web Studio. We build websites for businesses in the USA, the UK, Dubai and the wider UAE, Canada, Australia and other markets, India included. Our case studies show what the unglamorous checks above can do. Blues Renewables, a rooftop solar installer, had a slow, client-rendered site with no lead tracking. After its rebuild, it went from zero tracked leads to 7 to 10 enquiries a week, and its Google clicks grew from 14 to 560 a fortnight. Trucks India's weekly Google clicks grew from 12 to 292 after crawling and indexing fixes. Eco Industries, a packaging manufacturer, went from no website leads to about 10 a week, and Terah Tex, a uniform manufacturer, from none to about 5 bulk-order leads a week.

Frequently asked questions

Can AI build a whole website for me?

Yes, for a simple brochure site, AI can generate the pages, copy, code and even hosting in one session. What it can't do is supply your facts, meet your legal duties or decide what your business should say. Treat the output as a draft, then run the checks in this guide before you publish.

Can ChatGPT create a website?

ChatGPT can write HTML, CSS and JavaScript, plan a site structure and draft page copy. You'll still need a domain, hosting and someone to assemble, test and publish the pages. For most non-coders, a hosted AI builder is the simpler route, with ChatGPT helping on copy.

Does Google penalise AI-generated websites?

No, not for using AI. Google's position is that appropriate use of AI isn't against its guidelines. The risk comes from mass-producing thin pages to manipulate rankings, which falls under its scaled content abuse policy. Original facts, photos and expertise keep you on the right side.

Are AI website builders good for SEO?

They cover the basics, such as mobile layouts and an automatic sitemap. However, they often miss business-specific title tags, internal links, crawlable content and indexing checks. Expect to fix those by hand, as described in checks 6 and 7.

How can you tell if a website is AI-generated?

Common signs include copy that could fit any company, stock-style images with odd details, vague claims with no names or proof, and identical section patterns on every page. Visitors notice these too, which is why adding your own facts and photos pays off.

How much does it cost to have AI build a website?

The builder subscription is usually the smallest cost. Add your domain, any paid features, your own time on prompts and edits, and the fixes from this checklist. If a developer reviews the site, ask for a fixed quote for that review before work starts.

Is web design still worth paying for when AI can do it?

For a hobby site or a short campaign page, often not. For a site that carries your revenue, the value has moved from drawing layouts to the parts AI misses: structure, tracking, speed, accessibility, security and search visibility.

Final Thoughts

AI has made the first draft almost free. It hasn't made ownership, accuracy, accessibility, security or lead tracking automatic, and those are what decide whether a website earns money.

So if you remember one thing about how to build a website with AI, make it this: let the AI draft, then check its work like a sceptic before you launch. If you'd like a second pair of eyes on an AI-built site, you can ask Billion Web Studio for a review.