Keel ⛵

Keel provides 42 configurable WordPress settings for security, updates, privacy, content, media, email, UX, and performance — each one visible under Settings → Site Defaults. Some depend on others; configuration or network policy can manage them centrally, and locked settings say so. Nothing is hidden and deactivation returns WordPress to its prior behaviour.

Keel closes a gap in WordPress core-update reporting. Keel asks WordPress.org whether the installed release is known to be vulnerable, names the patched tip on the site’s own release line, shows every offered release and marks the one core would choose. An authorized administrator can deliberately install the same-line patch through WordPress’s own upgrader with rollback enabled. The target and compatibility checks run again on the server, and nothing installs without a click.

The consistency is the point. Closing the REST API also removes the discovery link that advertises it; disabling comments also stops the comment feed and direct get_comments() queries. Where a trade is deliberate, Keel documents it instead of making a broader claim than the code can support.

Site Health reports the posture read-only: every default and its effective state, update operability, service failures, and traceable policy overlaps. If another plugin controls the same setting, Keel names the evidence it can establish and labels what it cannot attribute instead of guessing.

0.7 and 0.8 extend the same approach. Password-protected posts stay out of searches by people who cannot open them, and leftover shortcode tags are hidden from readers without changing stored content. Site Health now names the largest autoloaded options and the most overdue or frequent cron events with a probable owner and an explicit confidence level — option values and event arguments never enter the report, and nothing is deleted or rescheduled.