What should I check before installing an AI plugin on WordPress?
Before you install an AI plugin on a live WordPress site, make one recorded decision: approve it, approve it with limits, send the setup back for changes or reject it. Base that decision on evidence about the job, data flow, WordPress access, human approval, testing, support and removal.
Do not let "AI plugin" stand in for a clear requirement. A tool that drafts an unpublished article presents different risks from one that answers visitors, edits product data or can publish pages. Decide the job first; then judge whether the plugin needs the access it requests.
Start with one job and one boundary
Write the intended job in one sentence:
The plugin may use approved business facts and existing public pages to prepare an unpublished article draft. An editor checks the facts, links and wording before anything is published.
That sentence identifies inputs, output and approval. It also exposes unsuitable behaviour. If the plugin wants access to customer orders for a content-drafting task, ask why. If it can publish when you only need drafts, ask whether that capability can be disabled or withheld.
"It saves time" is not a testable requirement. "It prepares a draft that a named editor can review without changing the live page" is.
Do a document check before anyone installs the plugin. You should be able to identify the plugin and provider, read the terms and privacy information, map the requested access to the job, name the approver and write the test and exit plan. Installation is the next stage, not the way to discover basic terms.
Ask where your information goes
Many AI features rely on an external service. Before connecting one, ask the provider to document:
- which WordPress content and settings the plugin reads;
- whether it can access drafts, private pages, user records, form entries, orders or uploaded files;
- what leaves your server and which external services receive it;
- whether prompts, outputs, logs or telemetry are retained, and for how long;
- whether that information is used to improve or train models;
- who can access it and how deletion or export requests work; and
- whether behaviour changes when optional integrations are enabled.
These are not abstract questions. The WordPress Plugin Handbook's privacy guidance tells plugin developers to consider data sent to outside APIs, telemetry, third-party scripts, browser storage, logs, REST API exposure, user roles, erasure and uninstall cleanup. WordPress.org's directory rules also require plugins using external services to document the service and its terms, and prohibit tracking without consent, subject to the rules' stated service exception (WordPress.org plugin guidelines).
A directory listing is useful evidence, not a complete assessment of your business's privacy or security obligations. The directory rules govern listed plugins; they do not certify that a plugin suits your site. Keep the provider's current privacy notice and service terms with your decision record. If the answer is vague, mark the data path as unknown rather than assuming that no information leaves WordPress.
Match permissions to the job
Ask which WordPress role or technical credentials are required and why. Separate the person operating the tool from the connection the plugin uses.
For example, an editor may need to review a draft. That does not automatically mean every editor should be able to change plugin settings, view other users' information or manage API credentials. Likewise, a plugin may need to create a draft without needing the ability to publish it.
Record the smallest access that supports the intended job. Include:
- who can configure the plugin;
- who can request AI work;
- which content each person can read or change;
- who can approve or publish;
- where provider credentials are stored and who can rotate them; and
- what happens when a staff member or supplier leaves.
Do not share an administrator password to make a trial convenient. Give each person their own appropriate account, and revoke access through a controlled handover.
Check the plugin and provider, not just the feature list
In WordPress, open the plugin's details before installing it. WordPress documentation says the Add Plugins screen shows whether a directory plugin is compatible with your WordPress version or untested with it, and links to its documentation and installation notes (Manage Plugins).
Also record:
- the exact plugin name, author and download source;
- the version you evaluated and the WordPress and PHP versions on the test site;
- the last update and support route;
- required provider account, subscription or usage limits;
- documented dependencies and known conflicts;
- update ownership; and
- what evidence the provider offers for privacy, security and incident reporting.
Compatibility text is not a promise that the plugin works with your theme, forms, shop or hosting configuration. Reviews and active-install counts can help you form questions, but they do not replace a site-specific test.
Protect the approval boundary
Decide what the plugin may do automatically and what must stop for a person. For content work, the approval check should cover factual claims, source links, prices, product details, internal links, images, metadata and the final published page. For customer-facing answers, test escalation, refusal and failure behaviour as well as fluent answers.
Keep a visible state such as draft, ready for review, approved and published. The person approving should be able to see what changed and reject it without editing the live page first.
If the tool can edit or publish automatically, verify that you can turn those actions off. A reassuring description is not enough; observe the setting and the resulting WordPress state on the test site.
Test away from the live customer journey
Use a staging site or another controlled copy when possible. Remove or mask personal and confidential information unless the test specifically requires it and you have an approved basis for using it. Do not send test orders, enquiries or emails to real customers.
Before changing a site, create a recoverable backup. WordPress's backup guidance explains that a typical full recovery needs both the database and the WordPress files; a file copy alone usually does not include the separate database (WordPress backups). Confirm who can restore the backup and where the restore will be tested.
Test the real job, not only whether the plugin activates:
| Test | Evidence to retain | Stop if |
|---|---|---|
| Install and activate | Version, environment and visible errors | The site or administrator area breaks |
| Run the intended task | Inputs, output and processing time | It needs unexplained data or access |
| Review before publishing | Draft state, reviewer and change history | Work can bypass the agreed reviewer |
| Check existing functions | Forms, search, checkout or other relevant paths | A customer path changes or fails |
| Disable and remove | What stops, what remains and export/deletion steps | The site depends on an undocumented service or data cannot be accounted for |
| Restore | Dated restore result on a controlled environment | The backup cannot be restored |
A plugin passing these checks gives you evidence for this environment and this version. Updates to WordPress, the plugin, its model provider or another integration can change the result, so keep the test record with the version and date.
Decide who owns updates, support and exit
An AI plugin is usually both installed software and a service relationship. Record who will:
- review plugin and provider changes;
- apply and test updates;
- monitor usage or service limits;
- investigate failed or unsuitable outputs;
- rotate credentials;
- respond to a privacy or security incident; and
- decide whether to renew, replace or remove it.
Before approval, perform an exit review. Can you export the useful work? What content, settings, logs or database tables remain after deactivation or deletion? Does removing the external account affect existing pages? Who has the authority and documentation to complete the removal?
WordPress provides controls to deactivate and delete plugins, but that action alone does not prove an external provider has deleted retained data or that the plugin cleaned every stored record. Ask for the provider's documented process and verify the parts you can observe.
A hypothetical content-plugin decision
Suppose a small accounting firm wants a plugin to prepare unpublished service-page updates from approved facts. This is a hypothetical example, not a WPShip customer result.
The document check shows that the plugin can read every public and private post, send selected content to an external model provider and create drafts. It does not need customer form entries or the ability to publish. The firm therefore limits the connection to the content needed for the task and leaves publishing with its editor.
On a staging copy, the team tries an accurate service description, an outdated fee and a request that includes a private note. The first output is usable after editing. The plugin repeats the outdated fee rather than flagging it, and the private note appears in the provider request. The decision is not simply pass or fail: revise the facts supplied to the tool, exclude private notes, document the external data route and retest those two cases. The live installation waits until those limits work as intended.
This example shows why output quality is only one part of approval. A fluent draft can still use the wrong fact or the wrong data.
Use a one-page installation decision record
Complete this record before a live installation:
| Decision | Your evidence |
|---|---|
| Intended job | One specific task and expected output |
| Prohibited actions | Data and actions outside the job |
| Data path | Information read, information sent, recipients, retention and deletion |
| WordPress access | Roles, capabilities and credential owner |
| Approval | Named reviewer and the state where work stops |
| Test | Environment, cases, results and unresolved failures |
| Recovery | Backup set, restore owner and tested result |
| Operations | Update, support, incident and cost owner |
| Exit | Export, removal and external-data deletion path |
| Decision | Approve, approve with limits, revise the setup or reject, with owner and date |
Unknown is a valid entry. It tells you what must be resolved before installation. A blank cell hides the same uncertainty.
How this applies to WPShip Assistant
WPShip publicly describes its Assistant as a site-owner workflow for researching opportunities, preparing drafts and supported text edits, and putting results through review before approval. Its page says the plugin connects the site to the Assistant and that the owner remains responsible for checking facts and approving work (WPShip Assistant).
Those statements make task definition, site context and human approval relevant to an evaluation. They do not prove compatibility with your current stack, establish every data flow or replace a test on your site.
If you already run WordPress and are considering an AI-assisted content workflow, ask WPShip whether the Assistant fits your site and approval process. Bring your WordPress version, hosting environment, current publishing roles, the content you want it to use and any information it must not access. Scope, exclusions and price should be confirmed before work begins; the form's delivery has not been tested for this article.
Ask four questions at the end: What does it do? What does it touch? Where does a person stay in control? How do we recover or leave? If the record cannot answer them with current evidence, keep the plugin off the live site until it can.