Access the Repo Here on GitHub.

There’s a growing tension in the WordPress world.

On one side, you’ve got the flexibility and ecosystem that made WordPress dominant.
On the other, you’ve got performance expectations, modern tooling, and this new wave of AI-driven “vibe coding” workflows.

Most teams try to solve this by going fully headless.

I think that’s overkill for 80% of use cases.

So we built something simpler.

Introducing Convesio Static Proxy

Convesio Static Proxy is an open source WordPress plugin that lets you load externally hosted static pages directly into a WordPress route.

No theme.
No template rendering.
No WP overhead.

Just map a URL like:

/offer-1 → https://example.workers.dev/offer-1

…and it renders on your main domain like it’s native.

Why This Exists

If you step back, most “marketing pages” don’t need WordPress at all.

• Landing pages
• Promotional funnels
• Viral offers
• Campaign-specific microsites

These pages are:

• Mostly static
• Built quickly
• Iterated on constantly
• Performance-sensitive

Yet we run them through:

• PHP
• Theme rendering
• Plugin stacks
• Database queries

That’s a lot of overhead for something that could be a static HTML file.

The Big Idea

Instead of forcing everything into WordPress…

Let WordPress be the router.

Then let something else do the rendering.

That “something else” could be:

• A static site deployed on Cloudflare Workers
• A Vite build
• A page generated from an AI tool
• A quick project spun up in Replit
• A “vibe coded” landing page from Lovable

You build wherever you want.

Then just plug it into WordPress.

Real Use Cases

1. Viral / Performance-Critical Offer Pages

When you’re running traffic:

• Ads
• Email campaigns
• Influencer drops

Every millisecond matters.

With Static Proxy:

• No WP boot time
• No plugin conflicts
• No theme rendering

Just fast.

2. Rapid Experimentation

Marketing teams don’t want:

• Deploy pipelines
• Theme edits
• Dev bottlenecks

They want to:

• Build → Publish → Test → Iterate

Now they can build pages externally and drop them into:

/offer-a
/offer-b
/offer-c

without touching WordPress.

3. AI + “Vibe Coding” Pages

This is where things get really interesting.

Tools like Replit, Lovable, and Claude.design are enabling people to:

• Describe a page
• Generate it instantly
• Deploy it

But then the question becomes:

Where does it live?

You don’t want:

• random subdomains
• broken branding
• lost SEO value

Static Proxy solves that.

You keep everything under your main domain.

4. Hybrid WordPress (Without the Complexity)

You don’t need to go full headless to get headless benefits.

You can:

• Keep WordPress for content, blog, CMS
• Use static pages for high-performance routes

Best of both worlds.

How It Works (Without Getting Too Deep)

At a high level:

• The plugin intercepts requests early (template_redirect priority 0)
• If a route matches, it proxies the external page
• It rewrites:
  • links
  • assets
  • canonical URLs
• It supports:
  • SPA fallbacks
  • asset proxying
  • caching with stale-on-error

So from the browser’s perspective:

👉 It looks like a normal page on your domain
👉 But it’s actually coming from somewhere else entirely

What Makes This Different

There are a few things I really like about how this turned out:

1. Exact Path Mapping

You control routes precisely:

/black-friday → external page

No hacks. No subdirectories. No weird rewrites.

2. No Theme Involvement

This is key.

We’re not injecting into WordPress templates.

We’re bypassing them entirely.

3. Asset Proxying

Even if your static page references:

/hero_bg.png

It still works.

The plugin handles that.

4. Built for Real Use

This wasn’t built as a side project.

We built it because we needed it:

• for static pages
• for checkout flows
• for performance-critical routes

Then realized…

we should just open source it.

Where This Is Going

This is part of a bigger shift I’m seeing:

• WordPress becoming more of a hub
• Static + AI-generated pages becoming the frontend layer
• Infrastructure getting pushed closer to the edge (Cloudflare, etc.)

You don’t need to rip out WordPress.

You just need to stop forcing everything through it.

Final Thought

Most teams don’t need a full headless architecture.

They just need:

• speed
• flexibility
• freedom to build outside WordPress

This gives you that.

Without blowing everything up.

If you’re experimenting with:

• faster funnels
• static sites
• AI-generated pages
• hybrid architectures

You’ll probably find some interesting use cases here.

And I’m curious to see what people build with it.