GuardForge hardens your WordPress site against common attacks without requiring an account or an API key. It applies proven hardening rules on activation, monitors for brute-force login attempts, protects your own account with two-factor authentication, checks your files against the build wordpress.org actually published, and keeps an audit log whose rows are hash-chained — so a line edited or deleted after the fact is detectable rather than deniable.
Nothing in the Free list below is capped, timed, or unlocked by paying. One thing in it reaches the network, it is off until you switch it on, and External services below describes it exactly: the file-integrity scan asks wordpress.org what your WordPress and your wordpress.org plugins are supposed to contain, so it can tell you when a file is not part of the official build — it sends a version number and a plugin slug, never your site’s address and nothing about your content.
GuardForge Pro is a separate add-on (installed alongside this free plugin) that unlocks:
GuardForge is part of the Forge Suite. Learn more and get Pro at https://avakode.com.
This plugin reaches wordpress.org, and nothing else. Activating it contacts nobody and schedules nothing that would — the file-integrity monitor is off on a fresh install, and switching it on is what puts the daily lookup on the schedule. The only outgoing request it ever makes is the checksum lookup below, it happens only while the file-integrity monitor is switched on, and it asks a public catalogue a question that names nothing of yours.
wordpress.org, for the file-integrity scan. Off until you switch the monitor on in GuardForge > Settings. Then once a day, and whenever you press “Run scan now”, GuardForge asks api.wordpress.org for the checksum list of your WordPress version and locale, and downloads.wordpress.org for the checksum list of each installed plugin it hosts (its folder name and version number). Those are public catalogues: the request carries the version, the locale and the slug, and nothing else — not your site’s address, not your user list, not your content, not a licence key. Answers are cached, and one scan makes at most ten requests, so a site with sixty plugins is covered over a few days rather than in one burst. Switch the file-integrity monitor off in Settings and none of this happens.
Nothing about your site is sent on a schedule or in the background. A fresh install makes no request at all and schedules none; with the file-integrity monitor switched on it has one daily request — the checksum lookup, while that monitor is on — and it asks a public catalogue a question that names nothing of yours. Switch the file-integrity monitor off and this plugin makes no outgoing request at all.
Deleting GuardForge always removes one thing: your two-factor enrolments. That table holds TOTP shared secrets and single-use recovery codes — credential material — and once the plugin is gone nothing can use them, while a database that outlives the plugin gets backed up, exported and copied to staging. Reinstalling means enrolling again, which takes half a minute; leaving shared secrets behind has no upside at all.
Everything else stays by default: your login log, file-integrity snapshots, audit trail and settings all survive a delete, so removing the plugin by accident does not take your history with it. If you want a clean slate, tick Delete GuardForge data on uninstall in GuardForge Settings before you delete.
GuardForge Hardening score works out one number from twenty-one checks of this installation. Every check reads your own site — options, constants, your .htaccess, your user list, WordPress’s own update transients. Nothing is fetched from anywhere, which is also why the score cannot verify a header by fetching your homepage: the score makes no external request of any kind, and that promise is worth more than the extra check. The three things in the free plugin that reach the network — the “Explain” button, the integrity scan’s checksum lookup and the daily advisory download — are all described above, and none of them is the score: it reads what the last scan already worked out and asks nobody anything.
A check that cannot apply here leaves the sum entirely rather than scoring zero. An nginx site has no .htaccess to write, so the two .htaccess checks go to “does not apply” and the remaining checks grow to fill the hundred. Marking a correctly configured site down for lacking an Apache file would be theatre.
Every check sits in one of four weight buckets, and there are no others. 12 is the control whose absence is how sites actually get taken over; 8 is a direct route in, or the loss of the evidence that one was used; 5 is reconnaissance and exposure that shortens somebody else’s work; 2 is worth doing, cheap, and not what the incident report will name. The full table:
https — 12two_factor_admins — 12updates_pending — 12debug_display — 8xmlrpc — 8brute_force — 8file_edit — 8integrity_baseline — 8admin_username — 5user_enumeration — 5rest_restricted — 5security_headers — 5csp — 5sensitive_files — 5audit_log — 5hide_version — 2directory_listing — 2login_captcha — 2pingback — 2bad_useragents — 2notifications — 2The points a row advertises are the points you actually gain: the weights above are shared out over the checks that apply to your site so that they add up to exactly one hundred, and the headline is the sum of what those rows earned. With the Pro add-on installed and licensed, one more row joins the same list — installed plugins and themes with a published advisory, at 12 — and the shares are worked out again around it. Without the add-on that row does not exist and nothing on the screen mentions it.
Off unless you switch it on. When you do, GuardForge issues a link on your own site that publishes a letter grade and the month it was worked out — nothing else.
The grade is not your score. It is worked out only from the eleven checks a stranger can already run against your site from outside with no login: the scheme, XML-RPC, whether ?author=1 gives up a login name, whether the REST API answers anonymous callers, the version in your generator tag, your response headers, your Content-Security-Policy header, whether a directory lists its contents, whether sensitive files answer directly, the login form, and the X-Pingback header. Everything on that list is already public, so the badge tells a passer-by nothing they could not have found by loading your site.
Your numeric score, your two-factor coverage, your brute-force thresholds, your integrity results, whether an account is called admin, your pending updates and any vulnerable components are never published, in any form. The link carries an unguessable token so nobody can walk a list of sites looking for weak ones, it can be reissued or turned off at any moment, views are never logged, and until you switch it on the address is not registered at all — your site answers WordPress’s own 404, exactly like a site without the plugin.