What's in the 175 tools

Seven engines, and every one states what it cannot see.

• Site QA — the client-can-edit-it check, run on every page
• Accessibility — headings, alt text, link text, contrast, the Divi-specific defects generic checkers miss. From the rendered page it also reads the theme itself: language, skip link, landmarks, zoom, form labels, button names
• Performance — image weight, module counts, nesting depth, resolved against your media library
• SEO — how your pages are built to rank; it cannot see rankings or volume, and says so
• Legal — expected documents, whether they're published, and what your site actually loads
• Design Guardian (Divi 5) — a fixed list of dated patterns, plus heading sizes checked against your own type scale
• Divi 5 canvases (off-canvas menus, popups and mega menus) audited with the page they belong to, and Divi 5 interactions checked for missing targets, duplicated ids and popups nothing opens
• Which plugin loads which files on each page, with size, render-blocking and a probably-unused flag
• Page-builder performance settings, and forms built in Divi or Elementor checked for a missing recipient, spam protection and success message
• Images described and icon links and buttons named by your assistant, written through the builder and undoable
• On Elementor sites, presets, V4 global classes and components, design values and CSS regeneration answer in Elementor’s own vocabulary
• Site Health: the install itself. Versions against their support windows, pending updates, abandoned plugins, security posture, database bloat, mail deliverability, WordPress core's own Site Health tests — on any theme, any builder, with one-click hardening fixes

How the audits work →
Automatic fixes →
On a schedule →

The tools for a book of client sites.

• Site memory — record a convention once (palette rules, tone, always do X here) and it is injected into every future session, so you never re-explain your rules✦Pro
• Site-to-site page transfer, with the design tokens a page depends on✦Pro
• Rescue audit — Divi 4 shortcodes, orphaned plugins, classic-editor sediment, with an ordered fix plan (free)
• Client-ready reports that lead with what changed✦Pro
• Scheduled audits — a site that drifts tells you before a client does✦Pro
• On Divi 5: style guide generator from the site's own design system✦Pro
• Legal page drafts from what the site actually loads (free)
• Fleet hub: every client site’s score, pending updates, security, hourly uptime checks, and certificate and domain expiry in one table, alert emails on a change of state, and presets, colours, variables, patterns, layouts and brand kits pushed to client sites✦Pro
• Tested updates: each plugin, theme or WordPress update checked on your key pages before and after, and a plugin or theme update that breaks a page rolled back automatically (WordPress core updates are reported, not rolled back)✦Pro
• Client approvals and a monthly care report✦Pro
• Asset cleanup rules for the files plugins load, from Audit → Performance✦Pro

Rescuing an older site →

Every job used to end with “ask the owner to do it in wp-admin” three times. Ten tools end that, across the eight jobs below. Site setup and menus each get a read tool and a write tool — eight of the ten of them work on any WordPress site, whatever the theme or builder. The two that do not are search and replace and the SEO fields tool: both write page content, so both need a builder this plugin can write, and both are verified against Divi 5 and the block editor rather than claimed everywhere. Writing site setup and menus, search and replace, and structured data are Checknaut Pro.

• Site setup — title, tagline, front page and posts page, read free and written with Pro✦Pro (a draft is refused as the front page)
• Menus — read every menu and location; build or extend one with Pro✦Pro, with every item validated before anything is created
• Forms — finds Gravity Forms and Contact Form 7 forms, recognises WPForms, Ninja, Fluent and Formidable forms from their stored shortcodes, with the shortcode to place each, and lists forms built in Divi or Elementor. None of those six form plugins was installed on the 5.0.0 test sites.
• Media search across the library, so an existing image is reused instead of re-uploaded
• Broken-link check — internal and external, live status codes, cached so a rerun is cheap
• Search & replace across pages — dry-run by default, structure-verified after the write, refuses needles that could corrupt Divi markup✦Pro
• SEO title and meta description per page — into Yoast, Rank Math or SEOPress if present, otherwise printed by Checknaut itself
• Structured data — JSON-LD per page, with fabricated ratings and reviews refused✦Pro

See the full changelog →

The seventh audit reads the install, not the pages — so it works on any theme with any builder, and it is the first thing to run on a site you did not build.

• WordPress, PHP and database versions against their support windows; pending core, plugin and theme updates (a same-branch security release is a failure, not a warning)
• Inactive plugins, and plugins with no wordpress.org release in two years
• Security posture — guessable admin logins, open registration, XML-RPC, user enumeration, missing login protection or backups, default salts, security headers, version disclosure, mixed content, a browsable uploads folder
• Database bloat — autoloaded options past WordPress's own line, backlogs of revisions and transients, orphaned meta
• Content hygiene — sample content still published, soft 404s, robots.txt, empty menu locations, comments open with no spam protection
• Mail — SPF, DMARC and MX for your domain, and whether mail leaves through PHP mail()
• WordPress core's own Site Health tests, folded in
• This site’s TLS certificate (days left, issuer, host-name match) and the domain’s registration expiry, from rdap.org
• Every network probe is cached, time-boxed and reported as unchecked by name when it cannot run — a short list is never read as a clean one
• Six hardening fixes applied from the finding with one click, each undoable: XML-RPC off, hidden versions, no user enumeration, security headers, file editors off, sitemap in robots.txt. HSTS is the one a site cannot take back, so it is not a one-click fix: it is set deliberately with Checknaut Pro’s hardening controls✦Pro

See the full changelog →

Checknaut asks which builder owns each page and then keys every tool, every fixer and every sentence on what that builder can actually do — never on its name. So the same install behaves differently, and says so, on a Divi page and an Elementor one.

• Divi 5 — the whole product: build, edit, audit, fix, the design system, Theme Builder templates and WooCommerce layouts. This site is Divi 5.13; on any site the plugin names each tool it withholds and why.
• Elementor — every page is read from Elementor's stored element tree and audited by element id. The fixes that write are alt text, heading level, link text and element settings, and with Checknaut Pro it builds whole Elementor pages as well: containers, classic widgets and the 4.x atomic ones. Every write goes through Elementor's own document save with an undo held in post meta (Elementor keeps the page there, and WordPress revisions do not record post meta — so a revision would have been a promise that restores cleanly and changes nothing back). 5.0.0 was tested on Elementor 4.3.0 with PRO Elements 4.2.3 standing in for Elementor Pro; on any site the plugin names every Elementor tool it withholds. With Elementor Pro, Theme Builder templates and Loop Grids too; design-system writes on Elementor cover global colours and fonts, V4 variables, global classes and default styles.
• The block editor — pages read and written with no page builder needed; a page is edited by replacing it whole, and there are no Theme Builder, loop, WooCommerce or design-system authoring tools for it.
• Bricks, Beaver Builder, Breakdance, Oxygen and WPBakery are identified by name, audited from their render and refused for writes. That code ships; none of the five was installed on the 5.0.0 test sites, and the site says so rather than implying coverage.
• Themes — the audits read content and the install, not a theme's markup conventions, so they are theme-independent. 5.0.0 was tested on WordPress 7.1 with the Twenty Twenty-Three, Twenty Twenty-Four and Twenty Twenty-Five themes and Divi 5.13.1, and on Elementor 4.3.0 with PRO Elements 4.2.3.
• Site Health needs no builder. It reads the install itself: versions, updates, security posture, database, content hygiene, mail. That makes it the first useful thing to run on any WordPress site, whatever built it.

See what landed when →