An owner installs a plugin that does something useful. It works well for two years.
The developer stops maintaining it. The plugin keeps working, so nobody notices, and it sits on the site running code that has not been reviewed since before the last three platform releases.
Nothing about the site changed. The risk changed underneath it, silently, and the only signal available was a date on a page nobody looks at.
1. Check when it was last updated
The single most useful signal. Anything not updated within a reasonable period against recent platform releases should be treated as abandoned regardless of how well it works.
2. Check how actively it is maintained
Release frequency, responsiveness to reported issues and whether there is a company or one individual behind it. Both can be fine, and the difference matters for how long it will last.
3. Check how widely it is used
A widely deployed plugin has more eyes on it and more pressure to fix things quickly. A rarely used one may be excellent and it carries more risk of quiet abandonment.
4. Check what access it requires
Anything reading customer data, writing to the database or acting with elevated permission deserves more scrutiny than something that displays a widget.
5. Ask where the data goes
Whether anything leaves the site, to whom, where it is stored and for how long. This matters legally as well as technically and it is rarely stated on the installation page.
6. Ask the vendor the direct questions
Hosting, encryption, retention, subprocessors and incident handling, which is the list in ai chatbot security questions to ask a vendor.
7. Prefer fewer things with broader use
Three plugins doing narrow jobs carry three maintenance obligations. One well maintained tool covering the same ground is usually the better risk position.
8. Remove what you are not using
Deactivated plugins still sit on the server. Unused plugins are the cheapest security improvement available and almost nobody does the audit.
9. Keep everything updated on a schedule
Most compromises exploit known issues in outdated software. A monthly update routine with a backup beforehand handles nearly all of it.
10. Take a backup before every update
Verified as restorable. This converts an update from something to be feared into something routine, which is what makes people actually do it.
11. Test updates on a staging copy where you can
Particularly for anything touching checkout, forms or payment. A broken update discovered by a customer is considerably more expensive than one discovered in staging.
12. Understand what a script based widget avoids
No update cycle, no database access and a far smaller surface, which is part of why it behaves differently from a plugin, as covered in plugin conflict questions wordpress owners ask.
13. Check what happens if the vendor disappears
Whether the site keeps working, whether the data can be retrieved and how quickly the thing can be removed cleanly. Every tool on a website is a dependency, and the plan for its absence should exist before it is needed rather than during an outage.
13. Keep the caching and delivery layers in the picture
Security rules at those layers can block legitimate scripts and hide changes, which is the confusion in caching questions that confuse everybody.
14. Ask what it costs to run, not just to install
Maintenance, updates, occasional breakage and the time to keep it current, which is the same honest total as in running cost questions before installing a pool. See the integrations, features, start at try, and the sector view sits under small business.