Broken link checker for WordPress, without a plugin
Mortise does not install into wp-admin. If you can publish a token on the public site, or in DNS, you can crawl the public front end.
No card required. 1 site and 200 pages on the free plan.
How verification usually looks on WordPress
Any one method is enough. Put the token in /.well-known/mortise.txt. Or add the meta tag to the start page’s head, which on many themes is a header injection field. Or add a DNS TXT record: mortise-site-verification= and the token. The meta tag is read from the start URL you entered. The file and DNS are checked on that host. A security redirect to another domain will fail verification on purpose.
What the crawl sees
Mortise requests public HTML as MortiseBot/1.0. It follows links in that HTML, skips typical asset extensions when deciding which URLs are pages, and checks other linked URLs for status. It does not open wp-admin, read the database, or see previews that only exist when you are logged in.
If a security plugin blocks unknown bots, allow MortiseBot, or verification and crawls will fail. robots.txt is honoured. A disallow on the start URL stops the crawl with a robots error rather than a pile of fake 404s.
Permalinks and caches
When a permalink changes, pages that still link to the old path can produce a new break after two 404 crawls, if the old path worked on the baseline. A caching plugin that serves HTML is fine. A cache that hides the verification file or meta tag until you purge it will make Verify fail until the public response contains the token.
Questions
Is there a WordPress plugin?
No. Verification is a file, a meta tag, or DNS TXT. Crawling uses public HTTP.
Will it scan draft posts?
No. If a draft is not linked from public HTML, Mortise does not see it.
Does it work on WordPress.com and self-hosted WordPress?
It works when you can prove control of the host and the public HTML is crawlable. If you cannot upload the file, edit the head, or set DNS, verification cannot pass.