TL;DR
- The plugin directory shows tens of thousands of options, and the compatibility flag is, by the WordPress Codex’s own admission, voluntary — a flag, not a verdict. Top-ten listicles rank against a generic site. Neither knows your specific stack, your PHP version, or your managed host’s disallowed-plugins list.
- AI-checked compatibility means feeding an AI chat your use case in one sentence, your plugin list with versions, your WordPress and PHP versions, your hosting tier, plus two or three candidate plugins’ metadata. Output is a ranked shortlist with explicit conflict flags — the install decision stays with you.
- The five-step build runs about ninety minutes. Inventory your stack in three lines, name the use case in one sentence, paste candidate metadata, ask for one ranked output, and verify the top one or two in staging using the Health Check Troubleshooting Mode that WPBeginner’s December 2025 guide names as the standard conflict-detection step.
- Three traps. Letting the chat ignore your managed host’s disallowed list — WP Engine’s public list names over fifty actively blocked plugins. Trusting the directory’s compatibility flag at face value when the Codex itself flags it as voluntary. Skipping the staging install on the chat’s word — Odd Jar’s March 2026 piece names six conflict patterns metadata cannot show alone.
- The plugin worth installing is not the plugin everyone recommends. The plugin worth installing is the one that fits your stack, your hosting, and the one-sentence use case you wrote down at the top.
A nonprofit director picked a backup plugin on a Saturday morning. Top of every listicle. Five-star average. Two hundred thousand active installs. By Sunday afternoon her staging URL returned a white screen, and her actual backup window had moved from automatic to Wednesday.
The plugin was excellent. It also did not fit her stack.
The shortlist she needed was different from the one Google handed her. Not the best backup plugin in the world. The best backup plugin for her plugin stack, her PHP version, and her managed host’s allowlist.
This piece is about how an AI chat builds that shortlist for you in about ninety minutes. The second half is about how to read its output without trusting it more than you should.
Why is picking a WordPress plugin so hard right now?
The plugin directory holds tens of thousands of options. Each one shows a small Compatibility widget on its page. The numbers behind that widget are, by the WordPress Codex’s own admission, voluntary — contributed by whoever bothered to test the plugin and report back.
A widget that depends on volunteer reporting is not a verdict.
For a popular forms or backups plugin with five hundred thousand installs, the widget is broadly accurate. For the niche caching, membership, or page-builder plugin that solves your exact need, the widget often shows two votes from 2024 and nothing for 2026. Is that the verdict your decision needs? Probably not.
Top-ten listicles are the next instinct. Their problem is the opposite. They rank plugins against a generic site, not yours.
The site you maintain has a specific WordPress version, a specific PHP version, a specific page builder, and a specific managed host. None of those are accidents. They are all reasons your site exists where it does. A generic top-ten cannot rank against any of them.
Then there is the managed-host layer. WP Engine publishes a disallowed-plugins list naming over fifty specific plugins it actively blocks. Six categories run from caching plugins that fight its built-in cache to related-posts plugins it labels database-intensive. Other managed hosts maintain similar lists, less publicly. If you install a disallowed plugin on the wrong host, your dashboard will not warn you in advance.
The decision the reader is making is more constrained than the listicle pretends. The shortlist needs to know the constraints first.
What does AI-checked compatibility actually do?
AI-checked compatibility is a small, repeatable workflow. Five minutes per candidate plugin, plus the eighty-five minutes of staging install for the one or two that pass.
Think of it as a sommelier who already knows what is on your table. The sommelier does not pick the best wine in the world. The sommelier picks the best wine for tonight’s meal, given what is already paired. The same kind of work fits the plugin choice in front of you.
You give an AI chat your use case in one sentence. A forms plugin for a small-business contact form, with spam protection, perhaps. You add your active plugin list with versions, your WordPress version, your PHP version, and your hosting tier. A four-line block is enough. No formal structure needed.
Then you paste the candidate plugin’s metadata — its readme content, its last-updated date, its tested-up-to flag, and the first paragraph of its changelog. Two to three candidates is enough. Eight is performance theater.
You ask for one specific output. Two or three candidate plugins ranked by fit-score against your stack. One explicit conflict flag per candidate. A one-line reason-to-reject for each non-shortlisted option.
The chat does the matching. It does not make the install decision.
How do you build the shortlist in one sitting?
The work splits into five steps. None of them needs a developer. The longest step is the staging install in step five.
Step 1 — inventory your stack in three lines. Open a text file. Paste your active plugin list — the single column you can copy from Plugins, Installed Plugins. Add your WordPress version from Tools, Site Health, Info. Add your PHP version from the same screen. Add the name of your managed host, or self-hosted on a VPS if you are not on a managed host. Stop at three or four lines. The chat does not need more.
Step 2 — name the use case in one sentence. A backup plugin that runs nightly and stores off-site, perhaps. Or a forms plugin with conditional logic and spam filtering. The sentence sets the priority order. Do not list ten requirements. List the one or two that matter.
Step 3 — paste candidate metadata. Pull two to three candidate plugins from the directory. Copy each one’s short description, last-updated date, tested-up-to version, and the first paragraph of the changelog. Skip the marketing copy. The chat does not need to read what the plugin’s homepage thinks of itself.
Step 4 — ask for one ranked output. A specific prompt works better than a vague one. Ask for the candidates ranked by fit-score against your stack, one explicit conflict flag per candidate, and a one-line reason-to-reject for each non-shortlisted option. State your priorities in plain English — weight support response above feature breadth, for example. The output lands in seconds.
Step 5 — verify in staging. The shortlist tells you which one or two plugins to install in staging. WPBeginner’s December 2025 guide names the Health Check Troubleshooting Mode as the standard conflict-detection step. The Mode runs in a private user session, disabling every other plugin for you while live visitors continue to see the site normally. Twenty minutes per candidate is plenty.
The full cycle costs about ninety minutes of your time. None of those minutes happen on a Sunday during a backup-window emergency.
What can go wrong with this approach?
Three traps catch operators on a deadline.
Trap 1 — letting the chat ignore your managed host’s disallowed list. WP Engine’s published list names over fifty plugins it actively blocks. Most of the popular caching plugins are on it. A long roster of database-intensive related-posts plugins is on it too. The chat does not know that list unless you paste it.
Add the line “my host is WP Engine” to the inventory. Ask the chat to cross-reference the public disallowed-plugins list. If you are on Kinsta or another managed host, add the equivalent line. The disallowed list is not a guess. It is a published policy.
Trap 2 — trusting the directory’s compatibility flag at face value. The flag is voluntary. The Codex says so plainly. For a candidate plugin’s flag to be reliable, plenty of users on plenty of stacks must have reported back.
For the niche plugin you are evaluating, the flag may be a single vote from someone whose stack looks nothing like yours. Ask the chat to weight the flag by the number of recent reports. Flag any candidate whose compatibility data is thin.
Trap 3 — skipping the staging install on the chat’s word. The chat reads metadata. It does not run code. Odd Jar’s March 2026 piece names six conflict patterns that surface only at runtime. PHP namespace collisions from shared Composer libraries. jQuery version conflicts. Hook-priority clashes. CSS specificity wars. Resource exhaustion from heavy database queries. REST API endpoint collisions.
Metadata cannot show any of them. The staging install is the test the AI shortlist cannot run for you. The diagnosing WordPress plugin conflicts walkthrough is the workflow for what surfaces during that staging run.
How do you spread the ninety minutes across an afternoon and a calm morning?
A defensible plugin choice costs about ninety minutes spread across an afternoon and a calm morning.
Half a Tuesday afternoon writes the inventory paragraph and pulls the candidate metadata. The chat returns the shortlist in seconds. The next morning runs the staging install on the top one or two candidates with Health Check Troubleshooting Mode active. The decision lands by lunch.
If you ship the shortlist as a four-line text file rather than a Slack message, you have a second-pair-of-eyes artifact. Your bookkeeper, your developer friend, your former agency contact — any of them can look at the same four lines and weigh in. That is the point of writing it down.
The plugin you install will not be the plugin everyone recommends. The plugin you install will be the one that fits your stack, your hosting, and the use case you wrote down at the top. A defensible decision is the calm of seeing the same constraints twice and reaching the same answer.
The listicle ranked plugins. Your shortlist ranked plugins against you. That is the part the listicle could not have written for you. The next listicle still will not write it.
Other questions worth answering
How does the pre-install check change for a premium add-on sold direct by its developer?
The signals shift, the workflow holds. A premium plugin sold from a developer’s own site skips the WordPress directory entirely. There is no Compatibility widget and often no public review thread.
Open the developer’s documentation page, the release notes, and a third-party WordPress publication review. Odd Jar’s March 2026 guide names four signals — last-updated date, WordPress-version-tested flag, support-forum equivalent, and active-installation count — as the pre-install audit.
At what active-install count does a candidate become too niche for the ranked output to trust?
No public study names an exact threshold. Odd Jar’s March 2026 guide treats active-installation count as one of four pre-install signals: last-updated date, WordPress-version-tested flag, and support-forum reports. When active installs drop low, the other three usually drop with them. Ask the chat to flag any candidate where two or more signals look thin.
When should you re-run the candidate ranking on a site you already configured?
Two triggers, not a calendar. First, before adding any plugin to an existing stack, re-run steps three and four so the new candidate gets ranked against the active plugin list. Second, after any WordPress major release when your tested-up-to flags drift out of date. WPBeginner’s December 2025 guide names Health Check Troubleshooting Mode as the staging-install verification step for the re-ranked candidates.
Does a chatbot’s training cutoff matter for an add-on released in the last few weeks?
Yes, with one caveat. The workflow handles it by leaning on metadata you paste rather than the AI chat’s training recall. A plugin released last week does not need to be in the chat’s training set.
What the chat ranks is the readme, the changelog, and the last-updated date you give it. Frontier 2026 chats like Claude and ChatGPT preserve that structure cleanly.
What should you write down before you start?
One paragraph. Your active plugin list with versions. Your WordPress version. Your PHP version. Your managed host or VPS arrangement. The use case in one sentence. The budget if there is one. Three to four lines is enough — the chat works better with less.
The next post in this series is the pre-install reference check for the candidate that makes your shortlist. A separate read with a separate workflow. The step closes the gap between metadata and code review for a plugin from an unknown author. The code review of third-party plugins workflow walks through that read end-to-end.
If you want a calm second opinion on your inventory paragraph and your shortlist before you run the staging install, you can contact me here. I read your stack, look at your candidates, and tell you which staging test to run first. There is no pitch, no upsell, and the conversation is free.