Core Concepts

Render Verification

Your AI checks the live render and reads PHP errors to debug its own work.

A successful tool call is never treated as proof of a working page. After any write that produces visible output, your AI fetches the live render and reads it back. If something rendered wrong, your AI sees it and fixes its own work before handing the page to you.

What it checks

Your AI does an HTTP GET of the page (cache-busted) and inspects the actual response, not just the status line. It checks for:

HTTP status, so a 500 or a redirect is caught instead of assumed away.
PHP notices, warnings, and fatals printed into the page body, the kind that quietly break a layout.
Required widgets present, so a section that failed to place is flagged.
Listing item counts meeting a minimum, so an empty grid does not pass as a populated one.
Expected text present, so the content you asked for actually landed on the page.
Unresolved dynamic widgets, for example a JetEngine field that rendered empty because a binding was never set. A plain 200 would hide that. Render verification does not.

Honest verdicts

Every check returns one of four verdicts: pass, fail, inconclusive, or skip. The point is to never report a green check it did not actually earn.

Pass: the page rendered and every check held.
Fail: a real problem showed up in the render, and your AI starts debugging.
Inconclusive: the server cannot reach its own public URL (a connectivity issue, not a broken page). Your AI does not call this a failure. It falls back to an in-process render instead.
Skip: a cache plugin with no known bypass is active, so the live HTML may be stale. Your AI returns skip rather than a false pass against cached output.

It reads the actual error

BuildPress runs its own host-independent PHP error capture. It works on Cloudways, Kinsta, WP Engine, shared hosting, and local dev, with no reliance on WP_DEBUG. You do not have to enable host logging or hunt through a log file. When a page 500s or white-screens, your AI reads the real PHP error and fixes its own work.

Drafts first

Pages are created as drafts and published only on your explicit confirmation. Render verification happens on the draft, so a broken page never goes live for your visitors to find.

The verification report

Each build ends with a verification report: pass, warn, and fail lines for what was checked, plus an edit URL and a preview URL so you can open the page yourself. You get builds that are checked, not assumed.

Verification report6 checks

HTTP 200 - page renderspass

Hero section presentpass

Feature grid: 3 of 3 itemspass

Testimonials: placeholder copywarn

Pricing: PHP notice in outputfail

Pricing re-checked: cleanpass

Checked, not assumed. A failed check sends your AI back to fix its own work.

A build verification report, showing pass, warn, and fail lines for the checked sections alongside edit and preview links.

Example prompts

You rarely have to ask for verification, since it runs after every visible write. These prompts lean on it directly when you want your AI to investigate or re-check:

The homepage is showing a 500 error. Check what's wrong, read the error, and fix it.
Verify the Services page renders, and tell me if any section is empty or missing.
The properties grid looks blank on the front end. Find out why and fix the binding.

For more on how your AI composes and re-themes pages, see widget-first builds and how BuildPress works.