Forma

The page health panel: SEO feedback where you're already working

Every page and post editor now shows a contextual SEO health panel with one-click fixes, and the same check rides along on the Agent API's page and post lists as seo_ok / seo_issues.

Settings → SEO has a health dashboard. It always has. The problem was never that Forma couldn't tell you a page was missing a description — it's that finding out meant leaving the page you were editing, opening a different screen, and cross-referencing a list of filenames against whatever you were just working on. By the time you got back to the editor you'd forgotten which field it was.

Feedback where you're already looking

Every page and post editor now has a Page health panel sitting right under the SEO preview:

⚠ Title is 68 chars (aim ≤60)                    [Fix]
⚠ No meta description                             [Fix]
ⓘ No social image (site default may cover this)  [Fix]

Click Fix and the editor expands the collapsed SEO panel, scrolls to the field, and focuses it. No new tab, no context switch, no re-finding your place. The check runs against the exact document you're looking at — the same title, the same description, the same Forma's contextual SEO page health panel slot state — so there's no gap between what the panel says and what's actually going to ship.

This isn't a replacement for the sitewide health dashboard. Settings → SEO still catches things a single-document check can't: duplicate titles across pages, a missing sitewide favicon, schema fields that only matter in aggregate. The two live side by side on purpose. One tells you what's wrong with the site. The other tells you what's wrong with the paragraph you're currently editing.

The same check, for agents

An agent editing content over the API has the identical problem at a different scale: instead of one page open in an editor, it might be looking at forty. Re-fetching full SEO settings for every document just to find the three that need work doesn't scale. So the same lightweight check now rides along on the list endpoints:

GET /api/v1/pages
{
  "filename": "qa-test-page",
  "seo_ok": true,
  "seo_issues": [
    { "field": "desc", "severity": "info", "message": "Description is short (47 chars)" }
  ]
}

seo_ok is false only when something is warn-severity — a missing description, a title running long. Purely informational notes (no social image, description on the short side) don't fail the flag, because they're not actually wrong, just worth knowing. GET /api/v1/posts returns the same shape. An agent — or a script, or a dashboard — can pull the whole list once, filter on seo_ok: false, and go straight to the handful of documents that need attention instead of opening all of them.

Why the split matters

A health check that only exists in a settings screen gets checked once, at launch, and then forgotten. A health check that shows up exactly where you're already working — or in the same response an agent already fetched — gets looked at every time, because it cost nothing extra to see. That's the actual fix here. The logic isn't new. Where it shows up is.