Fixing AI Agent Compatibility on a WordPress Site

Why WordPress sites trip agents up

WordPress core produces clean HTML. The block editor's own blocks, the default themes and the core Navigation block all follow accessibility guidance reasonably well. Agents run into trouble with what gets added on top, and a typical small business site has a lot on top: a page builder, a form plugin, a booking or appointment plugin, a cache and optimisation plugin, a cookie consent plugin, a security plugin and often WooCommerce with its own extensions.

Each of those plugins produces its own markup and loads its own scripts. Each one was built and configured with human visitors in mind, and each has settings that make it more or less usable by software acting for a person. An AI agent that is booking an appointment, asking for a quote or buying something moves through several of them in one visit, so a single badly configured plugin can end the task.

The good news is that most fixes are settings, not code. Where code is needed it is usually a small change to a form template or a line in the cache plugin's exclusion list.

Plugin by plugin: what to check

Form plugins

Forms are how a service business gets enquiries, so this is usually the most valuable fix. An agent fills a form by matching each field to what it knows: name, email, phone, the service wanted, the preferred date. It relies on the field's label to do that. A form that uses placeholder text inside the box instead of a label, which many themes and form styles do to look tidy, leaves the agent guessing.

Contact Form 7

Contact Form 7 builds forms from a text template, so labels are only there if the template includes them. The pattern below wraps each field in a label, which is the simplest reliable form:

<label> Your name
    [text* your-name autocomplete:name] </label>

<label> Email address
    [email* your-email autocomplete:email] </label>

<label> Phone number (optional)
    [tel your-phone autocomplete:tel] </label>

<label> What do you need help with?
    [select your-service "Boiler service" "Boiler repair" "New installation"] </label>

[submit "Send enquiry"]

If your version of Contact Form 7 does not accept the autocomplete option, leave it out; the labels matter more.

Gravity Forms, WPForms, Fluent Forms and Elementor Forms

These builders create labels from the field name you type, which is good. Check two settings. First, label visibility: some options hide the label visually but keep it in the HTML, which is fine, while others remove it altogether and leave only a placeholder. View the page source and check a <label> element is still there for each field. Second, field names: a field called "Field 3" or "Untitled" produces a label of "Field 3". Rename every field to what it asks for.

Spam protection

Score-based checks such as Google reCAPTCHA v3 and Cloudflare Turnstile run invisibly. When they judge a visitor to be automated, the form may fail with a vague "there was an error" message or, worse, appear to send while the plugin quietly discards it. A genuine agent working for a customer can be marked as automated because, strictly, it is. Test the form with an agent and check the submission arrives. If it does not, consider a honeypot field, which most form plugins offer, as your first line of defence, and keep the heavier challenge for forms that attract a lot of spam.

Booking and appointment plugins

Booking is a task people increasingly hand to an agent, and booking plugins are some of the hardest pages for agents to use. Many draw their calendar and time slots with JavaScript as a grid of boxes, with the date shown only as a number inside each box and availability shown only by colour.

What an agent needs from a booking step is simple: controls it can identify and operate, with names that say what they are.

<!-- Hard to use: a number in a box, availability shown by colour -->
<div class="day available">14</div>

<!-- Usable: a button whose name gives the full date and status -->
<button type="button" aria-label="Tuesday 14 October, 3 slots available">14</button>
<button type="button" aria-label="Wednesday 15 October, fully booked" disabled>15</button>

You usually cannot change a booking plugin's markup yourself, so the practical route is:

1. Check the plugin's settings for an accessible or list view. Several plugins can show available times as a list of buttons rather than a calendar grid, which agents and keyboard users both find easier.
2. Try booking with only the keyboard. If you cannot tab to a date and choose it with Enter, an agent will struggle too. Report it to the plugin developer with the details; accessibility fixes help every customer of theirs.
3. Offer a second route. A short, well-labelled "request an appointment" form with a preferred date and time lets an agent make the request even when the calendar defeats it. Link to it from the booking page.
4. Keep the booking page at its own address. If the booking widget is inside a pop-up on the home page, give it a dedicated page so an agent can be sent straight there.

Page builder menus and delayed scripts

Menus that only open on hover

Hover is something a mouse does and an agent often does not. A sub-menu that appears only on hover may never be seen, and on touch-sized viewports some builder menus rely on a tap handler that agents do not always trigger. The core Navigation block has a setting under its submenu options to open submenus on click, and in that mode it uses a button with aria-expanded, which agents understand. Elementor's Nav Menu, Divi's menu module and mega menu plugins have their own settings for click or hover. Choose click where the option exists, and make sure every top-level item that has a sub-menu is also a real link to a page listing its children. The navigation guide goes into the patterns in detail.

Delayed JavaScript from cache plugins

Performance plugins including WP Rocket, LiteSpeed Cache, Perfmatters and FlyingPress can delay loading scripts until the visitor first moves the mouse, scrolls, touches the screen or presses a key. It is a popular way to improve lab speed scores. The side effect is that anything depending on those scripts, such as a mobile menu toggle, a form's validation, a booking calendar or an add to cart button that uses script, does nothing until that first interaction. A person barely notices. An agent that clicks the menu button as its first action may see nothing happen, decide the control is broken and try something else.

The fix is not to turn the feature off everywhere but to exclude the scripts your journeys depend on. Each plugin has an exclusion list where you enter part of a script's file path or a keyword, for example the folder name of your form or booking plugin, or your theme's navigation script. After excluding them, clear the cache and test the menu and form on first load without touching anything else.

The fix, step by step

Cookie banners and WooCommerce

Cookie banners

In the UK, PECR as amended by the Data (Use and Access) Act 2025 still generally requires consent before non-essential cookies are set, so a consent banner is often needed. This is not legal advice, and your own obligations depend on what the site sets. From an agent's point of view the design matters more than the plugin. A banner that sits at the bottom of the screen with two plainly named buttons is quick to answer. A full-screen wall with a single "Manage" link leading to a panel of toggle switches is slow and error-prone, and an agent may refuse to make a privacy choice on the person's behalf and stop to ask.

WooCommerce

WooCommerce is used differently from Shopify because you control the whole checkout. Newer installs use the Cart and Checkout blocks, which are built with labelled fields and autocomplete attributes. Older sites may still use the shortcode checkout with a theme template on top, where field labels and error messages vary. Points to check:

• Guest checkout is a setting under Accounts and Privacy. Forced accounts are the step most likely to stop an agent.
• Extensions that add checkout fields, such as delivery date pickers and gift options, should add labelled fields and keep them optional.
• Payment gateways usually take over in an embedded frame or a separate page. That is where the agent hands back to the customer, and it should be.
• Stock and price should be in the product page HTML, not loaded later by a variation script, so an agent that reads the page gets the right answer. The checkout guide covers the rest of the hand-over.

Keeping it working after updates

• Test after plugin updates to your form, booking, page builder and cache plugins. Updates can reset settings or change markup.
• Keep changes on staging first. A staging copy lets you try a menu or delay setting without affecting customers.
• Write down your exclusions. A note of which scripts you excluded from delayed loading, and why, stops a future speed tweak undoing the fix.
• Check new forms before publishing. Label every field and submit a test before linking the form anywhere.
• Re-run the audit on your enquiry and booking pages each quarter and after any theme change.