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.

Four invoices landed in my inbox the same week: Vercel, Sentry, Plausible, Better Stack. Added up, they came to $152 a month, just to host an app, know when it broke, see who visited, and get a ping if it went down.

None of those jobs are hard. They’re just scattered across four different companies, each charging you separately for the privilege.

So I moved all four onto one box. A $5/mo VPS, one install command, one binary doing all four jobs. Here’s exactly what that looks like, with the real thing actually running: not a feature comparison, not a pricing page screenshot.

What You Need

• A VPS with 1-2 vCPU and 2-8GB RAM (I used a $5/mo box, Ubuntu 24.04 LTS)
• SSH access to that box
• A domain, if you want a real custom URL (not required to follow along)
• Five minutes: the install really is one command

I run my whole setup on a Contabo VPS, solid price for what you get, and it’s what this whole post is built on.

The $152/mo Problem, Priced Out

Here’s what four separate “it’s just $20/mo” subscriptions actually add up to:

Each one, on its own, sounds reasonable. Stacked, it’s real money for four things that don’t individually need a dedicated company behind them.

Why One $5 Box Actually Holds Up Here

I’ll be straight with you: “run your whole stack on one cheap box” is a claim I’ve measured being wrong before. A different self-hosted stack I tested, Coolify plus Postal plus Mautic plus WordPress, needed real RAM minimums that added up fast. Coolify alone wants 2 cores and 2GB before you’ve deployed anything. Postal’s own docs recommend 8GB on its own, because it runs MariaDB and RabbitMQ next to its web and worker processes. Stack those together and you’re looking at two boxes, not one, closer to $15/mo than the $4/mo the pitch usually promises.

This is a different situation, and I didn’t want to just assume it was different because the marketing said so. The tool I used, Temps, a single self-hosted Rust binary, states its own idle footprint at around 50MB of RAM on its own homepage. That’s genuinely light, not a marketing rounding error, because it’s one purpose-built binary doing these four jobs natively, instead of four separate open-source apps glued together on the same box, each with its own database, its own worker process, its own idea of how much RAM is “normal.”

I went looking for that number specifically because I’d been burned assuming a lightweight-sounding pitch would hold up without checking. It’s worth doing that check yourself on any tool before you commit a VPS tier to it. The resource page is usually one search away, and it’s a lot cheaper to read than to discover you need a bigger box halfway through setup.

Why not just run the individual open-source alternatives?

You could. GlitchTip (Sentry-API-compatible) and Umami (a clean Plausible-style dashboard) are both solid, genuinely open-source options if you only need to replace one piece. I looked at going that route instead of an all-in-one tool, and the honest answer is: it works, but you’re back to running multiple separate apps, each with its own database and its own update cycle, even if each one individually is light. The appeal of Temps specifically is that it’s one binary, one install, one thing to keep patched, not that the individual alternatives are bad.

Setting It Up

SSH into a clean Ubuntu box and run one command:

curl -fsSL https://temps.sh/deploy.sh | bash

That’s it. No dashboard sign-up first, no credit card, no multi-step wizard before you see anything. The installer provisions Docker, a time-series database, and a Pingora-based proxy (the same proxy engine Cloudflare runs) automatically.

Once it finishes, you register your admin account and you’re deploying. No signup form, no credit card, no email verification loop before you can see the dashboard: the install script is genuinely the whole onboarding.

What you should see once it’s done: a confirmation that default roles were initialized, an admin user created, and a preview domain assigned automatically (Temps hands you a working subdomain immediately, so you’re not stuck configuring DNS before you can test anything). If any of those three lines don’t show up, something in the install failed silently. Re-run the script before moving on rather than troubleshooting forward from a broken base.

Block 1: Hosting (replaces Vercel, $20/mo)

Point your domain at the box, connect a repo, deploy. Here’s the real thing, actually live, not a staged screenshot:

That’s observability-starter, genuinely running on my own box, answering real requests.

Block 2: Error Tracking (replaces Sentry, $29/mo)

Temps accepts your app’s existing Sentry SDK. You point its DSN at your Temps instance instead of Sentry’s servers, and your error reporting code doesn’t change.

I didn’t just take that on faith. I threw a real error on purpose and watched it get caught:

That’s a genuine HTTP 500 from a real endpoint, and the app’s own log line telling you exactly where to go look for it.

Block 3: Analytics (replaces Plausible, $69/mo)

Analytics here means real request counting, not a JavaScript snippet reporting back to someone else’s server. Here’s a real count, pulled straight from the box’s own service log:

That number is real, counted from journalctl, not invented for this post.

Block 4: Uptime & Health (replaces Better Stack, $34/mo)

Temps runs its own health checks every 5 seconds, with a 60-second window before it acts. This is specifically its deploy-health and auto-rollback mechanism, not a separate uptime-monitoring product bolted on. Add a webhook and you get a ping the moment something looks wrong, the same job Better Stack is doing for $34/mo.

Is It Actually Safe to Expose?

I’ve been burned by this exact question before. On a different self-hosted tool (Coolify), I measured that ufw cannot close a port that Docker has published. Docker writes its own firewall rules ahead of ufw‘s, so a ufw deny on that port does nothing at all. I’d actually written the opposite assumption into a script once, and only caught it by testing instead of trusting.

Temps avoids that specific trap by construction: its control-plane runs as a host systemd service, not a Docker-published port, and every deployed app routes through its single Pingora proxy rather than individual host ports. There’s no equivalent Docker-published admin port here to accidentally leave open.

Common Mistakes (and How to Avoid Them)

• Assuming every self-hosted stack fits on one cheap box. It doesn’t. I’ve measured a different stack that genuinely needed two boxes. Check the specific tool’s real resource numbers before you commit, don’t assume “self-hosted” means “lightweight.”
• Trusting ufw to close a Docker-published port. It silently won’t. If a tool exposes its dashboard via docker run -p, firewall it at the DOCKER-USER chain or put it behind a reverse proxy. ufw alone is not protection.
• Skipping the “what breaks with two servers” question. Every “replace your whole stack” pitch glosses over this. Ask it before you’re mid-migration.
• Not registering the admin account immediately. Any fresh self-hosted install has a window where the setup page is reachable by anyone who finds the URL before you’ve claimed it. Register the moment the install script finishes, not “later tonight.”
• Confusing a tool’s general self-hosting reputation with its actual numbers. “Self-hosted” isn’t a resource tier. Two tools both described as lightweight can have wildly different real RAM/CPU needs. Read the specific tool’s own stated numbers, not the category’s reputation.

What This Doesn’t Do

One box only. The moment you need a second server, more traffic than one box handles, or you want redundancy, you’re back to manual provisioning each time. There’s no fleet management, no declarative multi-box config, no unified observability across machines. That’s a real trade-off, not a footnote.

Frequently Asked Questions

Is Temps really free?
Yes. The software itself has no license fee. You pay for the VPS it runs on, which is where the $5/mo comes from.

Does this replace Sentry’s exact feature set?
It accepts Sentry-compatible DSNs so your existing error-reporting code works unchanged, but it’s not a drop-in clone of every Sentry feature. Check your specific needs against what you actually use.

What if I outgrow one server?
You provision a second box manually, there’s no built-in fleet management. See “What This Doesn’t Do” above.

Is my admin console exposed to the internet by default?
Its control-plane binds to an address you configure (TEMPS_CONSOLE_ADMIN_ADDRESS), separate from the public traffic path. Register your admin account immediately after install regardless, the same advice that applies to any fresh self-hosted install.

Do I need to know Docker to run this?
Not really. The install script provisions Docker underneath for you. You’re not writing Docker Compose files or managing containers by hand day to day, the same way you wouldn’t on Vercel. It’s there, it’s just not something you touch directly for normal use.

Can I migrate an existing app over, or does it only work for new projects?
The install and the hosting side work the same either way, point an existing repo at it the same as a new one. What I haven’t personally tested is migrating historical error/analytics data out of Sentry or Plausible into Temps; treat that as a fresh start for monitoring data, not a data-import job.

The Real Number

$152/mo down to $5/mo is $1,824 a year back in your pocket, for four jobs that genuinely don’t need four separate companies billing you for them.

I put together a free one-page cheat sheet with the exact install command, the setup checklist, and the hardening steps. Grab it below if you want to run this yourself without re-reading this whole post.

Get the free $5/Mo Self-Hosted Cheat Sheet

Every command from this post, one page, as a PDF. Enter your email and we’ll send it straight to your inbox.

Get the Cheat Sheet →

If you want to see this whole setup walked through start to finish, I made a video covering the same build. [LINK: video URL, once the video ships].

The post Replace Vercel, Sentry & Plausible for $5/Month (Real Setup) appeared first on The Beginner’s Playbook for Fixing WordPress Errors.

Someone pointed it out to me, not anything on my own site. I checked every setting I knew, and every one was correct.

The address wasn’t in a setting at all. It was in a table Yoast keeps for itself. Below is how I found it, the half-fix that made things worse, the complete one, and the extra trap that made my fix look like it had failed.

One note before we start. The screenshots come from a copy of my site that I rebuilt from the backup I took before the fix, so I could break it again and capture every step. The real site is already repaired.

What You Need

• A WordPress site running Yoast SEO that has moved from a staging address to its live one (I tested this on a recent Yoast SEO release with WP Fastest Cache active)
• WP-CLI access from your WordPress folder
• Access to the database with the mysql or mariadb client
• A backup of two tables: wp_yoast_indexable and wp_yoast_seo_links
• Your own table prefix, if it isn’t wp_ (mine is wp_)

Step 1: Check for a Yoast Canonical Pointing to Staging

Open your homepage, view the page source and search for canonical. Or let the terminal do it in one line:

curl -s https://ceeveeglobal.com/ | grep -oE '<link rel="canonical"[^>]*>|og:url" content="[^"]*"'

You should see: your live address in both lines. If you see staging, localhost or an old domain, keep going. This is what I saw:

(The :8081 in the second panel is just the port my copy of the site runs on.)

A canonical tag is one line in your page’s code that names the original address of that page. og:url is a similar line that Facebook and LinkedIn read when someone shares your page.

Those two were only part of it. My homepage held 14 references to the staging address: one canonical, one og:url, and twelve more inside the structured data, a block of code in the page that tells search engines what the page is.

Google calls a rel="canonical" link “a strong signal that the specified URL should become canonical”. That is why this one line matters.

Step 2: Rule Out the Usual Suspects

Every guide sends you to the same places first. I went through all of them, and each one was clean.

Here are the checks. The first block is the WP-CLI part:

wp option get home
wp option get siteurl
wp eval 'echo home_url();'
grep -E "WP_HOME|WP_SITEURL" wp-config.php

And this is the database part:

SELECT COUNT(*) FROM wp_options WHERE option_value LIKE '%staging.ceeveeglobal%';
SELECT COUNT(*) FROM wp_posts WHERE post_content LIKE '%staging.ceeveeglobal%' OR guid LIKE '%staging.ceeveeglobal%';
SELECT COUNT(*) FROM wp_postmeta WHERE meta_key='_yoast_wpseo_canonical';

You should see: correct addresses from the first three commands and no output from the grep. The three counts came back 1, 0 and 0.

I had six clean checks and one wrong page. That told me the address wasn’t stored where WordPress keeps its settings.

It also explains why the usual advice, “check your SEO plugin settings”, goes nowhere. The plugin’s settings screen was right. The wrong address lived somewhere the settings screen never reads.

Step 3: Find the Real Cause in Yoast’s Own Table

A permalink is a page’s full web address. Yoast keeps a table called wp_yoast_indexable, with a saved copy of the permalink of every page. Each row has a canonical column. When that column is empty, Yoast quietly uses the address it saved.

The canonical column was empty on every row of mine. So I counted how many saved addresses still held the staging domain.

Back up wp_yoast_indexable and wp_yoast_seo_links first, and open the backup file to check it isn’t empty. Then run this:

SELECT 'indexable rows', COUNT(*) FROM wp_yoast_indexable
UNION ALL SELECT 'permalink on staging domain', COUNT(*) FROM wp_yoast_indexable WHERE permalink LIKE '%staging.ceeveeglobal%'
UNION ALL SELECT 'og_image on staging', COUNT(*) FROM wp_yoast_indexable WHERE open_graph_image LIKE '%staging.ceeveeglobal%'
UNION ALL SELECT 'twitter_image on staging', COUNT(*) FROM wp_yoast_indexable WHERE twitter_image LIKE '%staging.ceeveeglobal%'
UNION ALL SELECT 'og_image_meta on staging', COUNT(*) FROM wp_yoast_indexable WHERE open_graph_image_meta LIKE '%staging.ceeveeglobal%'
UNION ALL SELECT 'seo_links on staging', COUNT(*) FROM wp_yoast_seo_links WHERE url LIKE '%staging.ceeveeglobal%'
UNION ALL SELECT 'permalink NULL', COUNT(*) FROM wp_yoast_indexable WHERE permalink IS NULL
UNION ALL SELECT 'permalink_hash consistent', COUNT(*) FROM wp_yoast_indexable WHERE permalink IS NOT NULL AND permalink_hash = CONCAT(LENGTH(permalink),':',MD5(permalink))
UNION ALL SELECT 'permalink not NULL', COUNT(*) FROM wp_yoast_indexable WHERE permalink IS NOT NULL;

You should see: zero on every staging line. This is what I saw:

There were 611 rows, and 511 of them still held the staging address. Here is what each line of the result means:

• permalink on staging domain counts the stale page addresses. Mine was 511.
• og_image, twitter_image and og_image_meta are the picture addresses Yoast keeps for social sharing. They held the staging domain in 72, 55 and 49 rows.
• seo_links on staging counts the internal-link records in wp_yoast_seo_links. Mine held it in 384 rows.
• permalink NULL counts rows with no saved address. It matters in Step 5.

All of it was left over from before the move from staging to live. I had decommissioned my staging site on 13 June 2026, so the address these rows pointed at didn’t exist any more.

Step 4: The Half Reset That Made It Worse

Yoast has its own reset for this. In its code it is called reset_permalink, and it runs when your home address changes. It changes three columns:

'permalink'      => null,
'permalink_hash' => null,
'version'        => 0,

I only knew about two of them. So I emptied permalink and permalink_hash and left the rest alone. Do not run this on your live site.

UPDATE wp_yoast_indexable SET permalink = NULL, permalink_hash = NULL WHERE permalink LIKE '%staging.ceeveeglobal%';

It emptied the rows in a fraction of a second:

Query OK, 511 rows affected (0.017 sec)
Rows matched: 511  Changed: 511  Warnings: 0

Then I reloaded the page. The canonical tag was gone, completely, and so was og:url.

No wrong address and no address at all. That was worse. Nothing refilled the empty permalinks when a page loaded, so on my copy they just stayed empty.

I also ran Yoast’s plain indexing command, wp yoast index, after emptying the rows. It added three rows and didn’t refill any of the emptied ones. The canonical tag stayed missing both times.

The missing piece was the third column. Yoast rebuilds a row when its version is lower than the current one, and its own reset sets version to 0, the lowest possible. My rows still said version 2, so as far as Yoast could tell they were up to date.

Step 5: The Complete Reset (the Actual Fix)

Do exactly what Yoast’s own reset does, all three columns:

UPDATE wp_yoast_indexable SET permalink = NULL, permalink_hash = NULL, version = 0 WHERE permalink LIKE '%staging.ceeveeglobal%';

You should see: the number of stale rows in the Rows matched line. Mine was 511:

Query OK, 511 rows affected (0.015 sec)
Rows matched: 511  Changed: 511  Warnings: 0

Now load a page. The canonical tag and og:url come back with your live address, because Yoast rebuilds each emptied row the first time its page is visited. For the tag itself, that is all it takes.

I checked that on my copy by visiting every published page once, 108 of them. Not one still carried the staging address in its source.

The rows rebuild only as their pages get visited, so permalink NULL stays high for a while. That is normal, and it is why the picture columns and the links table can still hold the old address. Steps 6 and 7 deal with those.

Step 6: Optional: Rebuild Every Row Now

If you would rather not wait for visitors, Yoast has a WP-CLI command that rebuilds everything. Its own help says --reindex “removes all existing indexables and then reindexes them”:

wp yoast index --reindex

On my copy, with 108 published posts and pages, it finished in under two minutes. Afterwards no permalink or picture column held the staging address.

Two things it did not do. It rebuilds every row, including ones that were fine, and on a big site that takes a while. It also left 227 stale rows in the links table, so you still need the second statement in Step 7.

Step 7: Fix the Image and Link Columns

The picture columns and the links table hold real media addresses, so I kept them and swapped only the domain. If you did Step 6, the picture columns are already rebuilt and only the second statement, the one for wp_yoast_seo_links, matters. Running both is harmless:

UPDATE wp_yoast_indexable SET open_graph_image=REPLACE(open_graph_image,'staging.ceeveeglobal.com','ceeveeglobal.com'), twitter_image=REPLACE(twitter_image,'staging.ceeveeglobal.com','ceeveeglobal.com'), open_graph_image_meta=REPLACE(open_graph_image_meta,'staging.ceeveeglobal.com','ceeveeglobal.com') WHERE open_graph_image LIKE '%staging.ceeveeglobal%' OR twitter_image LIKE '%staging.ceeveeglobal%' OR open_graph_image_meta LIKE '%staging.ceeveeglobal%';
UPDATE wp_yoast_seo_links SET url=REPLACE(url,'staging.ceeveeglobal.com','ceeveeglobal.com') WHERE url LIKE '%staging.ceeveeglobal%';

You should see: the matched counts from Step 3. Mine were:

Query OK, 72 rows affected (0.007 sec)
Rows matched: 72  Changed: 72  Warnings: 0
Query OK, 384 rows affected (0.015 sec)
Rows matched: 384  Changed: 384  Warnings: 0

One warning. This only worked because the data in those columns is plain text or JSON. PHP stores serialized data with each string’s length inside it, like s:5:"hello";, so a plain find and replace on serialized data breaks it.

Step 8: Clear the Page Cache (Or Your Fix Will Look Like It Failed)

My database now held zero staging addresses. I reloaded the page and it still said staging.

That is the page cache. It saves a finished copy of every page, wrong canonical included, and keeps serving that copy without asking WordPress. On the real site, 599 files in the cache folder carried the staging address, and the cache held 376 pages in total. A cached copy of my homepage from 14 September already had it.

Clear the saved pages first, then WordPress’s own object cache, which is its short-term memory for values it has already looked up. These are the commands for WP Fastest Cache, with the paths from my install, so change the path to your own WordPress folder, or use your cache plugin’s Clear Cache button if you run a different one:

rm -rf /var/www/html/wp-content/cache/all/*
wp cache flush

You should see: Success: The cache was flushed. If you need a refresher, my guide on how to clear the cache on a WordPress site covers the other plugins.

Step 9: Check It Worked

Run the one-line check from Step 1 again. You should see your live address in both lines.

Then run the counting query from Step 3 again. Every staging line should read 0. On my copy, the homepage and five other pages had zero staging references after the cache was cleared.

The Script I Used on My Live Site (Optional)

I have to be straight about this. On my live site I didn’t know the complete reset would do it. I emptied the rows, saw the tag vanish, and wrote a small script that works out the real address for every row from whatever that row points at. I found the shorter fix afterwards, by reading Yoast’s source.

The script still works, and it is a fair option if you want every emptied row filled in right now without a full reindex. It never deletes a row. Save it as repair-permalinks.php and run wp eval-file repair-permalinks.php from your WordPress folder:

<?php
/**
 * Repopulate Yoast indexable permalinks that were nulled.
 *
 * Nulling the permalink was supposed to make Yoast rebuild it lazily (that is what its own
 * reset-permalinks routine does on a permalink-structure change). On this install it does not
 * rebuild on a front-end request — it simply renders no canonical at all, which is worse than the
 * wrong one. So the permalink is recomputed here from the object each row points at.
 *
 * permalink_hash must stay consistent with permalink: Yoast looks rows up by that hash, and its
 * format is strlen(permalink) . ':' . md5(permalink). Verified against the rows that still had
 * matching hashes before any changes were made.
 *
 * Read-then-write per row, with a count of what it could not resolve. Nothing is deleted.
 */

global $wpdb;

$rows = $wpdb->get_results(
    "SELECT id, object_type, object_sub_type, object_id
       FROM {$wpdb->prefix}yoast_indexable
      WHERE permalink IS NULL"
);

$fixed = 0;
$skipped = [];

foreach ( $rows as $r ) {
    $url = null;

    switch ( $r->object_type ) {
        case 'post':
            if ( $r->object_id ) {
                $p = get_post( (int) $r->object_id );
                // Only published/attachment-style objects have a meaningful public permalink.
                if ( $p ) {
                    $url = get_permalink( $p );
                }
            }
            break;

        case 'term':
            if ( $r->object_id ) {
                $link = get_term_link( (int) $r->object_id );
                if ( ! is_wp_error( $link ) ) {
                    $url = $link;
                }
            }
            break;

        case 'user':
            if ( $r->object_id ) {
                $url = get_author_posts_url( (int) $r->object_id );
            }
            break;

        case 'home-page':
            $url = home_url( '/' );
            break;

        case 'post-type-archive':
            if ( $r->object_sub_type ) {
                $link = get_post_type_archive_link( $r->object_sub_type );
                if ( $link ) {
                    $url = $link;
                }
            }
            break;

        case 'date-archive':
            $url = home_url( '/' );
            break;

        // 'system-page' (404, search) has no canonical of its own — left NULL deliberately.
    }

    if ( ! $url ) {
        $key = $r->object_type . ( $r->object_sub_type ? ':' . $r->object_sub_type : '' );
        $skipped[ $key ] = ( $skipped[ $key ] ?? 0 ) + 1;
        continue;
    }

    $wpdb->update(
        $wpdb->prefix . 'yoast_indexable',
        [
            'permalink'      => $url,
            'permalink_hash' => strlen( $url ) . ':' . md5( $url ),
        ],
        [ 'id' => (int) $r->id ]
    );
    $fixed++;
}

echo "repaired: $fixed\n";
echo "left NULL by type:\n";
foreach ( $skipped as $k => $n ) {
    echo "  $k: $n\n";
}

$remaining = (int) $wpdb->get_var( "SELECT COUNT(*) FROM {$wpdb->prefix}yoast_indexable WHERE permalink IS NULL" );
$staging   = (int) $wpdb->get_var( "SELECT COUNT(*) FROM {$wpdb->prefix}yoast_indexable WHERE permalink LIKE '%staging.ceeveeglobal%'" );
$hashok    = (int) $wpdb->get_var(
    "SELECT COUNT(*) FROM {$wpdb->prefix}yoast_indexable
      WHERE permalink IS NOT NULL AND permalink_hash = CONCAT(LENGTH(permalink),':',MD5(permalink))"
);
$notnull   = (int) $wpdb->get_var( "SELECT COUNT(*) FROM {$wpdb->prefix}yoast_indexable WHERE permalink IS NOT NULL" );

echo "\nstill NULL: $remaining\n";
echo "still staging: $staging\n";
echo "hash consistent: $hashok of $notnull non-null\n";

On my copy it repaired 512 rows and left 47 empty. Those 47 are system pages such as the 404 page and search results, which never had a canonical.

Common Mistakes (and How to Avoid Them)

• Emptying only some of the columns Yoast’s reset changes. I emptied two of three, and the canonical tag disappeared instead of coming back. Use the complete reset from Step 5.
• Running plain wp yoast index after a half reset. On my copy it added three rows and left every emptied row empty. Use --reindex, or set version to 0 as in Step 5.
• Fixing the table and skipping the cache. The page keeps serving the old copy, so the fix looks like it failed. Clear the cache every time you change the table.
• Checking only the canonical tag. My homepage had 14 references, and 12 of them were in the structured data. Count the whole page source, not one line.
• Running a find and replace over serialized data. The stored string lengths stop matching, and the data breaks. Only replace text in columns you know are plain text or JSON.

Frequently Asked Questions

How do I know if my site has this problem?

View the page source of your homepage and search for canonical. If the address is a staging, localhost or old domain, run the counting query from Step 3 to see how many rows in Yoast’s table still hold it.

Does a wrong canonical hurt my rankings?

I didn’t measure any change in rankings, so I can’t tell you it did. Google describes a canonical link as “a strong signal”, so a dead staging address is the wrong thing to hand it.

Why didn’t Yoast fix this itself?

Yoast runs its reset when the home address option is updated. Why that didn’t happen on my site, I don’t know. I can’t tell how the old addresses got into the table, so I’m not going to guess.

Will this work with Rank Math or another SEO plugin?

I only tested this on a recent Yoast SEO release with WP Fastest Cache active. Another SEO plugin or another cache, or an older Yoast version, might store or serve the address differently, so check its own tables and cache before copying these steps.

Should I run this on my live site?

I ran the script from the last section on my live site after backing up both tables. The complete reset and the reindex I only tested on the copy. Try either one on a copy of your own site first.

Wrapping Up

The wrong address wasn’t in any setting. It was in Yoast’s own table, half a reset made it worse, and the page cache kept serving it after I fixed it.

If a page ever refuses to change after you fix it, my guide to the WordPress White Screen of Death shows another case where the fix was right and something else was in the way.

The post Yoast Canonical Pointing to Staging: Why No Setting Shows It 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.

Quick Answer: I built a small FastAPI email verification API — it checks every email against four things: valid syntax, a disposable-domain blocklist, role-based prefixes like info@ or admin@, and a live DNS MX record lookup, before anything is trusted. It’s live on my own tools API today, and you can build your own copy in about 10 minutes.

What You Need

• Python 3.9 or newer
• About 10 minutes and a terminal
• A Mautic instance or any signup form, if you want to wire this in for real — optional for just trying the API
• Basic FastAPI familiarity helps, but every route here is short enough to follow cold

What I Tried First — And Why It Wasn’t Enough

My first fix was a cleanup script, not a filter. I wrote mautic-cleanup.py to scan every contact already in Mautic through its REST API, flag anything on a disposable-domain list or still unconfirmed after 30 days, and delete the flagged ones.

DISPOSABLE_DOMAINS = {
    "mailinator.com", "guerrillamail.com", "tempmail.com", "throwaway.email",
    "yopmail.com", "sharklasers.com", "trashmail.com", "dispostable.com",
    # ...786 domains total in my full list
}
# In production this loads from a text file instead of a hardcoded set —
# same idea, just easier to keep adding to as new disposable domains show up.

CUTOFF_DAYS = 30  # unconfirmed contacts older than this are considered bots

def is_bot(contact):
    reasons = []
    email = (contact.get("fields", {}).get("core", {}).get("email", {}).get("value") or "").lower()
    if not email:
        reasons.append("no email")
        return reasons

    domain = email.split("@")[-1] if "@" in email else ""
    if domain in DISPOSABLE_DOMAINS:
        reasons.append(f"disposable domain: {domain}")

    confirmed = contact.get("fields", {}).get("core", {}).get("confirmed", {}).get("value")
    date_added_str = contact.get("dateAdded", "")
    if str(confirmed) in ("0", "false", "") and date_added_str:
        date_added = datetime.fromisoformat(date_added_str.replace("Z", "+00:00"))
        age_days = (datetime.now(timezone.utc) - date_added).days
        if age_days >= CUTOFF_DAYS:
            reasons.append(f"unconfirmed {age_days}d")

    return reasons

Any contact that comes back with a reason gets flagged. The script pulls every contact through Mautic’s /api/v2/contacts endpoint first, paginating 200 at a time, then runs this check against each one.

It ran as a dry run by default and only deleted with --delete. It worked — I cleared out a real batch of bots the first time I ran it. But it’s reactive: junk still landed in Mautic first, and I was cleaning up a mess instead of stopping it at the door.

What Actually Fixed It — Building a FastAPI Email Verification API

The real fix was moving the check to before a signup gets accepted, not after. So I built a standalone FastAPI endpoint — /email/verify — that scores every address before anything touches Mautic.

I keep it as its own router file, app/routers/email_tools.py, with the disposable-domain list in a separate app/data/disposable_domains.txt so it’s not baked into the code. One line in main.py wires it into the app:

app.include_router(email_tools.router, tags=["email_tools"])

That’s the same pattern most FastAPI apps use to stay organized as you add more tools — each feature gets its own router file instead of one giant main.py.

The Four Checks

Each email goes through four gates, in order, and stops at the first one it fails:

import re
import dns.resolver

SYNTAX_RE = re.compile(r'^[^@\s]+@[^@\s]+\.[^@\s]{2,}$')

ROLE_PREFIXES = {
    "info", "admin", "support", "noreply", "no-reply", "postmaster",
    "webmaster", "contact", "sales", "help", "billing", "abuse",
    "security", "hostmaster", "mailer-daemon", "marketing", "newsletter",
}

def check_mx(domain: str) -> bool:
    try:
        dns.resolver.resolve(domain, "MX")
        return True
    except Exception:
        return False

def verify_single(email: str) -> dict:
    email = email.strip().lower()
    checks = {"syntax": False, "has_mx": False, "is_disposable": False, "is_role_based": False}
    score = 0

    if not SYNTAX_RE.match(email):
        return {"email": email, "is_valid": False, "score": 0, "checks": checks, "reason": "Invalid email format"}
    checks["syntax"] = True
    score += 25

    local, domain = email.split("@", 1)

    if domain in DISPOSABLE_DOMAINS:
        checks["is_disposable"] = True
        return {"email": email, "is_valid": False, "score": score, "checks": checks, "reason": "Disposable email domain not accepted"}
    score += 25

    if local in ROLE_PREFIXES:
        checks["is_role_based"] = True
        return {"email": email, "is_valid": False, "score": score, "checks": checks, "reason": "Role-based addresses not accepted (e.g. info@, admin@)"}
    score += 25

    has_mx = check_mx(domain)
    checks["has_mx"] = has_mx
    if not has_mx:
        return {"email": email, "is_valid": False, "score": score, "checks": checks, "reason": "Email domain has no mail server (MX record missing)"}
    score += 25

    return {"email": email, "is_valid": True, "score": score, "checks": checks, "reason": None}

The scoring stops early. If the syntax is wrong, you get a score of 0 back immediately — there’s no point checking MX records on something that isn’t even shaped like an email. Each passed check adds 25 points, so a fully valid address always scores 100.

Dimu’s Note: the role-based rejection was the one I almost skipped. But info@company.com is a real inbox someone reads — just not the person who signed up for your newsletter. Blocking it kept my open-rate numbers honest.

Why the Checks Run in a Thread Executor

dns.resolver.resolve() is blocking — it waits on a real network call, and so does reading the disposable-domain file. Call either one directly inside an async def route and it freezes the whole event loop, not just that one request. Every other request waiting on your API stalls with it.

The fix is one line per call:

loop = asyncio.get_event_loop()
result = await loop.run_in_executor(None, verify_single, email)

run_in_executor pushes the blocking function onto a background thread pool and hands control straight back to the event loop. Your API stays responsive to every other request while that one DNS lookup is still working. This is the part most FastAPI tutorials skip — and it’s the difference between an endpoint that scales and one that falls over the moment two people hit it at once.

Three Endpoints

I exposed the checker three ways, so it fits however I end up calling it:

@router.get("/email/verify")
async def verify_email_get(email: str = Query(...)):
    loop = asyncio.get_event_loop()
    result = await loop.run_in_executor(None, verify_single, email)
    return {"success": True, "message": f"Email is {'valid' if result['is_valid'] else 'invalid'}", "result": result}

@router.post("/email/verify")
async def verify_email_post(body: dict):
    email = body.get("email", "")
    loop = asyncio.get_event_loop()
    result = await loop.run_in_executor(None, verify_single, email)
    return {"success": True, "message": f"Email is {'valid' if result['is_valid'] else 'invalid'}", "result": result}

@router.post("/email/verify-bulk")
async def verify_email_bulk(body: BulkEmailVerifyRequest):
    emails = body.emails[:50]  # hard cap so one request can't hammer DNS 5000 times
    loop = asyncio.get_event_loop()
    tasks = [loop.run_in_executor(None, verify_single, e) for e in emails]
    results = await asyncio.gather(*tasks)
    valid_count = sum(1 for r in results if r["is_valid"])
    return {"success": True, "result": {"results": results, "summary": {"total": len(results), "valid": valid_count, "invalid": len(results) - valid_count}}}

The bulk endpoint gathers all the executor calls concurrently with asyncio.gather, so 50 emails don’t verify one at a time — they all run in parallel threads at once.

Try It Yourself — Self-Host in About 10 Minutes

You don’t need my full tools API to run this — it’s one router file. Here’s the minimal setup:

pip install fastapi uvicorn dnspython

Drop verify_single, check_mx, and the three routes above into a single main.py, wire the router into a FastAPI app, then run it:

from fastapi import FastAPI, APIRouter, Query
from pydantic import BaseModel
from typing import List

router = APIRouter()

class BulkEmailVerifyRequest(BaseModel):
    emails: List[str]

# ...paste verify_single(), check_mx(), and the three @router routes here...

app = FastAPI()
app.include_router(router)

uvicorn main:app --host 0.0.0.0 --port 8000

Then test it:

curl "http://localhost:8000/email/verify?email=test@mailinator.com"

{
  "success": true,
  "message": "Email is invalid",
  "result": {
    "email": "test@mailinator.com",
    "is_valid": false,
    "score": 25,
    "checks": {"syntax": true, "has_mx": false, "is_disposable": true, "is_role_based": false},
    "reason": "Disposable email domain not accepted"
  }
}

FastAPI also builds an interactive docs page automatically — mine’s at /customdocs since I renamed the default route, yours will sit at localhost:8000/docs if you didn’t touch it. You can test all three endpoints straight from the browser there, no curl needed.

If you’re putting this on a real domain instead of localhost, I run mine on a Contabo VPS — cheap enough that a small side API like this barely registers on the bill.

Quick Reference

curl -X POST "http://localhost:8000/email/verify" \
  -H "Content-Type: application/json" \
  -d '{"email": "someone@gmail.com"}'

curl -X POST "http://localhost:8000/email/verify-bulk" \
  -H "Content-Type: application/json" \
  -d '{"emails": ["a@gmail.com", "b@mailinator.com", "info@company.com"]}'

Advanced Tips

My live version sits behind an API key, since it shares one FastAPI app with a dozen other tools I’ve built. Instead of decorating every single route with a dependency, I gate the whole app in one place:

class APIKeyMiddleware(BaseHTTPMiddleware):
    async def dispatch(self, request: Request, call_next):
        if request.url.path not in WHITELISTED_PATHS:
            api_key = request.headers.get(API_KEY_NAME)
            if api_key != API_KEY:
                return JSONResponse(status_code=401, content={"detail": "Invalid API key"})
        return await call_next(request)

app.add_middleware(APIKeyMiddleware)

One middleware class, one line to register it, every route protected except the ones I explicitly whitelist, like the docs page. If you’re only running the email verifier alone, you probably don’t need this yet — but the moment you add a second tool to the same app, it’s worth doing before you’re pasting the same Depends() onto every route.

The 50-email cap on the bulk endpoint is doing similar work. It’s not a technical limit, it’s a guardrail — without it, one request could try to trigger 5,000 DNS lookups and tie up your thread pool for everyone else.

Frequently Asked Questions

Does this replace SMTP-level email verification?

No. This checks that the domain can receive mail via its MX record, not that the specific mailbox exists. Full SMTP verification means connecting to the mail server and asking directly — slower, and a lot of providers block or fake that response anyway.

Why not just use a paid email verification API?

Cost, mostly. Most paid APIs charge per lookup once you’re past a small free tier. For a Mautic list that’s mostly WordPress and dev-tool signups, syntax plus disposable plus role plus MX catches the obvious junk without a monthly bill.

How do I keep the disposable domain list current?

Mine started small and grew every time a new one slipped through in Mautic — it’s at 786 domains now. There are public lists on GitHub you can seed from, then keep adding whatever gets past you.

Will this catch every bot signup?

No — a bot using a real Gmail address passes every check here. This stops the lazy, high-volume junk: disposable domains, malformed addresses, dead domains — which was most of what was hitting my Mautic list.

Final Thoughts

The real lesson wasn’t the code — it was catching the problem at the door instead of mopping up after. mautic-cleanup.py still runs occasionally as a backstop, but the verification API is what actually changed my numbers.

This endpoint isn’t wired into my Mautic signup form yet — that’s next. I’m also planning to open a version of this up as a free public tool on aibuilttools.com, where you’ll be able to grab an API key by joining my list — if that’s useful to you, keep an eye on that page.

The post FastAPI Email Verification API: How I Built It appeared first on The Beginner’s Playbook for Fixing WordPress Errors.

Every time I wanted Claude to help me update a post, add a new page, or check my plugin list, I was copying and pasting. Text in. Text out. Then manually clicking through the WordPress dashboard to actually apply it.

There had to be a better way. And there was — it just took me a full weekend of broken Node.js paths and permission errors to find it.

What I Tried First — And Why It Didn’t Work

My first instinct was to use a REST API approach. WordPress has a built-in REST API, so I figured I’d just point Claude at it with an API key and call it a day.

Two problems showed up immediately.

First problem: Claude Code doesn’t natively “call” REST APIs on its own during a conversation — it needs a tool or server to bridge that connection. The REST API is great for building apps, but it isn’t a conversational interface.

Second problem: My WordPress site runs inside a Docker container on a Coolify VPS. It’s not publicly accessible via REST during dev work — I’d have to expose ports and deal with auth tokens just to test a simple post update. That felt like overkill for what I needed.

I also tried a plugin called “AI Power” which connects WordPress to OpenAI. Useful for content generation — but it doesn’t let Claude control WordPress. It just uses GPT inside the WordPress editor. That’s the opposite direction from what I wanted.

What I actually needed was an MCP server — a small Node.js process that exposes WordPress tools (create post, get posts, update page, list plugins) to Claude Code via the Model Context Protocol.

So I built one.

What Actually Fixed It — The MCP Server Setup

Here’s exactly how I set it up. My stack: Coolify VPS + Docker WordPress container + Node.js MCP server.

Step 1 — SSH into the VPS and set up a working directory

ssh coolify-vps
mkdir -p /home/coolify-service/wp-mcp
cd /home/coolify-service/wp-mcp

I created a dedicated folder outside the Docker container. The MCP server runs on the host — it communicates with WordPress via WP-CLI commands executed inside the container.

Step 2 — Install Node.js on the VPS host

curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
sudo apt-get install -y nodejs
node --version  # should show v20.x.x

If you’re on a minimal Coolify VPS like mine, Node.js won’t be pre-installed. Don’t skip this check.

Step 3 — Initialize the project and install the MCP SDK

cd /home/coolify-service/wp-mcp
npm init -y
npm install @modelcontextprotocol/sdk

The @modelcontextprotocol/sdk is the official Anthropic MCP package. It handles all the protocol handshake — you just define tools.

Step 4 — Write the server.js file

This is the core of the whole setup. Here’s a simplified version of what my server.js looks like:

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { CallToolRequestSchema, ListToolsRequestSchema } from "@modelcontextprotocol/sdk/types.js";
import { execSync } from "child_process";

const WP_CONTAINER = "wordpress-n0g4skoo8sgwgc848koog0ww";

function runWpCli(command) {
  const full = `docker exec ${WP_CONTAINER} wp --allow-root ${command}`;
  return execSync(full, { encoding: "utf8" });
}

const server = new Server(
  { name: "wordpress-mcp", version: "1.0.0" },
  { capabilities: { tools: {} } }
);

server.setRequestHandler(ListToolsRequestSchema, async () => ({
  tools: [
    {
      name: "wp_get_posts",
      description: "List recent WordPress posts",
      inputSchema: {
        type: "object",
        properties: {
          count: { type: "number", description: "Number of posts to retrieve" }
        }
      }
    },
    {
      name: "wp_create_post",
      description: "Create a new WordPress post",
      inputSchema: {
        type: "object",
        properties: {
          title: { type: "string" },
          content: { type: "string" },
          status: { type: "string", enum: ["draft", "publish"] }
        },
        required: ["title", "content"]
      }
    }
  ]
}));

server.setRequestHandler(CallToolRequestSchema, async (request) => {
  const { name, arguments: args } = request.params;

  if (name === "wp_get_posts") {
    const count = args.count || 5;
    const result = runWpCli(`post list --posts_per_page=${count} --fields=ID,post_title,post_status --format=json`);
    return { content: [{ type: "text", text: result }] };
  }

  if (name === "wp_create_post") {
    const { title, content, status = "draft" } = args;
    const result = runWpCli(`post create --post_title="${title}" --post_content="${content}" --post_status=${status}`);
    return { content: [{ type: "text", text: result }] };
  }

  throw new Error(`Unknown tool: ${name}`);
});

const transport = new StdioServerTransport();
await server.connect(transport);

The key insight here: every tool just runs a WP-CLI command inside the Docker container via docker exec. No REST API. No auth tokens. Direct shell access.

Step 5 — Add the MCP server to Claude Code config

On your local machine (not the VPS), open your Claude Code MCP config file. On Windows it’s at:

C:\Users\YourName\AppData\Roaming\Claude\claude_desktop_config.json

Add this block:

{
  "mcpServers": {
    "wordpress": {
      "command": "ssh",
      "args": [
        "coolify-vps",
        "node /home/coolify-service/wp-mcp/server.js"
      ]
    }
  }
}

This tells Claude Code: when you need WordPress tools, SSH into my VPS and run the Node.js server. The MCP protocol runs over stdio — so SSH becomes the transport pipe.

Step 6 — Test it

Restart Claude Code. In the chat, try:

List my last 5 WordPress posts

If it works, you’ll see Claude call the wp_get_posts tool and return your actual post titles. That moment — the first time Claude listed my real posts from ceeveeglobal.com without me touching the dashboard — genuinely felt like magic.

Quick Reference

# SSH into VPS
ssh coolify-vps

# Start MCP server manually (for testing)
node /home/coolify-service/wp-mcp/server.js

# Test WP-CLI directly (check connection works)
docker exec wordpress-n0g4skoo8sgwgc848koog0ww wp --allow-root post list

# Check Node.js version on VPS
node --version

# Reinstall SDK if something breaks
cd /home/coolify-service/wp-mcp && npm install

Claude Code config location (Windows):

%APPDATA%\Claude\claude_desktop_config.json

Claude Code config location (Mac):

~/Library/Application Support/Claude/claude_desktop_config.json

Frequently Asked Questions

Q: Do I need a special WordPress plugin for this to work?

No plugin needed. The MCP server communicates with WordPress through WP-CLI running inside the Docker container. As long as WP-CLI is installed in your container (it is by default in most WordPress Docker images), you’re good to go. No REST API, no extra plugins — just shell commands.

Q: Is this secure? I don’t want to expose my WordPress to the internet.

It’s actually more secure than the REST API approach. The MCP server runs on your VPS host and only accepts connections via SSH. Nothing is exposed publicly. Claude Code connects through your existing SSH key pair — same as if you logged in manually. Your WordPress dashboard URL stays private.

Q: What happens if the Docker container name changes after a Coolify update?

This caught me once. After a Coolify update, my container got recreated with a different ID. I store the container name as a constant at the top of server.js — so I just update that one line and restart. To find your current container name:

docker ps --filter "name=wordpress" --format "{{.Names}}"

Final Thoughts

This setup changed how I work with my WordPress sites. Instead of switching between Claude and the dashboard, I just describe what I want and it happens — new posts drafted, plugin lists checked, page content updated, all through conversation.

It’s not a product you can buy. It’s something you build, and that’s the point. If you want to go further — more tools, more sites, a shared MCP config — I’ve packaged some of these patterns into ready-to-use tools at aibuilttools.com.

Start with one tool. Get it working. Build from there.

The post How I Connected WordPress to Claude AI With an MCP Server appeared first on The Beginner’s Playbook for Fixing WordPress Errors.

Understanding the Issue: Why is Mautic 5 Missing in Coolify?

When you open Coolify, looking for Mautic under the “Add Resource” section, it can be frustrating to find nothing. The absence of a one-click app or template for Mautic 5 in Coolify is due to recent updates and changes in the Coolify ecosystem, necessitating a manual workaround.

Why Mautic Matters for WordPress Users

Mautic is a powerful open-source marketing automation tool, seamlessly integrating with WordPress to enhance customer engagement and conversion rates. Its absence from Coolify means WordPress users need an alternative method to keep their automation processes running smoothly.

Prerequisites

Before diving into the deployment process, ensure you have the following prerequisites:

• Basic understanding of Docker and Docker Compose.
• Access to a server with Docker installed.
• Admin access to a Coolify account.
• A domain name if you plan to use a custom URL.

Step-by-Step Implementation: Deploying Mautic 5 with Docker Compose

Despite its absence in Coolify, deploying Mautic 5 is straightforward with Docker Compose. Follow these steps to get started:

1. Create a New Project in Coolify: Navigate to your Coolify dashboard and click New. Name your project (e.g., “Mautic”), then proceed with Continue.
2. Add a Resource: Choose Add Resource and select Docker Compose Empty to initiate your custom setup.
3. Insert the Docker Compose File: Copy the Docker Compose file provided in the resource link and paste it into the designated area. Click Save, then Deploy to start the process.
   Access Your Mautic Instance: Once deployed, go to Links in Coolify and click the generated URL to complete your Mautic setup.

version: "3.9"

services:
  db:
    image: mysql:8.0
    environment:
      - MYSQL_ROOT_PASSWORD=${SERVICE_PASSWORD_64_MYSQLROOT}
      - MYSQL_DATABASE=${MYSQL_DATABASE:-mautic}
      - MYSQL_USER=${SERVICE_USER_MYSQL}
      - MYSQL_PASSWORD=${SERVICE_PASSWORD_64_MYSQL}
    volumes:
      - mysql-data:/var/lib/mysql
    healthcheck:
      test: mysqladmin ping --silent --user=$${SERVICE_USER_MYSQL} --password=$${SERVICE_PASSWORD_64_MYSQL}
      start_period: 30s
      interval: 10s
      timeout: 5s
      retries: 5

  rabbitmq:
    image: rabbitmq:3
    environment:
      - RABBITMQ_DEFAULT_VHOST=${RABBITMQ_DEFAULT_VHOST:-mautic}
    volumes:
      - rabbitmq-data:/var/lib/rabbitmq

  mautic_web:
    image: mautic/mautic:latest
    ports:
      - "8880:80"
    volumes:
      - mautic_data/config:/var/www/html/config:z
      - mautic_data/logs:/var/www/html/var/logs:z
      - mautic_data/media/files:/var/www/html/docroot/media/files:z
      - mautic_data/media/images:/var/www/html/docroot/media/images:z
      - mautic_data/plugins:/var/www/html/docroot/plugins:z
      - mautic_data/vendor:/var/www/html/vendor:z
      - mautic_data/bin:/var/www/html/bin:z
      - mautic_data/cron:/opt/mautic/cron:z
    environment:
      - SERVICE_FQDN_MAUTIC_80
      - DOCKER_MAUTIC_LOAD_TEST_DATA=${MAUTIC_LOAD_TEST_DATA:-false}
      - DOCKER_MAUTIC_RUN_MIGRATIONS=${MAUTIC_RUN_MIGRATIONS:-false}
      - MAUTIC_DB_HOST=${MYSQL_HOST:-db}
      - MAUTIC_DB_PORT=${MYSQL_PORT:-3306}
      - MAUTIC_DB_DATABASE=${MYSQL_DATABASE:-mautic}
      - MAUTIC_DB_USER=${SERVICE_USER_MYSQL}
      - MAUTIC_DB_PASSWORD=${SERVICE_PASSWORD_64_MYSQL}
      - MAUTIC_MESSENGER_DSN_EMAIL=amqp://guest:guest@rabbitmq:5672/mautic/messages
      - MAUTIC_MESSENGER_DSN_HIT=amqp://guest:guest@rabbitmq:5672/mautic/messages
    depends_on:
      db:
        condition: service_healthy
      rabbitmq:
        condition: service_started
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost"]
      interval: 15s
      timeout: 10s
      retries: 15

  mautic_cron:
    image: mautic/mautic:latest
    volumes:
      - mautic_data/config:/var/www/html/config:z
      - mautic_data/logs:/var/www/html/var/logs:z
      - mautic_data/media/files:/var/www/html/docroot/media/files:z
      - mautic_data/media/images:/var/www/html/docroot/media/images:z
      - mautic_data/plugins:/var/www/html/docroot/plugins:z
      - mautic_data/vendor:/var/www/html/vendor:z
      - mautic_data/bin:/var/www/html/bin:z
      - mautic_data/cron:/opt/mautic/cron:z
    environment:
      - DOCKER_MAUTIC_ROLE=mautic_cron
      - MAUTIC_DB_HOST=${MYSQL_HOST:-db}
      - MAUTIC_DB_PORT=${MYSQL_PORT:-3306}
      - MAUTIC_DB_DATABASE=${MYSQL_DATABASE:-mautic}
      - MAUTIC_DB_USER=${SERVICE_USER_MYSQL}
      - MAUTIC_DB_PASSWORD=${SERVICE_PASSWORD_64_MYSQL}
      - MAUTIC_MESSENGER_DSN_EMAIL=amqp://guest:guest@rabbitmq:5672/mautic/messages
      - MAUTIC_MESSENGER_DSN_HIT=amqp://guest:guest@rabbitmq:5672/mautic/messages
    depends_on:
      mautic_web:
        condition: service_healthy

  mautic_worker:
    image: mautic/mautic:latest
    volumes:
      - mautic_data/config:/var/www/html/config:z
      - mautic_data/logs:/var/www/html/var/logs:z
      - mautic_data/media/files:/var/www/html/docroot/media/files:z
      - mautic_data/media/images:/var/www/html/docroot/media/images:z
      - mautic_data/plugins:/var/www/html/docroot/plugins:z
      - mautic_data/vendor:/var/www/html/vendor:z
      - mautic_data/bin:/var/www/html/bin:z
      - mautic_data/cron:/opt/mautic/cron:z
    environment:
      - DOCKER_MAUTIC_ROLE=mautic_worker
      - MAUTIC_DB_HOST=${MYSQL_HOST:-db}
      - MAUTIC_DB_PORT=${MYSQL_PORT:-3306}
      - MAUTIC_DB_DATABASE=${MYSQL_DATABASE:-mautic}
      - MAUTIC_DB_USER=${SERVICE_USER_MYSQL}
      - MAUTIC_DB_PASSWORD=${SERVICE_PASSWORD_64_MYSQL}
      - MAUTIC_MESSENGER_DSN_EMAIL=amqp://guest:guest@rabbitmq:5672/mautic/messages
      - MAUTIC_MESSENGER_DSN_HIT=amqp://guest:guest@rabbitmq:5672/mautic/messages
    depends_on:
      mautic_web:
        condition: service_healthy

volumes:
  mysql-data:
  rabbitmq-data:
  mautic_data:

Connecting a Custom Domain

For personalised branding, connecting a custom domain to your Mautic instance is beneficial. Here’s how:

• Log in to your domain provider (e.g., Namecheap) and access Advanced DNS settings.
• Add a new record, select A Record, enter your subdomain (e.g., “mautic”), and point it to your server’s IP.
• Save the changes. After DNS propagation, return to Coolify, open your Mautic service, navigate to Settings, and add your subdomain.

Advanced Insights: Expert Tips for Optimising Your Setup

Deploying Mautic through Docker Compose opens avenues for customization and optimization. Here are expert-level tips:

• Optimize Performance: Configure Docker resources such as CPU and memory allocation to ensure Mautic runs efficiently.
• Regular Backups: Set up automated backups for your Mautic data to prevent data loss. Tools like DigitalOcean Spaces can be valuable here.
• Enhance Security: Use SSL certificates for secure communication. Services like Let’s Encrypt provide free SSL certificates.

Integrating Affiliate Recommendations

For an all-in-one solution, consider hosting providers like Vultr or InterServer for reliable and cost-effective hosting solutions. Additionally, Namecheap remains a top choice for domain management.

Troubleshooting Common Issues

If you encounter issues during the installation or deployment process, consider the following tips:

• Port Conflicts: Ensure no other services are using the ports Mautic requires.
• Check Logs: Use Docker logs to identify any errors during deployment.
• Network Settings: Verify your server’s firewall and network settings allow necessary traffic.

Conclusion: Bringing Mautic Back to Coolify

While the absence of Mautic 5 in Coolify might initially seem daunting, the manual deployment using Docker Compose is a robust alternative. By following the steps outlined above, WordPress users can regain the powerful marketing automation capabilities Mautic offers. Embrace these changes, and enhance your online strategies with a tailored approach.

FAQs: Mautic 5 Missing in Coolify

• Why is Mautic 5 not showing in Coolify? Coolify has undergone updates, removing the direct one-click Mautic installation, necessitating a manual setup.
• Can I still use Mautic with Coolify? Yes, by utilizing Docker Compose, you can manually deploy Mautic 5 on your server.
• Is Docker Compose difficult to use? Docker Compose simplifies the deployment process, especially when following detailed guides like this one.

Summary

To recap, deploying Mautic 5 in Coolify involves creating a new project, adding a Docker Compose resource, and configuring your domain. With these steps, you can restore Mautic’s capabilities even without direct Coolify support.

Have questions or need further clarification? Feel free to leave a comment below, and we’ll be happy to assist you.

Explore more WordPress tips and tricks|/wordpress-tips-tricks
Learn how to optimize your WordPress site for SEO|/wordpress-seo-optimization

The post Mautic 5 Missing in Coolify? Here’s How to Fix It with Docker Compose appeared first on The Beginner’s Playbook for Fixing WordPress Errors.

Most beginners copy-paste WordPress code from Stack Overflow without understanding what it actually does. I did the same thing for months until I realized I was just guessing. One wrong character in functions.php, and boom — White Screen of Death.

Here’s the truth: you don’t need to memorize thousands of functions. I’ll show you 8 WordPress code concepts that power every WordPress site — from simple blogs to complex e-commerce stores.

Understanding these core WordPress code concepts will transform how you build and customize WordPress sites. No more guessing. No more breaking things accidentally.

By the end of this guide, you’ll understand:

• What each WordPress code concept is (in plain English)
• How to use it properly (with working code examples)
• Real-world problems it solves (not just theory)

Let’s start with the most important warning before diving into these WordPress code concepts.

⚠️ CRITICAL WARNING: Before You Edit functions.php

Editing functions.php can break your entire site if you make one syntax error. I learned this the hard way when my client’s site went down.

Always follow these rules:

✅ Backup your site first — Don’t waste money on backup plugins. Watch how I built my own backup system in 15 minutes using AI (saves you $840/year)

✅ Use a child theme — Never edit parent theme files directly

✅ Test on staging site — If you have one available

✅ Or use Code Snippets plugin — Much safer than editing functions.php

One missing semicolon = White Screen of Death. You’ve been warned.

Now let’s dive into the essential WordPress code concepts that every developer should know.

Why Understanding WordPress Code Concepts Matters

Before we jump into specific WordPress code concepts, let’s talk about why this matters.

WordPress powers 43% of all websites. But here’s what most people don’t know: every WordPress plugin, theme, and custom functionality uses the same 8 core WordPress code concepts.

When you understand these WordPress programming fundamentals, you can:

• Debug WordPress errors faster
• Build custom features without expensive plugins
• Understand how WordPress plugins actually work
• Optimize your site’s performance
• Fix broken functionality yourself

These WordPress code concepts are the building blocks. Master them, and you’ll never feel helpless staring at WordPress code again.

Concept 1: add_action() Hook — The Foundation of WordPress

What is add_action()?

The add_action() hook is one of the most important WordPress code concepts. It lets you add custom code at specific points in WordPress without modifying core files.

Think of WordPress actions as “when X happens, do Y.” It’s event-driven programming made simple.

How to use add_action():

add_action('wp_footer', 'add_footer_text');
function add_footer_text() {
    echo '<div style="text-align: center; padding: 20px; background: #f0f0f0;">
        Built with ❤️ by Dimu | <a href="https://ceeveeglobal.com">Visit My Site</a>
    </div>';
}

What this does: Adds a custom footer message to every page on your site.

How to Test If It’s Working:

1. Add the code above to Code Snippets plugin (or functions.php)
2. Save and activate
3. Visit any page on your site
4. Scroll to the bottom

You should see: A gray box with “Built with ❤️ by Dimu” at the footer.

If you don’t see it: Check for syntax errors. One missing semicolon or bracket breaks everything.

Common Beginner Mistake:

Many tutorials use console.log() in examples like this:

echo '<script>console.log("Hello");</script>';

This does work — but you can’t see it on your page. You have to open browser Developer Console (F12) to see the message. That’s why beginners think their code failed.

Always test with visible output first (text, colors, borders) so you know your code is running.

Real-world problems add_action() solves:

• Add Google Analytics or tracking codes to footer automatically
• Insert custom content after every blog post
• Load scripts at the right time (not too early, not too late)
• Modify WordPress behavior without touching core files
• Hook into WordPress events like user login, post publishing

When to use add_action():

When you need to add functionality at specific WordPress events. Like adding a banner after every blog post or loading custom CSS on specific pages.

I use add_action() constantly. My AI tools page uses add_action to load custom JavaScript only on that page — not sitewide. Result? Faster load times and better performance.

More Practical Examples:

Example 2: Add Custom CSS to All Pages

add_action('wp_head', 'my_custom_styles');
function my_custom_styles() {
    echo '<style>
        body { border-top: 5px solid #ff6b6b; }
    </style>';
}

What you’ll see: Red border at the top of every page.

Example 3: Admin Dashboard Notice

add_action('admin_notices', 'my_admin_notice');
function my_admin_notice() {
    echo '<div class="notice notice-success">
        <p>Your custom code is working! 🎉</p>
    </div>';
}

Where to see it: WordPress Admin Dashboard (top of the page when you log in).

Pro tip: The most common WordPress actions are wp_head, wp_footer, init, wp_enqueue_scripts, and admin_init. Start with these.

Concept 2: add_filter() Hook — Transform WordPress Content

What is add_filter()?

Filters are another crucial WordPress code concept. While actions “do something,” filters modify existing data before WordPress displays it.

This is how WordPress lets you transform content, change titles, modify excerpts, and customize output without editing template files.

How to use add_filter():

add_filter('the_content', 'add_reading_time');
function add_reading_time($content) {
    // Only add to single posts
    if (is_single()) {
        $word_count = str_word_count(strip_tags($content));
        $reading_time = ceil($word_count / 200);
        $message = "<p style='background: #e3f2fd; padding: 15px; border-left: 4px solid #2196f3;'><strong>⏱️ Reading time: " . $reading_time . " minutes</strong></p>";
        return $message . $content;
    }
    return $content;
}

This automatically adds reading time to every post. No manual work needed.

How to Test If It’s Working:

1. Add the code to Code Snippets plugin
2. Save and activate
3. Visit any blog post (not page)
4. Look at the top of the content

You should see: A blue box with reading time estimate.

Real-world problems add_filter() solves:

• Add custom content before/after posts automatically
• Modify excerpt length from default 55 words
• Change post titles programmatically
• Filter search results by custom criteria
• Add disclaimers to specific post types
• Customize WordPress login messages

When to use add_filter():

When you need to transform existing content. I use filters to add custom CTAs at the end of my WordPress error fix posts. One filter updates 40+ posts automatically.

More Practical Examples:

Example: Change Excerpt Length

add_filter('excerpt_length', 'custom_excerpt_length');
function custom_excerpt_length($length) {
    return 30; // Change from default 55 words to 30
}

Example: Add Text After Every Post

add_filter('the_content', 'add_cta_after_post');
function add_cta_after_post($content) {
    if (is_single()) {
        $cta = '<div style="background: #fff3cd; padding: 20px; margin-top: 30px; border-radius: 5px;">
            <h3>Need Help with WordPress Errors?</h3>
            <p>Try my <a href="https://ceeveeglobal.com/wp-error-expert/">WP Error Expert Tool</a> - AI-powered error diagnosis!</p>
        </div>';
        return $content . $cta;
    }
    return $content;
}

Key difference: Actions add new functionality. Filters modify existing data. Both are essential WordPress code concepts you’ll use daily.

Concept 3: WP_Query — Custom WordPress Loops

What is WP_Query?

WP_Query is WordPress’s powerful way to fetch posts from the database. It’s one of the most flexible WordPress code concepts for displaying content.

The default WordPress loop shows all posts. WP_Query lets you get specific posts based on any criteria you want — categories, tags, custom fields, dates, and more.

How to use WP_Query:

function display_custom_posts() {
    $args = array(
        'posts_per_page' => 5,
        'category_name' => 'wordpress-errors', // Change to your category slug
        'orderby' => 'date',
        'order' => 'DESC'
    );
    $query = new WP_Query($args);

    if ($query->have_posts()) {
        echo '<div class="custom-posts">';
        while ($query->have_posts()) {
            $query->the_post();
            echo '<div style="margin-bottom: 20px; padding: 15px; border: 1px solid #ddd; border-radius: 5px;">';
            echo '<h3><a href="' . get_permalink() . '">' . get_the_title() . '</a></h3>';
            echo '<p>' . get_the_excerpt() . '</p>';
            echo '<a href="' . get_permalink() . '" style="color: #0073aa;">Read More →</a>';
            echo '</div>';
        }
        echo '</div>';
    } else {
        echo '<p>No posts found.</p>';
    }
    wp_reset_postdata();
}

// Add shortcode to use anywhere
add_shortcode('custom_posts', 'display_custom_posts');

How to Test If It’s Working:

Using Code Snippets Plugin (Recommended):

1. Add the code to Code Snippets plugin
2. Change 'category_name' => 'wordpress-errors' to match your actual category slug
3. Edit any post or page
4. Add this shortcode: [custom_posts]
5. Publish and view the page

You should see: A styled list of 5 posts from that category with borders and read more links.

If you see “No posts found”: Your category slug might be wrong. Go to Posts → Categories and check the actual slug.

Real-world problems WP_Query solves:

• Create custom post grids (like my tools page layout)
• Display posts from specific categories only
• Build “Related Posts” sections based on tags or categories
• Show posts by custom field values
• Create portfolio sections with filtering options
• Display posts from multiple post types

When to use WP_Query:

When the default WordPress loop isn’t flexible enough. I use WP_Query on the homepage to show only featured WordPress error fixes — not all 45+ posts.

Useful WP_Query Parameters:

$args = array(
    'posts_per_page' => 10,        // Number of posts
    'category_name' => 'tutorials', // Category slug
    'tag' => 'beginner',           // Tag slug
    'orderby' => 'date',           // Sort by date
    'order' => 'DESC',             // Newest first
    'post_type' => 'post',         // Post type
    'meta_key' => 'featured',      // Custom field key
    'meta_value' => 'yes'          // Custom field value
);

Important: Always use wp_reset_postdata() after custom queries to avoid conflicts with the main loop. This resets global post data.

Concept 4: WordPress Shortcodes — Reusable Content Blocks

What are WordPress shortcodes?

Shortcodes are reusable code snippets you can insert anywhere using simple brackets. They’re essential WordPress code concepts for creating custom, reusable elements.

Think of shortcodes like creating your own Gutenberg blocks, but lighter and more flexible.

How to use WordPress shortcodes:

add_shortcode('cta_button', 'my_button_shortcode');
function my_button_shortcode($atts) {
    // Set default values
    $atts = shortcode_atts(array(
        'text' => 'Click Here',
        'url' => '#',
        'color' => 'blue'
    ), $atts);
    
    // Return the button HTML
    return '<a href="' . esc_url($atts['url']) . '" style="display: inline-block; padding: 12px 24px; background: ' . esc_attr($atts['color']) . '; color: white; text-decoration: none; border-radius: 5px; font-weight: bold;">' . esc_html($atts['text']) . '</a>';
}

How to Test If It’s Working:

1. Add the code above to the Code Snippets plugin

2. Save and activate

3. Edit any post or page

4. Add this shortcode to the content:

[cta_button text="Try Free Tool" url="https://ceeveeglobal.com/tools/" color="green"]

You should see: A green button with “Try Free Tool” text.

More Shortcode Examples:

Example: Simple Contact Box

add_shortcode('contact_box', 'contact_box_shortcode');
function contact_box_shortcode() {
    return '<div style="background: #f8f9fa; padding: 20px; border-left: 4px solid #007bff; margin: 20px 0;">
        <h3>Need WordPress Help?</h3>
        <p>Contact me: <a href="https://ceeveeglobal.com/contact/">Click Here</a></p>
    </div>';
}

Usage: [contact_box]

Real-world problems shortcodes solve:

• Add custom CTAs without page builders
• Insert contact forms anywhere in content
• Display pricing tables consistently across pages
• Embed custom widgets in posts and pages
• Create reusable content blocks that update globally

When to use shortcodes:

When you need the same element across multiple posts or pages. I use shortcodes for tool promotion boxes in my blog posts. Update one shortcode function, and all posts update automatically.

Shortcodes are perfect for WordPress performance optimization too — they’re lighter than page builder elements and load faster.

Concept 5: wp_enqueue_script() & wp_enqueue_style() — Load Assets Properly

What is wp_enqueue?

These functions represent critical WordPress code concepts for properly loading CSS and JavaScript. Never add scripts directly to header.php or footer.php — always use wp_enqueue.

How to use wp_enqueue properly:

function load_my_assets() {
    // Load CSS
    wp_enqueue_style('my-custom-style', get_stylesheet_directory_uri() . '/custom.css', array(), '1.0.0');
    
    // Load JavaScript with jQuery dependency
    wp_enqueue_script('my-custom-script', get_stylesheet_directory_uri() . '/custom.js', array('jquery'), '1.0.0', true);
}
add_action('wp_enqueue_scripts', 'load_my_assets');

Explanation:

• get_stylesheet_directory_uri() gets your theme’s URL
• array('jquery') means “load jQuery first, then my script”
• '1.0.0' is version number (for cache busting)
• true at the end means “load in footer for better performance”

How to Test If It’s Working:

1. Create a file called custom.js in your theme folder
2. Add this code to it:

jQuery(document).ready(function($) {
    $('body').prepend('<div style="background: yellow; padding: 10px; text-align: center;">Custom JS Loaded!</div>');
});

3. Add the wp_enqueue code above to your functions.php or Code Snippets
4. Refresh your site

You should see: Yellow banner at the top saying “Custom JS Loaded!”

Real-world problems wp_enqueue solves:

• Prevents jQuery conflicts (the #1 WordPress JavaScript error)
• Loads scripts in correct order with proper dependencies
• Avoids loading same script twice (duplicate loading)
• Improves page speed by controlling what loads where
• Makes debugging easier with proper script handles
• Enables conditional loading (only load on specific pages)

Conditional Loading Example:

function load_my_assets() {
    // Only load on homepage
    if (is_front_page()) {
        wp_enqueue_script('homepage-slider', get_stylesheet_directory_uri() . '/slider.js', array('jquery'), '1.0.0', true);
    }
    
    // Only load on single posts
    if (is_single()) {
        wp_enqueue_style('single-post-style', get_stylesheet_directory_uri() . '/single-post.css');
    }
}
add_action('wp_enqueue_scripts', 'load_my_assets');

When to use wp_enqueue:

Always. This is not optional for WordPress development. If you’re adding CSS or JavaScript to WordPress, use wp_enqueue_style() and wp_enqueue_script(). Period.

I use wp_enqueue to load my custom scripts only on pages that need them. My WordPress Plugin Finder tool loads specific JavaScript — not on every page. This keeps the site fast.

Common mistake: Loading scripts in wp_head action. Use wp_enqueue_scripts action instead for proper loading. Need help debugging JavaScript errors? Check my WordPress Error Log guide.

Concept 6: Custom Post Types — Organize Content Better

What are custom post types?

Custom post types are powerful WordPress code concepts that let you create your own content types beyond default posts and pages.

Think of custom post types as adding new categories of content with their own admin menus, templates, and archive pages.

How to create custom post types:

function create_tools_post_type() {
    $args = array(
        'labels' => array(
            'name' => 'Tools',
            'singular_name' => 'Tool',
            'add_new' => 'Add New Tool',
            'add_new_item' => 'Add New Tool',
            'edit_item' => 'Edit Tool'
        ),
        'public' => true,
        'has_archive' => true,
        'supports' => array('title', 'editor', 'thumbnail', 'excerpt'),
        'menu_icon' => 'dashicons-admin-tools',
        'rewrite' => array('slug' => 'tools'),
        'show_in_rest' => true  // Enables Gutenberg editor
    );
    
    register_post_type('tools', $args);
}
add_action('init', 'create_tools_post_type');

How to Test If It’s Working:

1. Add the code above to Code Snippets plugin

2. Save and activate

3. Go to WordPress Admin Dashboard

4. Go to Settings → Permalinks (IMPORTANT!)

5. Click “Save Changes” (this flushes rewrite rules)

6. Look in the left sidebar

You should see: A new “Tools” menu item with “Add New Tool” option.

If you get 404 errors:You forgot step 4-5. Always flush permalinks after registering custom post types. Read my WordPress 404 Error guide for more solutions.

Real-world problems custom post types solve:

• Build portfolio sections separate from blog posts
• Create testimonial systems with custom fields
• Add product showcases for services or digital products
• Organize different content types (like my AI tools collection)
• Keep blog posts and other content completely separate
• Create custom taxonomies for better organization

When to use custom post types:

When posts and pages aren’t enough for your content structure. My AI tools collection uses custom post types. Each tool has its own entry, separate from blog posts.

Pro tip: After registering custom post types, always go to Settings → Permalinks and click “Save Changes” to flush rewrite rules. Otherwise, you’ll get 404 errors on your custom post type pages.

Concept 7: WordPress REST API — Access Data Anywhere

What is WordPress REST API?

The WordPress REST API is one of the most modern WordPress code concepts. It lets you access your WordPress content via URLs that return JSON data.

Think of it as opening a window into your WordPress database from anywhere — mobile apps, external websites, JavaScript applications.

How to use WordPress REST API:

You don’t need to write code to use REST API. Just access these URLs in your browser:

Get all posts:

https://yoursite.com/wp-json/wp/v2/posts

Get 5 posts from specific category:

https://yoursite.com/wp-json/wp/v2/posts?per_page=5&categories=12

Search posts:

https://yoursite.com/wp-json/wp/v2/posts?search=wordpress

How to Test If It’s Working:

1. Replace yoursite.com with your actual domain
2. Try this URL in your browser:

https://ceeveeglobal.com/wp-json/wp/v2/posts?per_page=3

You should see: JSON data with post information (title, content, excerpt, etc.)

Common REST API Parameters:

• per_page: Number of posts to return (default: 10)
• categories: Filter by category ID
• tags: Filter by tag ID
• search: Search posts by keyword
• orderby: Sort by date, title, modified, etc.
• order: ASC (ascending) or DESC (descending)
• page: Pagination for large datasets

Using REST API in JavaScript:

fetch('https://yoursite.com/wp-json/wp/v2/posts?per_page=5')
    .then(response => response.json())
    .then(posts => {
        posts.forEach(post => {
            console.log(post.title.rendered);
        });
    });

Real-world problems REST API solves:

• Build headless WordPress sites (WordPress backend, custom React/Vue frontend)
• Create mobile apps that pull WordPress content
• Fetch data for JavaScript applications without page reload
• Integrate WordPress with external services and platforms
• Display WordPress posts on non-WordPress pages
• Build custom dashboards that pull WordPress data

When to use REST API:

When you need WordPress data outside WordPress itself. I use REST API to power some of my FastAPI tools that interact with WordPress data programmatically.

Security note: WordPress REST API is public by default. For sensitive data, use authentication. Most sites disable /wp-json/wp/v2/users endpoint for security. Learn more in my WordPress Security Audit guide.

Concept 8: WordPress Transients — Built-in Caching

What are WordPress transients?

Transients are WordPress’s built-in caching system — one of the most underrated WordPress code concepts for performance optimization.

They provide temporary data storage with automatic expiration. No Redis, Memcached, or external caching plugins required.

How to use WordPress transients:

function get_popular_posts() {
    // Try to get cached data
    $popular_posts = get_transient('my_popular_posts');
    
    // If no cache exists or expired
    if ($popular_posts === false) {
        // Run expensive query
        $args = array(
            'posts_per_page' => 10,
            'meta_key' => 'post_views',
            'orderby' => 'meta_value_num',
            'order' => 'DESC'
        );
        $popular_posts = new WP_Query($args);
        
        // Store in cache for 1 hour (3600 seconds)
        set_transient('my_popular_posts', $popular_posts, 3600);
    }
    
    return $popular_posts;
}

How to Test If It’s Working:

Add this code to test transient speed:

function test_transient_speed() {
    // First load (no cache)
    delete_transient('test_data');
    $start = microtime(true);
    $data = get_transient('test_data');
    if ($data === false) {
        sleep(2); // Simulate slow query
        $data = "Slow data loaded";
        set_transient('test_data', $data, 3600);
    }
    $first_load = microtime(true) - $start;
    
    // Second load (from cache)
    $start = microtime(true);
    $data = get_transient('test_data');
    $second_load = microtime(true) - $start;
    
    echo "First load: " . round($first_load, 4) . " seconds<br>";
    echo "Second load: " . round($second_load, 4) . " seconds<br>";
    echo "Speed improvement: " . round($first_load / $second_load) . "x faster";
}
add_action('wp_footer', 'test_transient_speed');

You should see: First load takes ~2 seconds, second load is almost instant (0.0001 seconds).

Real-world problems transients solve:

• Speed up slow database queries dramatically
• Cache external API responses (like OpenAI, Google APIs)
• Reduce server load on high-traffic WordPress sites
• Improve page load times without complex caching plugins
• Store temporary data without creating custom database tables
• Cache RSS feeds, social media data, weather info

When to use transients:

When you have expensive operations that don’t change frequently. My WP Error Expert tool caches AI responses using transients. Same error searched twice? Instant results from cache instead of calling the API again.

Practical Caching Example:

function get_latest_tools() {
    $tools = get_transient('latest_tools_cache');
    
    if ($tools === false) {
        $args = array(
            'post_type' => 'tools',
            'posts_per_page' => 10,
            'orderby' => 'date',
            'order' => 'DESC'
        );
        $query = new WP_Query($args);
        $tools = $query->posts;
        
        // Cache for 6 hours (21600 seconds)
        set_transient('latest_tools_cache', $tools, 21600);
    }
    
    return $tools;
}

I once reduced a page load time from 8 seconds to 1.2 seconds just by caching one slow WP_Query with transients. That’s the power of proper caching.

Important: Transients are stored in wp_options table by default. For high-traffic sites, use persistent object caching (Redis) for better performance. Check my WordPress Performance Analyzer to see if you need it.

Mastering WordPress Code Concepts: Quick Reference Guide

Here’s a cheat sheet for choosing the right WordPress code concept for your needs:

Save this table. You’ll reference it constantly when building WordPress sites.

How to Practice These WordPress Code Concepts

Understanding WordPress code concepts is one thing. Actually using them is different.

Here’s my recommended learning path:

Week 1: Master WordPress Hooks

• Create one add_action() to add visible content to footer
• Create one add_filter() to modify post content
• Break something, then fix it (seriously, this teaches you)

Week 2: Work with Data

• Build a custom post grid using WP_Query
• Create a simple shortcode for a CTA button
• Test different query parameters

Week 3: Asset Management & Custom Content

• Properly enqueue one CSS file and one JS file
• Register a simple custom post type
• Understand the loading order

Week 4: Advanced Concepts

• Test REST API endpoints on your site
• Implement transient caching on one slow query
• Measure the performance improvement

Don’t try to learn all 8 WordPress code concepts at once. Master one per week. That’s how I learned, and that’s what works.

Common WordPress Code Mistakes to Avoid

After teaching these WordPress code concepts for years, I’ve seen the same mistakes repeatedly:

1. Editing parent theme files directly Always use child themes. Theme updates wipe your changes otherwise. Learn how to create a child theme properly.

2. Forgetting wp_reset_postdata() after WP_Query This causes weird bugs with your main loop. Always reset. I’ve spent hours debugging this mistake.

3. Not sanitizing shortcode attributes Use esc_url(), esc_attr(), and esc_html() to prevent security issues. Never trust user input.

4. Loading scripts without dependencies If your script needs jQuery, specify it: array('jquery'). Otherwise, you’ll get “$ is not defined” errors.

5. Not setting transient expiration Without expiration, transients become permanent database clutter. Always set a reasonable expiration time.

6. Hardcoding instead of using WordPress functions Use get_template_directory_uri() instead of hardcoded paths. Your code will break when you change themes.

7. Not flushing permalinks after custom post types Register a custom post type, then go to Settings → Permalinks → Save. Otherwise, you’ll get 404 errors.

Learn from my mistakes. I’ve made all of these errors and spent hours debugging them.

Tools to Help You Learn WordPress Code Concepts

You don’t have to learn these WordPress code concepts alone. Here are tools that helped me:

1. Code Snippets Plugin — Practice WordPress code safely without editing functions.php directly. If something breaks, just disable the snippet. No White Screen of Death. Download from WordPress.org

2. Query Monitor Plugin — See exactly which hooks fire, database queries run, and where your code slows down. Essential for learning WordPress code concepts. Shows every SQL query, PHP error, and HTTP request.

3. WordPress Code Reference — Official documentation at developer.wordpress.org. Search any function, hook, or class. Bookmark it.

4. My AI-Powered WordPress Tools:

• WordPress Plugin Finder — Find plugins by functionality
• WP Error Expert — AI-powered error diagnosis using my knowledge base
• WordPress Performance Analyzer — Analyze Core Web Vitals and get optimization tips

These tools use the same WordPress code concepts I just taught you. Study how they work.

5. Local Development Environment — Test code on your computer before deploying live. I use Local by Flywheel. Watch my Local by Flywheel tutorial to set it up.

Conclusion: Your WordPress Code Concepts Journey Starts Now

These 8 WordPress code concepts power every WordPress site you’ve ever used — from simple blogs to WooCommerce stores to complex membership sites.

Understanding these fundamental WordPress code concepts transforms you from someone who installs plugins to someone who builds solutions. That’s the difference between WordPress users and WordPress developers.

You don’t need to master all 8 WordPress code concepts today. Start with add_action() and add_filter() — they’re the foundation everything else builds on.

Here’s your action plan:

This week: Try adding one action hook with visible output (like the footer text example)
Next week: Create a simple filter to add reading time to posts
Week 3: Build something custom with WP_Query
Week 4: Start exploring REST API and transients

I learned these WordPress code concepts by breaking things. You will too. That’s okay. Just keep your backups current and learn from every error.

Pro tip from 15 years of WordPress experience: Use the Code Snippets plugin instead of editing functions.php directly. It’s safer, easier to debug, and you can disable snippets without deleting code.

Don’t forget to set up backups before experimenting. Watch my video: Stop Paying for Backup Plugins – Build Your Own with AI in 15 Minutes. I’ll show you exactly how to create a custom backup system that costs $0.

These WordPress code concepts are your foundation. Build on them, experiment with them, break things and fix them. That’s how you become a real WordPress developer.

Which WordPress code concept are you trying first? Drop a comment below. I read every single one and reply with help if you’re stuck. Let’s build something together.

Frequently Asked Questions About WordPress Code Concepts

What are the most important WordPress code concepts for beginners?

The most important WordPress code concepts for beginners are add_action() and add_filter() hooks. These two WordPress code concepts form the foundation of WordPress development. Master hooks first, then move to WP_Query, shortcodes, and wp_enqueue functions. Start with actions and filters — everything else builds on understanding how WordPress hooks work.

What’s the difference between add_action and add_filter in WordPress?

add_action() adds new functionality at specific WordPress events, while add_filter() modifies existing data before display. Actions “do something” (add tracking code, send emails), filters “change something” (modify post content, change titles). Both are essential WordPress code concepts, but serve different purposes. Use actions to insert new features, use filters to transform existing content.

Do I need to edit functions.php to use WordPress code concepts?

No, you don’t have to edit functions.php directly. Use the Code Snippets plugin for safer WordPress code management, or create a custom plugin. Only edit functions.php if you’re using a child theme. Never edit parent theme files — updates will erase your changes. Code Snippets is the safest way to practice WordPress code concepts without risking your site.

Which WordPress code concepts should I learn first?

Learn WordPress code concepts in this order: 1) add_action() and add_filter() hooks (foundation), 2) WP_Query for custom loops, 3) wp_enqueue for loading assets properly, 4) shortcodes for reusable content, 5) custom post types, 6) REST API, and 7) transients. Master hooks first — they’re used in all other WordPress code concepts and understanding them makes everything else easier.

Can WordPress code concepts break my site?

Yes, syntax errors in WordPress code can cause the White Screen of Death. Always backup before adding custom code. Use a child theme or Code Snippets plugin. Test on staging sites first. One missing semicolon can break everything. Learn proper WordPress code concepts to avoid common mistakes and keep your site safe. Read my White Screen of Death guide for recovery steps.

How do WordPress hooks work with themes and plugins?

WordPress hooks (actions and filters) work the same in themes and plugins. They’re core WordPress code concepts that let themes and plugins interact with WordPress without modifying core files. Plugins use hooks to add features, themes use hooks to modify display. Both follow the same WordPress code concepts and execution order. Hooks are the standard way to extend WordPress functionality.

What are WordPress transients used for?

WordPress transients cache temporary data with automatic expiration. Use transients to cache slow database queries, external API responses, or expensive calculations. Transients are essential WordPress code concepts for performance optimization. They reduce server load and speed up sites without external caching plugins. Set appropriate expiration times — I use 1 hour for frequently updated data, 24 hours for static content.

How does WP_Query differ from the default WordPress loop?

WP_Query gives you complete control over which posts display, while the default loop shows all posts. WP_Query is one of the most flexible WordPress code concepts — filter by category, tag, custom fields, dates, post types, and more. Use WP_Query when the default loop isn’t flexible enough. Always use wp_reset_postdata() after custom queries to avoid conflicts with the main loop.

How can I test if my WordPress code is working?

Test WordPress code by adding visible output first. Use echo statements with HTML and CSS styling so you can see results immediately. Don’t use console.log() for initial testing — it’s invisible unless you open browser Developer Console. Start with simple examples like adding colored text or borders. Once you confirm code works, then optimize it. Check my WordPress Error Log guide for debugging tips.

Are WordPress code concepts the same across all WordPress versions?

Core WordPress code concepts (hooks, WP_Query, shortcodes, wp_enqueue) have been stable for years and work across all modern WordPress versions. However, newer features like REST API and Gutenberg support require WordPress 4.7+ and 5.0+ respectively. Always check WordPress documentation for version-specific features. These fundamental WordPress code concepts you learned will work on any WordPress site running version 4.0 or newer.

The post 8 Essential WordPress Code Concepts Every Beginner Should Master (With Real Examples) appeared first on The Beginner’s Playbook for Fixing WordPress Errors.

Why did I create an AI chatbot for my website?

Users coming to my website come from different countries. Their arrival times vary depending on the countries they live in. So if I go to chat with them, I have to put my life under my website.

I wanted to overcome that barrier and provide instant responses to user queries, improving engagement and satisfaction.

It also allowed me to increase my website’s efficiency, automate repetitive tasks, and free up time for more complex issues. Plus it allowed me to increase conversions.

How would you like to be able to go to a website and get instant answers to your questions without waiting for someone to respond?

Basically, that is the main task an AI chatbot can do for your website!

Hence, AI chatbots are becoming a must for any website. That’s because it can accomplish tasks ranging from improving user experience to improving website efficiency and increasing conversions.

Here, I will introduce you to the steps to create a similar or more improved AI chatbot for your website. You can try using the click icon on the bottom right of this page.

By adding an AI chatbot to your website, you can:

Improving user experience

The biggest advantage of an AI chatbot is that it can give very accurate answers to user queries instantly. Imagine a user lands on your website in the middle of the night with a question. A chatbot can provide an immediate response instead of waiting for someone to get back to them. This will make your website more attractive and make your visitors happy.

Increasing efficiency

By automating repetitive tasks, an AI chatbot saves you time. Think about it. Instead of answering the same questions over and over again, you can do it through your chatbot. This allows you to focus on the more complex and important tasks of your website.

Increase conversions

AI chatbots can guide users through your website, helping them find what they’re looking for faster. This can lead to more sales, signups, or whatever else your website may be aiming for and have a positive impact.

In this guide, I’ll walk you through everything you need to know to build your own AI chatbot and integrate it into your WordPress site.

Understanding AI Chatbots: The Core Structure

Before we dive into the technical aspects, it is essential to understand the basic structure of an AI chatbot. It will be very useful for you while building or improving this chatbot.

Key components of an AI chatbot

User Interface (UI): The visual part through which users interact with the chatbot. This is shown in the image above.

Backend: Server-side logic that processes user input and generates responses.

AI Integration: The chatbot’s brain is powered by models like OpenAI.

Overview of how it works

Chatbots capture user input, send it to the backend, where AI processes it, and then displays the response to the user on the frontend.

Step-by-step guide to building your AI Chatbot

Now that you have a basic understanding of AI Chatbot, let’s start building your Chatbot.

I will guide you step by step. Follow these steps very carefully. I have used PHP, HTML, CSS, and JavaScript for this process. Don’t worry I’m not an expert in these things like you. But you can make this process very easy by using ChatGPT or Claude as a support.

However, I am providing all the codes you need here.

AI Chatbot For WordPress

Creating a Chatbot UI

First impressions are the foundation of anything. A good-looking chatbot makes a big difference to your website. Here’s how to design a simple yet attractive chatbot interface.

Essential UI elements

Chat Box: This is where the conversation happens. It shows the chat history between the user and the chatbot.

Input Field: Allows users to type their messages here.

Send Button: This is used to send the message to the chatbot.

To create this UI, you will use HTML and CSS. You can download all related files below.

After entering the AI-chatbot folder, you can see two folders: front and back. Go inside the front folder. There are 4 files as shown below.

Here the chatbot.html file contains everything. But the Index.html, script.js, and style.css files contain only the related things. From there you can use these files appropriately.

Either way, open chatbot.html or Index.html in your browser. Then you will see the chatbot as below.

But you still can’t chat with this.

Set up Chatbot code in the backend

Now that your UI is ready, it’s time to access the code that will make your chatbot work.

1. Install and activate WPCode Lite.

2. Paste the code in the back folder here. Note, the Code Type should be changed to PHP Snippet.
3. Connecting the OpenAI API Key.
   Register on the OpenAI website and get an OpenAI API key. Because our chatbot is powered by the OpenAI API.  Keep this confidential. Next, enter the OpenAI API key in the snippet and save the snippet.

Linking the UI with the backend

Now that your front and back panels are ready, it’s time to connect them together. This is where JavaScript comes into play.

Now open the script.js file in the front folder. You can use Notepad for this. Go there and update your domain name and save the file.

Eg: replace https://YourWebsite.com with your site domain name.

If you did everything correctly, now you just have to open the index.html file again. To your surprise, your chatbot will work like the image below.

Advanced Customisation: Taking Your Chatbot to the Next Level

This chatbot is designed to suit my site. That is, only matters related to WordPress can be chatted through this chat button. When asked about a matter not related to WordPress, it replies, “I am trained to assist with WordPress-related questions. Feel free to ask me anything about WordPress”.

So, how to customise this chatbot for you?

System Prompt Customisation

Customising your AI chatbot’s system prompt is essential to ensure it aligns with the specific needs of your website and the type of interaction you want to have with your users. So here’s how to adjust your system prompt to suit different websites:

1. Understand the purpose of your website

Identify the primary function of your website. Is it an e-commerce site, a blog, a tech support platform or a content-driven site? Your chatbot’s system prompt should reflect the primary purpose and type of queries users might have.

2. Define the scope of the interaction

Clearly state the purpose for which your chatbot is designed. For example, if your website focuses on e-commerce, chatbots can assist with product inquiries, order tracking, or product recommendations. The scope should be narrow enough to keep the chatbot focused but broad enough to handle common user needs.

3. Crafting the System Prompt

Change the language and focus of the system prompt based on the context of the site. Here’s how you can adjust the provided trigger for different types of websites:

Example 1: E-commerce Website:

You are a knowledgeable shopping assistant on our online store. Your task is to help users find products, answer questions about orders, provide product recommendations, and assist with any inquiries related to our store. Engage users in friendly conversations to enhance their shopping experience. Do not respond to questions unrelated to shopping or our products. If asked, politely state that you are here to assist with shopping-related queries.

Example 2: Tech Support Website

You are a tech support specialist. Your task is to help users troubleshoot technical issues, provide guidance on software and hardware products, and assist with inquiries related to our tech support services. Engage users in problem-solving conversations to resolve their technical problems. Do not respond to questions outside of tech support. If asked, politely inform them that you specialize in providing tech support assistance.

Example 3: Blog or Content-Focused Website

You are an expert content guide for our website. Your task is to help users find articles, explain content topics, suggest related posts, and assist with any questions about our blog content. Engage users in informative conversations to enrich their reading experience. Do not respond to questions unrelated to our content. If asked, gently redirect them to the relevant blog topics.

Example 4: Educational Platform

You are an educational assistant for our online learning platform. Your task is to help users navigate courses, answer questions about course content, provide study tips, and assist with any inquiries related to learning on our platform. Engage users in supportive conversations to enhance their learning journey. Do not respond to questions outside of education-related topics. If asked, kindly direct them to the appropriate course material.

4. Enter the brand identity

Make sure the tone and style of the prompt aligns with your brand’s voice. If your brand is casual and fun, the query should reflect that. For a more professional brand, use formal and precise language.

5. Test and Iterate

After customizing your system prompt, test it with real user interactions to see if it meets the intended objectives. Gather feedback and make adjustments as needed to fine-tune the chatbot’s performance.

By customizing your chatbot’s system prompts, you can ensure that it provides relevant, useful and on-brand responses, making your website’s user experience more engaging and effective.

After you prepare your prompt, go to “Add the last prompt to the conversation history” in the Backend Snippet and enter the prompt you prepared.

Then save the code snippet. Depending on the success of your prompting, the output of your chatbot will be successful.

Icon Customization

But your chatbot still has the same icon as my chatbot. Let’s change that too.

Go to “load_chat_bot_base_configuration” and change your user_avatar_url and bot_image_url to the icon you require.

Other minor changes

You can change the Startup Message to suit you. You can also change the font size and commonButtons of your chatbot.

Final Steps: Publishing Your Chatbot on WordPress

Now you can integrate your chatbot into your WordPress website pages.
For that, we are again asking for help in the code snippet.

Go to Header and Footer in the code snippet. Go there and paste the full code, HTML, CSS, and JavaScript, in the footer.

Bonus Tip: If you run into any WordPress errors while setting up your chatbot, don’t worry. My WP Error Expert AI tool can help you fix many errors easily. And if you’re a web developer, check out my other AI tools designed to make your life easier.

Conclusion

In conclusion, integrating an AI chatbot into your WordPress site can significantly enhance user experience, increase efficiency, and drive conversions.

By automating responses to common queries, an AI chatbot ensures that visitors receive instant support, no matter the time of day.

This guide provides a comprehensive, step-by-step process to build and customize an AI chatbot that aligns with your website’s specific needs, whether it’s for e-commerce, tech support, content guidance, or education.

By following these steps, you can create a chatbot that improves customer satisfaction and optimizes your website’s performance, ultimately leading to better engagement and outcomes.

AI Chatbot For WordPress

The post How to Build and Integrate an AI Chatbot into Your WordPress Site: A Complete Guide appeared first on The Beginner’s Playbook for Fixing WordPress Errors.