Page Optimizer

42flows reads the pages you already have and improves them in place. Title, meta description, Open Graph, JSON-LD schema, internal links, alt text. We don't rewrite the page or replace it. We make targeted, reviewable edits to the page that's already ranking and earn the next few positions.

Existing pages already have authority, impressions, and rankings. New articles take 2 to 8 weeks to mature, often longer. One existing page going from position #9 to #3 outweighs 10 new articles published over a quarter. The compounding is structural, not incremental.

How it works

1. You connect your site. WordPress, Nuxt Content (Markdown via GitHub), Shopify. One-click for WordPress (Application Password), GitHub App for Nuxt Content.
2. 42flows reads the page. A small companion plugin (WordPress) or the GitHub adapter (Nuxt) returns a typed view of the page: meta, body widgets or blocks, attached images, existing schemas.
3. 42flows proposes edits. A reasoning model produces a list of typed edit operations (not raw HTML), each grounded in evidence from Google Search Console, the SEO audit, top-3 SERP competitors, and your business profile. Every edit has a written rationale.
4. You review and apply. The operator (you, or a 42flows oversight pro) reviews each edit, accepts or rejects it, and applies the accepted ones. One-click rollback if anything looks wrong.
5. 42flows verifies. After every apply, 42flows fetches the live page and asserts that the new title, description, OG tags, and schemas are actually present in the rendered HTML. If a CDN or page-cache plugin held onto the old version, the system surfaces that as a verify failure for follow-up.

Supported platforms

Today, Page Optimizer v2 runs end-to-end on WordPress sites only. Support for Nuxt Content, Shopify, static HTML, and the remaining WordPress page builders is on the roadmap.

Pages and posts

Page Optimizer v2 works on WordPress pages and WordPress blog posts in the same surface. The dashboard shows both, with a tab filter for All / Pages / Posts. The same edit operations apply to either type.

Blog posts often benefit more from optimization than pages. They sit deeper in the site, attract more long-tail queries, and are typically where the SEO plugin's auto-emitted Article schema lives. Optimizing a blog post that's already ranking position 9 to position 3 is the highest-leverage work in most catalogs.

Supported edits

Every edit is a typed operation against a specific element on the page. The model can't propose anything outside this list, and the operations are validated against your page's actual structure (widget IDs, block IDs, image URLs) before you ever see them, so there's no risk of editing something that doesn't exist.

Schema awareness, end to end

Most WordPress sites have an SEO plugin (Yoast, Rank Math, AIOSEO) that auto-emits structured data on every page render. Organization on every page, FAQPage where there's a FAQ block, Article on every blog post, BreadcrumbList everywhere. These schemas don't live in postmeta — the SEO plugin generates them at render time.

Page Optimizer v2 sees them. Before proposing edits, the orchestrator fetches the live URL and parses every <script type="application/ld+json"> block actually on the page. The reasoning model receives a unified view: schemas your SEO plugin emits, schemas 42flows wrote, and schemas present in both places. It will not propose a duplicate Organization or Article when the SEO plugin is already emitting one.

This is also why the post-apply verifier is meaningful. The same fetch-and-parse primitive checks whether the title, description, OG, and schemas you applied are actually in the rendered HTML. If a CDN held an old copy or a SEO plugin's filter overrode our write, the verify step catches it immediately.

How we own the meta layer

When you optimize a page, we write the new title, description, OG tags, and schemas to two places: the SEO plugin you already use (Yoast, Rank Math, AIOSEO) for compatibility, AND a 42flows-owned set of postmeta keys that the 42flows-content plugin emits directly on the page's <head>.

That second part is the foundation. We don't depend on Yoast (or any SEO plugin, or any page-cache plugin, or any CDN) to render our writes correctly. The 42flows-content plugin owns <title>, <meta description>, OG, Twitter, canonical, and JSON-LD schemas on wp_head priority 0. If you switch SEO plugins later, 42flows's edits keep working. If you don't have an SEO plugin at all, 42flows's edits still work.

After every apply, 42flows tells your active page-cache plugin (LiteSpeed Cache, WP Rocket, W3 Total Cache, WP Super Cache, NitroPack, Autoptimize) to drop the cached version of the page. If your site is behind Cloudflare, 42flows also purges the URL at the edge, provided you've added a Cloudflare API token scoped to "Zone — Cache Purge" via the dashboard.

Then 42flows fetches the page like a search engine would and asserts that the new title, description, OG tags, and schemas are actually in the rendered HTML. Verified shipments only.

What we don't yet support

We're explicit about this so there are no surprises.

• Layout changes on Elementor pages. We can edit text in existing widgets and add inline links. We can't yet replace a hero slider with a text block, restructure sections, or rearrange columns. That requires Elementor CSS regeneration orchestration, which is on the roadmap (Phase 1.5).
• Generating or swapping images. We can update alt text on existing images. We don't yet generate new featured images or hero photography for pages we optimize. The brand-fingerprint visual layer is Phase 2.
• Beaver Builder, Divi, WPBakery body edits. We can edit the meta layer on these pages today. Body-level edits require dedicated adapters that we're shipping in Phase 2 as customers need them.
• Bulk optimization. "Optimize all 30 pages on this site" isn't a primitive yet. v1 is one page at a time. Bulk is a wrapper we'll add once the per-page workflow has compounded enough data to justify the automation.
• Auto-apply without operator review. v1 always shows the proposed edits to an operator (you, or an SEO pro on the 42flows oversight team) before anything is written. We'll consider auto-apply for the meta layer once we have a measurable track record across customers.
• Customer-facing review UI. Today's review flow is operator-only. A customer-facing review page is on the roadmap.

Privacy and data handling

Snapshots taken before each edit are stored on your WordPress site (in postmeta), not on 42flows servers. They expire automatically after 30 days via a daily cron event the plugin schedules.

The _42flows_* postmeta keys 42flows writes are namespaced and removable on plugin uninstall. Cloudflare API tokens are stored alongside the rest of your site credentials with the same encryption posture.

For developers

• The 42flows-content companion plugin is open source and listed on wordpress.org. The full source is also in the 42flows main repo under wordpress-plugin/42flows-content/.
• REST endpoints exposed by the plugin: GET /wp-json/42flows/v1/page/{id}/edit-tree, POST /apply-ops, POST /rollback. All require an Application Password with edit_posts capability.
• Edit operations are typed in TypeScript at server/services/page-optimizer-v2/orchestrator.ts. Validation runs against the page's actual structure before the model's output ever reaches the WP plugin.
• Post-apply HTTP verification uses cheerio against the live URL with Cache-Control: no-cache. Mismatches surface as page_optimizer.v2.unverified activity events and are non-blocking — the writes still land; the verify result is a signal for the oversight layer.

If you're integrating a new platform: add an adapter at server/services/adapters/<platform>.ts exporting getPageEditTree + applyOps + rollbackSnapshot. The orchestrator and skill are platform-agnostic.