smolanalytics
menu
how it worksdocsfeaturescomparedpricinginstrumentmcpintegrationstoolsglossarycontact
log inStart trial
no plugin · a normal URL · run it on a schedule

Nobody touched the site.
The contact form still broke.

Core, the theme and a dozen plugins update on their own schedule, and what stops working is almost always the form. Describe it in one sentence and an agent fills it in on a real browser, every day, from outside the site.

Start the 14-day trialread the docs →
your terminal, or a daily scheduled job
npx smolanalytics test --url https://yoursite.com --test "the contact form accepts a name, an email and a message and shows the confirmation"
no account for the first run, no plugin, and nothing added to the theme. it visits the site from outside, which is also the only way to exercise your cache, your CDN and your security plugin.

how do I check my WordPress site still works after a plugin update?

A WordPress site is a normal URL, so testing one needs nothing special: npx smolanalytics test --url https://yoursite.com --test "the contact form accepts a name, an email and a message and shows the confirmation" opens a real browser, fills the form in, and tells you whether it worked. No plugin, no snippet, nothing added to the site. What is specific to WordPress is the failure mode. The site changes when nobody touched it, because core, the theme and a dozen plugins update on their own schedule, and the thing that breaks is almost always the form — a form plugin update that changes a field name, an SMTP plugin whose credentials expired so the submission is recorded and no mail is sent, a caching plugin serving a page with a stale nonce so the submit is rejected, a security plugin that starts refusing the post. Every one of those leaves a page that looks perfect, and most of them are discovered weeks later when somebody asks why you never replied. Most WordPress sites have no staging environment and no pull requests, so run the command on a schedule instead — daily is plenty — and the verdict arrives in your scheduler's log. A run that passes is recorded and replays afterwards in about a second with no model call at all. A recording that stops fitting is reported as stale rather than as a failure, because a renamed field and a removed field look identical to a replay. The same agent can also write and maintain tracking calls in whatever analytics you already use, and the included engine can be your analytics if you use none: cookieless, so no consent banner. 14-day trial at Pro limits, no card, then $19/month.

what a sentence covers on WordPress

Nothing to install: it is a normal URL
There is no WordPress plugin here and there does not need to be one. The agent visits your site the way a visitor does, from outside. That means it works the same on any host, any theme and any page builder, and it cannot slow your site down or break on an update, because it is not running inside it.
The site changes when nobody touched it
Core, the theme and every plugin update on their own schedule. That is the WordPress-specific reason to have a check running: on most stacks a regression follows a deploy you made, and here it follows an update you did not. Nothing in your workflow marks the moment something might have broken.
It is nearly always the form
A form plugin update renames a field. An SMTP plugin's credentials expire, so the entry is saved and no mail goes out. A caching plugin serves a stale nonce and the submit is silently rejected. All of them render a perfectly normal page, and all of them are found out weeks later by somebody asking why you never replied.
No pull request? Run it on a schedule
Most WordPress sites have no staging and no CI, so the comment-on-a-pull-request half does not apply. Say it plainly: here you run the same command daily from any machine or scheduler and read the verdict there. The runner is identical; only where the answer lands is different.

Honest pricing: 14-day trial at Pro limits, no card. Then Pro $19/mo, never metered on sites, so the main site plus the blog plus the landing page share one bill. 100 tested pull requests included and 10c each after, and replayed runs are not metered.

Fill in your own contact form. Daily.

Or write the sentence once and let something else do it every morning, from outside the site, with no plugin installed and nothing to slow the page down. The first run uses the agent; every one after it replays in about a second.

Start the 14-day trialread the setup docs →

questions

How do I test a WordPress site?
From outside, with one command: npx smolanalytics test --url https://yoursite.com --test "the contact form accepts a name, an email and a message and shows the confirmation". A real browser opens, fills the form in, and prints passed or failed. The first run needs no account and no key. Nothing is installed on the site and nothing is added to your theme, so there is no plugin conflict to worry about and no performance cost.
Is there a plugin?
No, and there is nothing for one to do. The test runs against your public URL from somewhere else, which is also the more honest way to check a site: it exercises your caching layer, your CDN, your security plugin and your SMTP configuration exactly as a visitor's request does. A plugin running inside WordPress would see none of that.
It says the form submitted, but does that mean the email arrived?
No, and that is worth being precise about because it is the most common WordPress failure. The agent confirms what a visitor can see, which is the confirmation message. If your form plugin shows a success message before the mail is handed off — and many do — a broken SMTP configuration will still pass this test. Cover that separately by checking the inbox, or by writing the sentence to end somewhere that only exists after delivery, if your setup gives you one.
Can it test WooCommerce checkout?
The same way it tests anything: point a sentence at it. Do the paying version against a test gateway rather than the live shop, because the runner does not seed or clean up data and a completed test order is a real order. The steps before payment are safe to run against the live site and are the ones a plugin update tends to break anyway.
What about the analytics you used to sell on this page?
Second in line, and optional. The same walk can write and maintain tracking calls in whatever analytics you already run, and a site that runs none can hold its own tracking behind one door on its setup page. The tests need none of it.

keep reading

for Webflow
the other stack with no repo to test from
for ecommerce
the checkout version of the same problem
setup docs
flags, the suite format, scheduling