I put the most-copied version on a real WordPress install, then hit its endpoint ten times from a terminal with no login, no nonce and no cookie. All ten went through. Ten real calls to a real AI model, on my bill, from something that wasn’t my website.

So this is the honest version of how to add an AI chatbot to WordPress: the build, every way I managed to break it, and the hardened version I ended up with. I tested the whole thing for free on my own machine, and I’ll show you how to do that too.

Tested on WordPress 7.1.3, PHP 8.3 and WPCode 2.4.0. The Location behaviour in Step 1 is WPCode’s own, so check it still holds if you’re on a much newer version.

What this is, in plain words

A chat bubble sits in the corner of your site. A visitor clicks it, types a question, and an AI model answers in your words, following instructions you wrote.

You’re not installing someone else’s chatbot service. There’s no monthly fee to a third party, no branding you can’t remove, no visitor data sitting on a platform you don’t control. It’s your code, calling an AI model directly, and you decide what it’s allowed to say.

What it fixes, specifically:

• The same five questions, all day. Opening hours, pricing, do-you-cover-my-area. The bot answers at 2am without you.
• Visitors who leave rather than fill in a form. A chat box gets answered questions that a contact form never would.
• Paying monthly for a chat widget that puts its own logo on your site.

What it costs to run

Two honest options, and you can switch between them with one setting:

• A paid API key from OpenAI or Anthropic. You pay per message, usually a fraction of a penny each. Better answers, nothing to maintain.
• Free, forever, on your own server using Ollama. No key, no bill, no limit on messages. You need a machine you control with a few GB of spare RAM, so a VPS rather than shared hosting. Answers are noticeably weaker than a paid model.

Both routes run the exact same code. There’s a section further down on how I tested the whole thing for free before spending anything.

If you’d rather build it by hand and understand every line, keep reading. That’s what the rest of this is.

What you need

• A WordPress site you can install a plugin on (mine was a throwaway Docker install, and Hostinger is where I’d start if I were setting this up fresh today)
• The WPCode plugin, free version, for pasting snippets
• Permalinks set to anything except Plain (this one bites people, more below)
• An API key from OpenAI or Anthropic, or Ollama on your own machine if you want to spend nothing
• 30 minutes

What we’re building

A chat bubble in the corner of your site. A visitor clicks it, types a question, and your chosen AI model answers, with your instructions shaping what it says.

Three pieces make that work: a REST route your site exposes, a widget in the page that calls it, and your API key, which never leaves the server.

That diagram is the hardened version. The tutorial version is the same picture with the two gates missing, which is the whole story of this post.

How I tested this for free

I didn’t spend anything building this, and you don’t have to either.

Ollama runs an AI model on your own computer. It installs without sudo, and it exposes an OpenAI-compatible endpoint, meaning the same code that talks to OpenAI talks to it, with only the base URL changed.

ollama list
# qwen2.5:3b-instruct-q4_K_M    357c53fb659c    1.9 GB

In the chatbot settings I pointed the base URL at http://localhost:11434/v1, set the model name, and left the API key field empty:

provider=compatible  base_url=http://ollama:11434/v1
model=qwen2.5:3b-instruct-q4_K_M  key_set=no

That answered in 1.56 seconds on a CPU-only box with no GPU. I timed the model call five more times to be sure: 1.73 seconds median, 1.66 to 1.82 once it’s warm.

One thing that will confuse you if nobody says it: my first request took 6.9 seconds. Ollama loads the model into memory on demand, so the first answer after an idle spell is slow and every one after it isn’t. Don’t judge the setup by that first reply.

You can also just leave it like this. If you run your own VPS, Ollama answers every chat for free, forever, and no API bill ever arrives. That is a real option, not a demo mode.

The catch is honest and worth knowing before you plan around it: this needs a machine you control with a few GB of spare RAM. Normal shared hosting won’t run it, so for most people it’s a VPS or nothing.

Here’s the other honest limit: a 3B model gives visibly weaker answers than GPT-4o or Claude. Test your plumbing locally, then judge answer quality only once you point it at a paid key. And one more thing I’d rather say than hide: my Anthropic adapter was verified against a local Anthropic-shaped mock, not against api.anthropic.com.

Step 1: the PHP snippet (and the trap that eats it)

Do this:

1. Install and activate WPCode from Plugins > Add New.
2. Go to Code Snippets > Add Snippet, choose Add Your Custom Code, and pick PHP Snippet.
3. Paste the PHP in. If you’re using my files, that’s 01-paste-into-wpcode.php.
4. In the right-hand column, set Location to Run Everywhere. This one matters more than it looks.
5. Save, then switch the snippet to Active.

That’s the whole step. The rest of this section is why, and you can skip to Step 2 if you just want the thing working.

What that PHP actually does

It registers a REST route: a URL on your own site that your chat widget can post a question to. Your snippet takes the question, adds your instructions, calls the AI model with your key, and sends the answer back.

The part everyone gets right:

register_rest_route( 'myapi/v1', '/chat-bot/', array(
    'methods'             => 'POST',
    'callback'            => 'handle_chat_bot_request',
    'permission_callback' => '__return_true',
) );

The part almost nobody does:

register_rest_route( 'myapi/v1', '/chat-bot-config', array(
    'methods'  => 'GET',
    'callback' => 'load_chat_bot_base_configuration',
    // no permission_callback at all
) );

WordPress does warn you about that second one. It just sends the warning somewhere you will never look:

curl -s -D - -o /dev/null http://yoursite.test/wp-json/myapi/v1/chat-bot-config

HTTP/1.1 200 OK
X-WP-DoingItWrong: register_rest_route (since 5.5.0; The REST API route definition for
  myapi/v1/chat-bot-config is missing the required permission_callback argument...)

With WP_DEBUG_LOG switched on, debug.log stayed at 0 bytes. Core suppresses that notice on purpose during REST requests, because a PHP warning printed mid-request would corrupt the JSON. Reasonable, but it means the one message telling you your endpoint is unprotected goes into a response header, not your log.

Why that one Location setting decides whether anything works

Skippable if yours already works. Worth reading if it doesn’t, because this is the one I’d never seen written down anywhere and it cost me an afternoon on a real build.

In WPCode, a PHP snippet has a Location. Set it to Frontend Conditional Logic and your REST route is never registered at all. No error, no log line, nothing:

The code was byte-identical in all four runs. Only the location changed.

The reason is in WPCode’s own source: Run Everywhere runs your snippet on plugins_loaded, which fires on every request including REST ones. Frontend Conditional Logic runs on wp, a hook a REST request never reaches. Nothing errors, so nothing logs.

Set the location to Run Everywhere. If your chatbot does nothing at all and your log is empty, check this before you check anything else.

Step 2: the widget

This is the part visitors actually see: the bubble, the panel, and the JavaScript that sends their question to the route you just built.

Do this: three more snippets, each added the same way as Step 1, each set to Active.

Not using WPCode for these? The HTML and JavaScript go in your theme’s footer.php before </body>, and the CSS goes in Appearance > Customise > Additional CSS.

Reload any page on the front end and the launcher appears in the bottom corner.

The endpoint line, and the two ways it goes wrong

The one line to get right is the endpoint, and the mistake to avoid is hardcoding it:

// Don't do this. It's your dev machine, not your visitor's
const apiUrl = 'http://ai-chatbot.local/wp-json/myapi/v1/chat-bot/';

When I left that in, the browser console said net::ERR_NAME_NOT_RESOLVED, then TypeError: Failed to fetch, and the visitor saw a generic error with no clue what happened.

There’s a nastier version of the same mistake. If your site is on HTTPS and your endpoint URL starts with http:// on a real domain, Chrome blocks the request outright:

Mixed Content: The page at 'https://yoursite.com/' was loaded over HTTPS, but requested
an insecure resource 'http://yoursite.com/wp-json/...'. This request has been blocked.

Worth knowing: http://localhost is exempt from that rule, so this never shows up while you’re testing locally. It appears the moment you go live.

Step 3: your API key, not in the snippet

Do this:

1. Get a key. OpenAI keys come from platform.openai.com, Anthropic keys from console.anthropic.com. Running Ollama locally? Skip this step entirely, you don’t need one.
2. Open wp-config.php and add this line above /* That's all, stop editing! */:

define( 'MY_CHATBOT_API_KEY', 'sk-your-key-here' );

1. Save, reload your site, and ask the bot something.

The PHP snippet reads that constant. Don’t paste the key into the snippet itself: a key in a WPCode snippet sits in your database, and in every backup and export of it.

If you got an answer, the build is done. Everything after this is making it yours, and knowing what to do when it breaks.

Make it yours

This is the part most tutorials skip, and it’s the part you’ll actually spend time on. None of it needs a code editor if you’re on the plugin version, and all of it is one CONFIG block if you’re on the snippets.

What it says before anyone types

Three fields, and they’re the three everyone changes first.

• Window title, the heading on the panel. “Ask us anything” beats “Chatbot”.
• First message, what it greets people with.
• Quick replies, the suggestion buttons under that greeting. Two or three, phrased the way a visitor would phrase them, because most people click one of these instead of typing.

In the snippets, those are title, startup_message and quick_replies at the top of the PHP file. In the plugin, they’re the first three boxes on the settings screen.

What it knows about your business

The system prompt is the most important field there is. It’s read on the server on every request, so a visitor can’t overwrite it or talk their way past it.

Here’s the thing nobody tells you, and it surprises everyone: the bot only knows what’s in that box. It does not read your pages, your posts or your products. If you want it answering questions about your prices, put your prices in there.

You answer questions for Example Plumbing in Bristol.
Boiler service £95. Emergency callout £120 plus parts. Bathrooms quoted on site.
Open Mon to Fri 8am to 6pm, Saturday mornings by arrangement, closed Sunday.
We cover Bristol and 20 miles around it.
To book: 0117 000 0000 or the form at /contact.
Answer briefly. If you don't know, say so and point them at the contact form.
Never invent a price.

The cost of that: it’s sent on every single message, so you pay for it every time. A tight prompt is cheaper than a long one, and pasting your whole FAQ in there gets expensive at volume.

Colours

Two values, not a theme editor: an accent colour and the text colour that sits on it. They flow through the launcher, the header and the visitor’s own message bubbles. Pick your brand colour and a text colour that reads clearly on it.

Swapping the model, including to a free local one

The same screen, pointed at two different providers. On the left, a local model through Ollama with the key field empty. On the right, OpenAI with a real key.

Nothing else changes. Not the widget, not the styles, not your prompt. Your visitors see no difference at all, which is what makes “test free locally, then switch to a paid key” a real workflow rather than a slogan.

The settings that control what a bad day costs you

These are the ones worth understanding before you leave it running. Every one is enforced on your server, before the AI model is ever called, so a refused request costs nothing.

When it breaks: 9 symptoms, 9 fixes

Here’s the part no tutorial includes. Every row is something I actually hit in this lab, and most of them are in the screenshots above.

Two things that tripped me up worth calling out. response.ok is not “it worked”. Under Plain permalinks the route returns a perfectly valid 200 carrying an HTML page, and the kit’s JavaScript believes it. And a failing API key, a bad model name and an unresolvable host produce exactly the same “Oops!” with 0 bytes in the log every time.

Common mistakes (and how to avoid them)

• Leaving the route public with no rate limit. Ten unauthenticated requests landed, 10 of 10. Anyone with the URL can spend your API credit.
• Letting the browser send the conversation history. I planted a fake earlier turn saying “My campaign code is TOPAZ-8831” and asked the bot to repeat it. With no history it said “I dont know”. With the injected history it said TOPAZ-8831. The visitor controls what your model is told.
• Trusting the system prompt to keep it on topic. My snippet said “only answer digital marketing questions”. It wrote me a poem about the sea.
• Debugging with WP_DEBUG and expecting a log. For every failure above, the log stayed empty.
• Pasting your key into the snippet. Use wp-config.php.

What you should improve next

Three changes take this from a demo to something I’d leave on a client site.

Check a nonce. Hand the widget a wp_rest nonce and verify it. Give the rejection its own error code so the widget can tell “your token expired” apart from “you’re going too fast”, fetch a fresh one and retry once. That keeps the check working on a cached page.

Add a rate limit, in front of the provider. Mine is a counter in a transient. Six requests against a limit of three gave three 200s, then three 429s, and the refused ones never reached the model, so they cost nothing.

Keep the conversation on the server. Store history in a transient keyed by session id. The browser then sends one message and an id, so it can’t rewrite what the model sees.

After those three, the same abuse test that landed 10 of 10 against the tutorial build landed zero. And when the provider genuinely fails, the visitor gets a neutral sentence while the real cause goes to the log where the owner can read it.

Frequently asked questions

Do I need a plugin for this?
No, and that’s the point of the snippet build. You need WPCode to hold the snippets, but the chatbot itself is your own code, so nothing is hidden from you.

Will it answer questions about my own pages and prices?
Only if you tell it them. It doesn’t read your site. Everything it knows comes from the system prompt field, so your prices, hours and policies have to be typed in there. Searching your actual content is a much bigger build than this one.

How much does it cost to run?
The build costs nothing. Each conversation costs whatever your provider charges per token, and the tutorial version sends the entire history on every turn with no cap, so a long chat gets expensive quietly.

Can I use Claude instead of ChatGPT?
Yes. The request shape differs, so you need a small adapter per provider rather than one function with the URL swapped.

Why does my chatbot say “Oops” with nothing in the log?
Because that one message covers at least five unrelated causes. Start with curl on your route and read the response body, not the status code. The table above maps each body to its cause.

Is it safe to leave the endpoint public?
Not as written. A public endpoint with no nonce and no rate limit is a proxy to your paid API that anyone can drive.

Take the files

Everything in this post, as something you can actually run.

Which one? If you’re comfortable pasting code and want to read every line before it runs on your site, take the snippets. If you’d rather upload a zip, tick some boxes and get on with your day, take the plugin. Both are the hardened build. Neither is a cut-down version of the other.

Wrap-up

An AI chatbot on WordPress is genuinely a 30-minute build. The hard part isn’t getting it talking, it’s the gap between “it answers” and “it’s safe to leave running”. A nonce, a rate limit and server-side history are what close it.

If you’re new to editing site files at all, start with how to edit wp-config.php before you touch anything else.

If you get stuck on any of this, come and ask me in my Discord. I’d rather answer a question there than have you give up on it.

The post How to Add an AI Chatbot to WordPress (No Plugin Needed) appeared first on The Beginner’s Playbook for Fixing WordPress Errors.

So this time I built another one the same way, and before I touched a single line myself, I ran WordPress.org’s own security scanner against it. Then I went further, because a warning list isn’t proof of anything: I tried to actually break the thing.

Here’s the short version: the official tool found 21 issues. Two rounds of fixes took that to zero.

And the one bug I could actually exploit for real was never on that list at all.

What You Need

Everything here is free and runs on your own machine.

• A terminal-based AI coding assistant — I used Claude Code, but the method works with any of them
• A local WordPress install — Docker, LocalWP, whatever you already use
• WordPress Plugin Check — WordPress.org’s own scanner, install it like any plugin: wp plugin install plugin-check --activate
• About fifteen minutes, which I’ll come back to

The plugin, and why I picked this one

I asked the assistant for a “Was this helpful?” widget: Yes/No buttons under a post, votes stored in the database, a summary on an admin page. Nothing exotic.

I picked it on purpose. It touches every place a beginner plugin usually gets hurt: an AJAX endpoint anyone can hit without logging in, a database table the plugin owns, an admin page only the site owner should see, and a settings form an admin can change. Four different attack surfaces in maybe eighty lines of real logic — dense enough to be worth checking, small enough to actually finish checking in one sitting.

Compare that to what most “build a plugin with AI” tutorials show you: a shortcode that prints some text, or a widget that reads an option. Those genuinely have nothing to attack. This one does, and that’s exactly why it’s the more honest test.

The prompt I actually used had no security words in it anywhere — no “secure,” no “sanitize,” no “nonce.” Just what I wanted it to do. That’s the point: I wanted the default, not the graded version.

One honest caveat before anything else: the assistant that wrote this plugin is the same tool I use every day, tested by an isolated instance that had no idea an audit was coming. I’m not claiming a blind test — I’m claiming a single-blind one, and I’d rather tell you that than pretend otherwise.

AI generated WordPress plugin security: what Plugin Check actually said

I ran wp plugin check — WordPress Plugin Check, the tool WordPress.org uses to review real plugin submissions — against the first thing the assistant handed back.

21 findings: 2 errors, 19 warnings. And here’s the part that actually surprised me: zero nonce problems, zero missing capability checks, zero unescaped output. The code checked its nonce. It called wp_unslash() before sanitizing input, which is the exact mistake I’ve personally shipped before. It gated both admin pages behind current_user_can('manage_options').

What Plugin Check actually flagged was almost entirely one pattern, repeated: SQL built with {$table} and {$column} dropped straight into the query string instead of going through $wpdb->prepare() properly, plus a missing readme file and an outdated plugin header. Real findings — just not the ones I expected.

Which of those findings can actually hurt you?

This is the part nobody else checks. A tool telling you something is unsafe and something actually being unsafe are two different claims, and only one of them is provable.

So I logged in as a real WordPress user, grabbed a live nonce off the actual page, and fired six real requests at the running plugin — the same way an attacker, or just a careless script, would. Not curl commands typed by hand and eyeballed — a script that checks what actually landed in the database afterward, because a request that returns a friendly JSON response and a request that actually stored something are not the same event. I’ve been burned by that gap before: a tool I built once looked like it was working in every test, right up until someone checked whether the database row it claimed to write was actually there.

• No nonce at all. Rejected. The check held.
• A script tag as the vote value, trying for stored XSS. Rejected — the vote only ever accepts “yes” or “no,” so there was nothing to inject into.
• 1 OR 1=1 as the post ID, going for SQL injection. Rejected — absint() turned it into a plain integer before it ever reached the query.
• A Subscriber account with a genuinely valid session, trying the admin page directly. Blocked. A valid login proves who you are, not what you’re allowed to do — and the capability check actually enforced that.
• A quoted value, testing whether wp_unslash() was handled correctly. It was.

Five attacks, five failures. Plugin Check’s flagged SQL pattern — the raw {$table} interpolation — turned out to be exactly what it looked like: untidy, not exploitable. Every value going into those queries was already a validated integer or one of two hardcoded strings before the SQL ever ran.

One attack worked, and it wasn’t on Plugin Check’s list, or PHPCS’s, or PHPStan’s.

The comparison table

Fourteen is the honest number, not the raw one — Plugin Check and PHPCS flagged the same eight lines, just twice each, once per tool. I checked file-and-line for overlap rather than just adding the totals, because reporting 38 would have been a real number technically, and a misleading one in practice.

Does a nonce make my AJAX endpoint safe?

No — and this plugin proves both halves of that sentence.

The nonce genuinely stopped forged requests. What it doesn’t stop is the same valid request, repeated.

I wrote a tiny script that pulled a real nonce off the page and voted “Yes” twenty times in a row. The database accepted every single one — the count went from 1 to 21. The only thing standing between a visitor and unlimited votes was a note in the browser’s local storage, which a script simply doesn’t have.

That’s not a nonce failure. It’s a missing-rate-limit failure, and it’s invisible to every tool I ran, because none of them ask “what happens if this exact request runs a thousand times?”

How long does it take to get it actually clean?

I fed Plugin Check’s own output straight back to a fresh assistant session — the real 21-line report, not my summary of it — and asked it to fix every finding.

Round one: 21 → 2. It rewrote every SQL call to use WordPress 6.2’s %i placeholder correctly, added real object caching, and wrote a readme file that hadn’t existed. That readme immediately introduced two new findings of its own — an outdated “tested up to” version and a description that ran over the character limit.

Round two: 2 → 0, fixing exactly those two lines.

Two rounds. Roughly nine minutes total, timed for real rather than guessed at. And the vote-stuffing bug was still sitting there afterward, completely untouched — because getting Plugin Check to say “no errors found” was never the same question as “is this actually safe.”

Common Mistakes

Trusting “it works” as your only test. My own plugin from last year still has no security section written about it anywhere. It works. That was never the same claim as safe.

Auditing AI code with the same AI that wrote it. Asking the assistant to grade its own homework tells you what it believes about its own work, not what’s actually true. Use the tool the WordPress plugin reviewers actually use.

Treating a clean linter run as the finish line. Twenty-one violations really did go to zero. The one exploitable bug was never touched by that process, at any point, because static analysis reads code — it doesn’t run it against the questions that actually matter, like “what if someone sends this exact same request 500 times?”

Skipping wp_unslash() before sanitizing input. I’ve personally shipped this exact bug before. This plugin got it right on the first attempt, which is worth noticing precisely because it’s the mistake that’s easiest to make and hardest to catch by reading.

FAQ

Is AI generated code secure? WordPress builders keep assuming yes.
This one held against five of six real attacks — no nonce, XSS, SQL injection, missing capability checks. It did have one real gap: unlimited vote stuffing. Test your own before you trust “it works.”

What does Plugin Check actually test?
Coding standards, security patterns like unescaped output and unprepared SQL, and WordPress.org submission requirements. It’s static analysis — it reads your code, it doesn’t run it against real requests.

Does a valid nonce mean a request is safe?
It means the request came from an active session on your site. It says nothing about what that account is allowed to do, and nothing about how many times the exact same valid request gets repeated.

How long does it really take to build WordPress plugin with AI?
About four minutes to a working install, about nine to a Plugin-Check-clean one — both timed, not estimated. Getting to actually secure took a sixth check no automated tool ran.

Can I run these checks on my own plugin?
Yes — that’s the actual point of this piece. wp plugin check <your-plugin> costs nothing and takes under a minute. Every script and prompt behind this piece is published; run them against your own plugin and see what comes back.

What’s the actual fix for the vote-stuffing bug?
Track votes server-side per visitor instead of trusting the browser. A signed cookie, an IP-plus-post-ID row in the votes table, or a rate limit on the AJAX action itself would all close it. I haven’t shipped that fix here on purpose — the point of this piece is what the audit found, not a finished, hardened plugin.

So what do you actually do with this?

Run Plugin Check on whatever AI-generated code is already live on your site. It’s free, it’s the same tool plugin reviewers use, and it takes less time than reading this post.

Then go further than the tool does. Ask what happens if a valid request gets repeated. Ask whether a valid login actually proves permission, not just identity.

Those are the questions that catch what static analysis structurally can’t — because they’re about behavior, not patterns in the source.

Twenty-one violations reaching zero is a real, checkable win. It just isn’t the same win as “this plugin is secure.” Only one of those two claims was true here, and the tool that would have told you which one never got asked the question.

If you haven’t built your first AI-generated plugin yet, start here — then come back and run this checklist on it.

The post AI Generated WordPress Plugin Security, Tested for Real appeared first on The Beginner’s Playbook for Fixing WordPress Errors.

What I found was a table. One top-ranking guide publishes time-to-first-byte figures — 200 to 800 milliseconds for WordPress, 20 to 100 for static — and never says what hardware it ran on, what page it requested, what tool it used, or how many times it tried.

That is a range wide enough to be right no matter what happens — and Google’s AI summary already repeats those numbers back to me as fact.

So I stopped reading and built all three stacks on one machine at home, measured them with scripts I’m publishing, and got an answer that surprised me.

The short version: static beat WordPress by 96×. Then I turned caching on, and the gap collapsed to 0.08 milliseconds.

What You Need

Everything runs on one Linux machine with Docker. No cloud account, no card, nothing to sign up for.

• Docker and Docker Compose — the whole lab is containers
• WordPress 6.5, MariaDB 11, nginx 1.27 — official images
• Hugo 0.128.0 (extended) — for the build-time test
• wrk and wget — load generator and export tool
• About an hour, most of it waiting

Mine ran in a throwaway container on an Ubuntu Optiplex in my house — which is why I’m careful below about which numbers I’ll stand behind.

The setup: four doors into one WordPress site

Benchmark WordPress on one machine and a static site on another, with different themes and different content, and you haven’t compared platforms — you’ve compared two different websites. That’s why most of these numbers don’t mean much.

So I ran one WordPress install with 200 identical posts, behind four nginx server blocks:

For WordPress vs static HTML to mean anything, both sides need the same HTML — so the static side is a wget mirror of the WordPress site, not a separately-built Hugo one. That’s deliberate: it makes the HTML byte-identical.

A, B and A′ returned the same md5. C differed by 165 bytes — wget rewriting absolute URLs to relative ones, and nothing else.

So any speed difference belongs to the serving path. Not the theme, not the content, not the page size.

The control that makes the rest trustworthy

A′ is the important one, and no comparison I read had anything like it.

It’s the same stack as A, same PHP-FPM pool, identical config. It is A. If my measurements are any good the two must come out the same — and if they don’t, my machine is too noisy and every other number here is garbage.

I ran it first, 160 rounds, alternating which went first:

A  median TTFB   33.6958 ms
A' median TTFB   33.6912 ms
ratio            0.9999   (drift 0.01%)
gap              0.0047 ms   against an IQR of 0.75 ms

The two identical stacks landed 0.01% apart — under one percent of the ordinary jitter. That’s the receipt that lets me report everything else.

This is the check to demand from anyone showing you a benchmark. If they can’t tell two identical things apart, they can’t tell two different things apart either.

WordPress vs static site: is static actually faster?

Every static site vs WordPress speed claim you have read starts here, and this part is true: enormously faster — against WordPress with no caching.

I hit each stack 185 times, rotating the order every round so a busy moment on my machine couldn’t land on one stack and stay there.

Ninety-six times. That’s the number that sells the switch, and it’s real. It’s also the wrong comparison.

What happens when WordPress is properly cached

Look at the middle row again. Cached WordPress is 78× faster than uncached WordPress — and it’s the same WordPress. Same plugins, same theme, same database.

The only change is nginx keeping the finished HTML and handing it out instead of waking PHP.

Which puts static at 1.23× faster than cached WordPress. Not 96×. Not 10×.

In absolute terms that’s 0.082 milliseconds.

What does 0.082ms mean in practice? It is three orders of magnitude smaller than the time a packet takes to reach your server and come back. It vanishes into the noise of the internet before the page starts rendering.

Every guide comparing static to WordPress compares it to the uncached configuration. Nobody runs an uncached WordPress site on purpose.

Does it hold up when people arrive at once?

One visitor at a time is the easy case. I pushed 1, 10 and 50 concurrent connections at each stack, three runs each.

Uncached WordPress hits a wall at about 130 requests per second and stays there — PHP-FPM’s default of five worker processes. Five requests at a time, no matter how many people show up.

Cached WordPress and static both keep climbing, and stay within about 16% of each other all the way up. Zero failed responses anywhere, on any stack.

The honest headline isn’t “static is faster than WordPress”. It’s that caching is faster than not caching, by 78× — and static adds a rounding error on top.

The comparison table

Everything I measured, in one place:

Two rows deserve a second look, because they’re the ones that actually decide this.

Memory is where static wins properly. WordPress needs MariaDB, PHP-FPM and nginx — 463.9 MiB with traffic on it. Static needs nginx alone: 38.6 MiB.

That’s 12× less memory and 6× less disk, and unlike the speed difference it isn’t a rounding error. It’s the gap between DigitalOcean’s $4/month 512 MB droplet and the $6/month 1 GB one — a real, if modest, $24 a year.

And that “8 of 16” row is not static being lighter. I’ll get to it.

Does publishing get slower as your blog grows?

This is the static site generator vs WordPress question I actually wanted answered, and the one nobody measures. The only person I found writing about it was a developer in 2021 whose workflow fell apart as his archive grew — a good post, with no numbers in it.

So I measured the cost of publishing one more post at three archive sizes.

Both camps are a little wrong.

Static defenders are wrong that build time is nothing. Multiply the archive by 100 and the rebuild takes 7.4× longer. That curve is real and keeps going.

The 2021 post is wrong that it falls apart. At a thousand posts, a full rebuild takes 296 milliseconds. A third of a second. If you publish weekly, you will not notice this in your lifetime.

WordPress stays flat — 33 ms at a thousand posts, statistically identical to 35 ms at ten — because publishing is one database insert regardless of how much you’ve already written.

So the authoring-loop objection is directionally true and practically irrelevant at blog scale. Revisit it at 50,000 pages; under a few thousand it’s a non-issue.

What actually breaks when you go static

Here’s where the piece changed my mind.

I put the three things a normal blog has onto the WordPress site — a contact form, site search, comments — exported it the way someone without a paid plugin would, with wget, then tried every feature against the export.

Five of six were broken.

Search made me sit up. On the export, /?s=fixture returns HTTP 200 — not a 404, a completely normal successful response. A static server has no idea what ?s= means, so it ignores it and hands back the homepage.

My first version of this test checked status codes only, and told me “site search: still works.” It does not. I had to compare the page bodies to catch it — and if I’d trusted the status code, I’d have published the opposite of the truth.

And the contact page is worse, because it looks completely fine:

That’s the exported site. Name, email, subject, message, Submit — and a visitor who fills it in, hits the button, and 404s into nothing.

You don’t get an error report, because nothing looks broken. You just stop hearing from people.

This also explains the “8 of 16 assets” row above. The static page isn’t 90KB lighter because it’s leaner — it’s lighter because six files it asks for aren’t there, including the block-navigation CSS and JavaScript.

Common Mistakes

Benchmarking WordPress with caching off. This is the big one. Every “static is 10× faster” claim I could find compares against a configuration nobody deploys. Turn on page caching and you recover 78× of the 96×.

Trusting a static site vs WordPress speed table with no method attached. If it won’t tell you the hardware, the tool, the page and the number of runs — and shows no spread around its figures — it’s a guess with decimal points.

Costing the hosting but not the workflow. The $2/month you save is real. So is the afternoon spent rebuilding your contact form on a third-party service, and every future post going through a build step instead of a Publish button.

Assuming an export keeps things working. It doesn’t, and it fails quietly. Go static deliberately — pick a forms service, pick a search service (or drop search), pick a comments host. Don’t export a dynamic site and hope.

What I’m not claiming

My lab was a container on a home Optiplex that also runs my other work. That is not clean benchmark hardware and I won’t pretend otherwise.

So I claim the ratios between stacks, not the absolute milliseconds. Every stack was measured in the same rounds, in rotating order, minutes apart, and the null control resolved identical stacks to 0.01%.

Under those conditions “static is 1.23× cached WordPress” is solid. “Static serves in 0.35ms” is true of my box and nothing else.

I’m also not claiming anything about SEO — everyone asserts static ranks better, and I can’t test it in an afternoon. I didn’t test managed WordPress hosting or Netlify’s free tier either. Different question, different piece.

FAQ

Is a static site faster than WordPress?
On WordPress vs static HTML, against uncached WordPress, yes — 96× on my measurements. Against WordPress with nginx page caching, 1.23×, which is 0.08 milliseconds. On a real connection that difference is invisible.

Is a static site worth it for a blog I update weekly?
For speed alone, no — caching gets you within a rounding error. For a lower bill and less to maintain, maybe: 12× less memory and no database to patch.

Will my contact form work after converting to static?
No. Mine returned 404 while still displaying a perfectly normal form. If you go static you need a forms service, and you need to know that before you migrate, not after.

Can I keep WordPress and get static speed?
Largely, yes — that’s the finding. Full-page caching took the same WordPress install from 33.70 ms to 0.432 ms without changing a single plugin or theme file. It’s the cheapest performance work available to you.

How much does each one actually cost to host?
Static fits DigitalOcean’s $4/month 512 MB droplet; WordPress needs the $6/month 1 GB tier at minimum. Around $24 a year, before you count your own time.

What about search on a static site?
Site search stops working and does it silently — HTTP 200, homepage returned. You’d need a client-side index or a hosted search service.

So which should you build?

Here’s the rule I’d give a friend, and it isn’t the one I expected to write.

If your site has forms, comments, search, or anything a visitor submits — stay on WordPress and turn on full-page caching. That one change bought 78× on my measurements.

You keep everything that works, and the remaining gap is a fraction of a millisecond nobody will perceive.

Reach for a static site generator vs WordPress only when your site genuinely has nothing dynamic in it — a portfolio, documentation, a landing page, an archive that only you update. Then you get real wins: 12× less memory, a cheaper box, no database to keep patched, and nothing to break at 3am.

What should not decide it is a speed table with no method behind it. The 96× is real and it’s measuring the wrong thing.

If you take one thing from this: go and turn caching on. It’s free, it takes an afternoon, and it’s most of the benefit people switch platforms for. You might try it before you rebuild anything.

Every script and raw measurement behind this post is published — the null control, the timing harness, the export probes, all of it.

Run them on your own box and tell me if you get something different. I’d genuinely like to know.

Related: How I Connected WordPress to Claude AI With an MCP Server

The post WordPress vs Static Site: I Measured Both, Here’s the Truth appeared first on The Beginner’s Playbook for Fixing WordPress Errors.

But it’s also the file that scares people the most. One wrong edit, and your site can go completely blank.

That’s exactly why I wrote this guide. I’ll show you how to safely find, access, and edit the wp-config.php file — even if you’ve never touched code before. Plus, I’ll share the exact tweaks I use on every site I build.

Let’s dive in.

What is the wp-config.php File? (And Why It Matters)

The wp-config.php file is WordPress’s main configuration file. Think of it as the bridge between your WordPress software and your database.

Without this file, WordPress can’t:

• Connect to your database
• Load your content
• Authenticate users
• Run your site

Here’s what it controls:

• Database connection details (name, username, password, host)
• Security keys and salts (protects against hackers)
• Debug mode settings (shows errors for troubleshooting)
• Memory limits (prevents crashes from resource-heavy plugins)
• Table prefix (adds security layer to your database)

The file gets created automatically when you install WordPress. But knowing how to edit it gives you total control over your site’s behaviour.

Note: I’ve edited wp-config.php hundreds of times over the years. It’s intimidating at first, but once you understand the basics, it becomes one of your most powerful troubleshooting tools. Just always — and I mean ALWAYS — backup first.

Where to Find the wp-config.php File

The wp-config.php file lives in your WordPress root directory. Depending on your hosting setup, this folder is usually called:

• public_html
• www
• htdocs
• Your domain name (e.g., example.com)

You can access this file three ways:

Method 1: File Manager (cPanel)

This is the easiest method if your host uses cPanel.

1. Log in to your hosting cPanel
2. Navigate to Files → File Manager
3. Open the public_html folder (or your site’s root folder)
4. Scroll down until you see wp-config.php
5. Right-click and select Edit

A warning will pop up about editing code. Click Edit again to proceed.

Method 2: FTP Client (FileZilla)

If you prefer FTP access or don’t have cPanel:

1. Download and install FileZilla (it’s free)
2. Get your FTP credentials from your hosting provider
3. Connect to your server using FileZilla
4. Navigate to your WordPress root directory
5. Right-click wp-config.php and select View/Edit

FileZilla will open the file in your default text editor. Make changes, save, and FileZilla will upload the updated file automatically.

Method 3: SSH Terminal (Advanced)

For those comfortable with the command line:

cd /path/to/your/wordpress/
nano wp-config.php

Make your edits, then press Ctrl + X, then Y, then Enter to save.

Pro Tip: On localhost setups like XAMPP or Local by Flywheel, navigate to xampp/htdocs/your-site-folder or wherever your local WordPress installation lives.

CRITICAL: Always Back Up Before Editing

Before you touch wp-config.php, create a backup. This isn’t optional.

If you make a mistake, your entire site can go down instantly. Here’s why:

• One missing semicolon = site crash
• Wrong database password = database connection error
• Incorrect syntax = white screen of death

How to back up wp-config.php:

Option 1: Download via FTP

• Right-click the file in FileZilla
• Select Download
• Save it to your computer as wp-config-backup.php

Option 2: Duplicate via File Manager

• Right-click wp-config.php
• Select Copy
• Name the copy wp-config-backup.php

Option 3: Full Site Backup If your hosting has automatic backups (like Cloudways or WP Engine), create a manual backup before editing anything critical.

My Reality Check: I learned this lesson the hard way. A few years ago, I edited wp-config.php without backing up first. I mistyped one character, hit save, and the entire site went blank. Took me 2 hours to figure out what went wrong. Now I back up every single time — no exceptions.

Understanding the wp-config.php File Structure

Let’s break down the main sections you’ll see when you open wp-config.php.

1. Database Settings

This section connects WordPress to your MySQL database:

// ** MySQL settings ** //
define( 'DB_NAME', 'your_database_name' );
define( 'DB_USER', 'your_database_username' );
define( 'DB_PASSWORD', 'your_database_password' );
define( 'DB_HOST', 'localhost' );

When you’d change this:

• Moving to a new host
• Fixing “Error Establishing Database Connection”
• Restoring from backup with different database credentials

2. Authentication Keys and Salts

These are random strings that encrypt your login cookies:

define('AUTH_KEY',         'put your unique phrase here');
define('SECURE_AUTH_KEY',  'put your unique phrase here');
define('LOGGED_IN_KEY',    'put your unique phrase here');
define('NONCE_KEY',        'put your unique phrase here');
define('AUTH_SALT',        'put your unique phrase here');
define('SECURE_AUTH_SALT', 'put your unique phrase here');
define('LOGGED_IN_SALT',   'put your unique phrase here');
define('NONCE_SALT',       'put your unique phrase here');

When you’d change this:

• After your site gets hacked
• As part of regular security maintenance (every 6-12 months)

How to generate new keys: Visit the WordPress.org Secret Key Generator and copy-paste the generated keys into your file.

3. Database Table Prefix

$table_prefix = 'wp_';

The default is wp_, but you can change it to add a security layer:

$table_prefix = 'wp_a7x9_';

Warning: Only change this during initial setup. Changing it on an existing site requires updating your entire database structure.

4. Debug Mode (Turned Off by Default)

define( 'WP_DEBUG', false );

This controls whether WordPress displays errors on your screen.

5 Essential wp-config.php Edits Every WordPress User Should Know

Now let’s get into the practical stuff. These are the most common edits I make on WordPress sites.

Edit #1: Enable Debug Mode (Troubleshooting Errors)

When something breaks on your site but you can’t see what’s wrong, enable debug mode.

Find this line:

define( 'WP_DEBUG', false );

Change it to:

define( 'WP_DEBUG', true );

What this does:

• Shows PHP errors, warnings, and notices on your screen
• Helps identify plugin conflicts
• Reveals theme issues

Save the file, then visit your site. You’ll now see error messages that were previously hidden.

Important: Turn debug mode OFF once you’ve fixed the issue. Leaving it on exposes sensitive information to visitors and slows down your site.

Bonus: Log Errors to a File Instead If you don’t want errors displayed publicly, log them to a file:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

This creates a debug.log file in /wp-content/ with all errors recorded privately.

My Tip: I always use the log file method on live sites. It lets me troubleshoot without exposing errors to visitors. Check the WordPress Enable Error Log guide for more details.

Edit #2: Increase WordPress Memory Limit (Fix “Memory Exhausted” Errors)

If you see errors like “Fatal error: Allowed memory size exhausted,” your site is running out of PHP memory.

Add this line before “That’s all, stop editing”:

define( 'WP_MEMORY_LIMIT', '256M' );

What this does:

• Increases PHP memory from the default 40MB to 256MB
• Prevents crashes from resource-heavy plugins
• Allows larger image uploads

You can try 128M first and increase if needed. Most shared hosting plans allow up to 256M or 512M.

Why this happens: Page builders, e-commerce plugins, and image-heavy sites consume lots of memory. This edit gives WordPress more room to work.

For more context on fixing memory issues, check out How to Fix WordPress Memory Size Exhausted.

Edit #3: Change Database Table Prefix (Security Enhancement)

Hackers know the default database prefix is wp_, making it easier to target your tables with SQL injection attacks.

During initial setup, change this:

$table_prefix = 'wp_';

To something random like:

$table_prefix = 'wp_secure2024_';

Only use letters, numbers, and underscores. No special characters.

CRITICAL WARNING: Do NOT change this on an existing site unless you also update every table name in your database via phpMyAdmin. One mistake will break your entire site.

Edit #4: Regenerate Security Keys (After a Hack)

If your site was hacked or you suspect unauthorized access, regenerate your security keys immediately.

Step 1: Visit WordPress.org Secret Key Generator

Step 2: Copy all 8 generated lines

Step 3: Find the authentication section in wp-config.php and replace the existing keys with the new ones:

define('AUTH_KEY',         'new-unique-key-here');
define('SECURE_AUTH_KEY',  'new-unique-key-here');
// ... (replace all 8 lines)

What this does:

• Logs out all users immediately (including hackers)
• Forces everyone to log in again with fresh, encrypted sessions

Dimu’s Security Practice: I regenerate these keys every 6 months as preventive maintenance. Takes 2 minutes and significantly reduces security risks.

For more security hardening tips, see Understanding SSL, HTTP, and HTTPS.

Edit #5: Disable Automatic Updates (Optional)

WordPress auto-updates for security by default. But if you want manual control:

Add this line:

define( 'AUTOMATIC_UPDATER_DISABLED', true );

When you’d do this:

• You prefer testing updates on staging first
• You manage updates manually via WP-CLI or hosting tools
• You have a managed WordPress host that handles updates

Important: Only disable this if you have a reliable update system in place. Security updates protect against known vulnerabilities.

Advanced wp-config.php Tweaks (For Developers)

These are more technical edits that solve specific problems.

Disable Post Revisions (Save Database Space)

WordPress saves every edit as a revision. On large sites, this bloats your database.

Disable completely:

define( 'WP_POST_REVISIONS', false );

Or limit to 5 revisions:

define( 'WP_POST_REVISIONS', 5 );

Change Autosave Interval

Default is 60 seconds. Increase to reduce server load:

define( 'AUTOSAVE_INTERVAL', 300 ); // 5 minutes

Increase Upload File Size Limit

If you need to upload large files:

@ini_set( 'upload_max_size' , '64M' );
@ini_set( 'post_max_size', '64M');
@ini_set( 'max_execution_time', '300' );

Force SSL for Admin Area

define( 'FORCE_SSL_ADMIN', true );

This forces HTTPS for your WordPress admin login and dashboard. For full SSL setup, read Understanding SSL and HTTPS for WordPress.

Move wp-content Directory (Security)

Advanced users can move the wp-content folder to a custom location:

define( 'WP_CONTENT_DIR', '/path/to/new/wp-content' );
define( 'WP_CONTENT_URL', 'https://example.com/new-content' );

Common wp-config.php Errors and How to Fix Them

Error: “Error Establishing a Database Connection”

Cause: Wrong database credentials in wp-config.php

Fix:

1. Check your database name, username, and password
2. Verify with your hosting provider
3. Try changing DB_HOST from localhost to 127.0.0.1

For a complete guide, see Resolving Database Connection Errors.

Error: “White Screen of Death”

Cause: Syntax error in wp-config.php (missing semicolon, quote, etc.)

Fix:

1. Restore your backup immediately
2. Check every line you edited for typos
3. Use a code validator to check syntax

Full troubleshooting guide: Fix WordPress White Screen of Death.

Error: “500 Internal Server Error” After Editing

Cause: PHP syntax error or permission issue

Fix:

1. Revert to your backup
2. Check file permissions (should be 644 for wp-config.php)
3. Review the exact line you changed

More details: Fixing HTTP Error 500 in WordPress.

Best Practices for Editing wp-config.php Safely

After 15 years of working with WordPress, here’s what I’ve learned:

DO:

• Always back up before editing
• Use a plain text editor (Notepad++, Sublime Text, VS Code)
• Test changes on a staging site first
• Document what you changed and why
• Keep your backup file outside the web root

DON’T:

• Never use Microsoft Word or Google Docs (they add hidden formatting)
• Don’t edit directly on a live site without backup
• Don’t share your wp-config.php file publicly (contains database passwords)
• Never leave debug mode enabled on production sites
• Don’t change table prefix on existing sites without database updates

My Workflow:

1. Download the current wp-config.php via FTP
2. Save as wp-config-backup-[DATE].php on my computer
3. Make edits in a local text editor
4. Test the syntax in a code validator
5. Upload to staging site first
6. If everything works, upload to live site
7. Immediately check if site loads properly

Quick Reference: wp-config.php File Location

Shared Hosting (cPanel): public_html/wp-config.php

VPS/Dedicated Server: /var/www/html/wp-config.php /home/username/public_html/wp-config.php

Localhost (XAMPP): C:/xampp/htdocs/your-site/wp-config.php

Localhost (MAMP): /Applications/MAMP/htdocs/your-site/wp-config.php

Localhost (Local by Flywheel): ~/Local Sites/your-site/app/public/wp-config.php

Wrapping Up: Your wp-config.php Cheat Sheet

The wp-config.php file is one of the most powerful files in WordPress. It’s your direct line to:

• Troubleshooting critical errors with debug mode
• Boosting security by changing database prefixes and regenerating keys
• Improving performance by increasing memory limits
• Controlling WordPress behavior at the core level

Key takeaways:

1. Always backup first — One wrong character can crash your site
2. Use debug mode for troubleshooting — It reveals hidden errors instantly
3. Regenerate security keys regularly — Simple 2-minute security boost
4. Increase memory limits if needed — Fixes “memory exhausted” errors
5. Turn off debug mode when done — Never leave it on in production

Dimu’s Final Tip: Bookmark this guide. You won’t edit wp-config.php often, but when you need to, having a trusted reference makes all the difference. I still reference my own notes before making changes — even after 15 years.

Need more help with WordPress errors? Check out:

• How to Clear Cache in WordPress
• Fix the 404 Error in WordPress
• WordPress 500 Internal Server Error
• Use AI to Detect WordPress Errors

Or try the WP Error Expert tool for AI-powered WordPress error analysis.

Have questions about editing wp-config.php? Drop a comment below. I personally respond to every question because I remember what it was like learning this stuff. We’re all in this together.

Frequently Asked Questions (FAQs)

Can I delete the wp-config.php file?

No. Deleting wp-config.php will completely break your WordPress site. WordPress needs this file to connect to the database. If it’s missing, you’ll see the WordPress installation screen instead of your site.

Where is the wp-config.php file located in WordPress?

The wp-config.php file is in your WordPress root directory, usually public_html or www. Access it via FTP, File Manager (cPanel), or SSH terminal.

What happens if I edit wp-config.php wrong?

If you make a syntax error, your site will likely show a white screen, “Error Establishing Database Connection,” or 500 Internal Server Error. This is why backing up before editing is critical — you can restore the working version immediately.

Is it safe to edit wp-config.php?

Yes, as long as you follow best practices: backup first, use a plain text editor, avoid Microsoft Word or Google Docs, test on staging first, and document your changes. Thousands of WordPress developers edit this file daily without issues.

How do I enable debug mode in WordPress?

Open wp-config.php and change define( 'WP_DEBUG', false ); to define( 'WP_DEBUG', true );. This displays PHP errors on your site. Turn it off after troubleshooting by changing it back to false.

Can I edit wp-config.php from WordPress dashboard?

No. WordPress intentionally does not allow editing wp-config.php from the dashboard because one mistake could lock you out completely. You must access it via FTP, File Manager, or SSH.

What are WordPress security keys and salts?

Security keys and salts are random strings in wp-config.php that encrypt your login cookies. They protect against session hijacking and brute force attacks. Regenerate them regularly for better security using the WordPress.org key generator.

How do I increase the WordPress memory limit?

Add this line to wp-config.php before “That’s all, stop editing”: define( 'WP_MEMORY_LIMIT', '256M' );. This increases memory from 40MB to 256MB and prevents “memory exhausted” errors.

The post How to Edit wp-config.php File in WordPress: Complete Beginner’s Guide (Security, Debug & Performance) appeared first on The Beginner’s Playbook for Fixing WordPress Errors.