StaticForge for Cloudflare Pages

Yes. Direct Upload deployments don’t consume build minutes. There’s a soft cap of about 100 deployments per day per project — the plugin’s debounce setting (default 120 seconds) keeps you well under that for normal editorial workflows.

No — two-tier dedup is built in.

General SEO plugins (handle everything: meta + og + schema) — when any of these is detected, ALL our injection is skipped: Yoast SEO (free or Premium), Rank Math, All in One SEO Pack (v4+ and legacy), SEOPress, The SEO Framework, Slim SEO, Squirrly, SmartCrawl, WP Meta SEO.

Schema-only plugins (handle only JSON-LD) — when any of these is detected, ONLY our JSON-LD is skipped, but our meta description, robots, canonical, Open Graph, and Twitter Card tags still emit so you don’t lose social previews: Schema & Structured Data for WP & AMP (saswp by Magazine3), Schema Pro, WPSSO Core, Schema (by Hesham), Schema App, Magazine3 Schema variants.

Niche plugin not in either list? Extend detection via the sforge_seo_competing_plugin filter (general) or sforge_schema_competing_plugin filter (schema-only), or simply untick the “Inject SEO meta” setting.

If the plugin can reach sitemap.xml , sitemap_index.xml , or wp-sitemap.xml on your origin, it mirrors that as-is (including all child sitemaps for sitemap-index files).

If none are reachable, the plugin generates sitemap.xml itself from the Sitemap Generator settings (StaticForge for Cloudflare Pages → Settings → Sitemap Generator):

• Post Types — multi-checkbox of public post types. Default: post + page.
• Include Homepage — adds the front page and posts page (if separate).
• Include Taxonomy archives — all public taxonomy term archives.
• Include Author archives — authors with at least one published post.
• Split into multiple files — off (single sitemap.xml ) or on (a <sitemapindex> referencing per-type sub-sitemaps such as sitemap-post.xml , sitemap-page.xml , sitemap-authors.xml , sitemap-taxonomy-category.xml ).

Sitemap inclusion is independent of Export Scope, so you can export a CPT without listing it in the sitemap and vice versa. Filter sforge_sitemap_groups exposes the grouped URL list for custom modification.

The activity log shows which path was taken: Sitemap mirrored from origin: ... vs Sitemap generated locally (single mode|split mode): N URLs ... .

By default the plugin keeps /wp-content/* URLs (theme CSS/JS, plugin assets, uploads) pointing at the WordPress origin so those assets keep working without bundling multi-gigabyte folders in every deploy. Structured data ( og:image , JSON-LD image / logo / thumbnailUrl ) and <img src> will therefore reference your dashboard host on the deployed site.

To make every URL on the deployed site reference the live host, you need a proxy on the live host that forwards /wp-content/* requests back to the WordPress dashboard, and then tick Export Scope → Rewrite /wp-content/ URLs in the plugin settings.

Cloudflare Worker (recommended). Create a Worker ( Workers & Pages → Create application → Workers → Hello World ) with this code:

export default { async fetch(request) { const url = new URL(request.url); if (url.pathname.startsWith(‘/wp-content/’)) { url.hostname = ‘dashboard.example.com’; return fetch(url, request); } return fetch(request); } };

Replace dashboard.example.com with your actual dashboard host. Deploy, then add routes example.com/wp-content/* and www.example.com/wp-content/* under the Worker’s Triggers tab.

Nginx / Apache reverse proxy. On the live host:

location /wp-content/ { proxy_pass https://dashboard.example.com; proxy_set_header Host dashboard.example.com; proxy_ssl_server_name on; }

Verify with curl -I https://example.com/wp-content/uploads/some-file.jpg — it should return HTTP 200 with the image content-type. Only then tick the Rewrite /wp-content/ URLs setting and Rebuild + Deploy Now .

If the toggle is on but no proxy is set up, every image, theme stylesheet, and plugin script on the deployed site will return 404.

The full step-by-step is also available inside the plugin: StaticForge for Cloudflare Pages → Setup Guide → Clean /wp-content/ URLs (advanced) .

Shared-hosting servers (HostArmada, SiteGround, GoDaddy, etc.) often block traffic from Cloudflare Workers / proxy IPs. Symptoms: the proxy approach above returns 522 or 520 for /wp-content/uploads/* , while a direct browser request to dashboard.example.com works fine. You usually cannot whitelist Cloudflare’s edge IPs on shared hosting.

Solution: tick Export Scope → Bundle /wp-content/uploads/ into deploy (leave Rewrite /wp-content/ URLs off). The plugin then:

1. 01Scans every rendered page for /wp-content/uploads/... references ( <img src> , srcset , og:image , JSON-LD image / logo / thumbnailUrl , inline CSS url() , oEmbed thumbnails).
2. 02Fetches each unique file from your origin during rebuild.
3. 03Uploads them into the Cloudflare Pages deploy at their original /wp-content/uploads/... paths.
4. 04Rewrites image URLs in HTML/JSON-LD to the live host so the static site is fully self-contained.

Theme CSS/JS and plugin assets still load from the origin (those rarely cause shared-hosting firewall issues). Cost scales with what’s actually referenced — only files used by exported pages get bundled, not the entire media library. Cloudflare’s check-missing API deduplicates unchanged files between deploys so subsequent rebuilds only upload new images.

Verify after deploy: curl -I https://example.com/wp-content/uploads/<any-image>.jpg should return HTTP 200 with Server: cloudflare (served by CF Pages, not your origin).

The crawler finds files by following the links in your rendered pages, so anything nothing links to never gets discovered. A BIMI logo is the classic case: your DNS record points straight at it, no page references it, and so it’s missing from the deploy. The same goes for ads.txt , an apple-app-site-association file, a domain-verification file, security.txt , or a PDF you only hand out by direct link.

Use Extra paths to include in the plugin settings (a text box, one path per line, relative to your WordPress root). Everything you list there is copied straight off disk into the deploy whether or not a page links to it.

For a BIMI image, put the SVG somewhere inside your WordPress install and list its path. If you want a tidy URL like /.well-known/bimi/logo.svg , create a .well-known/bimi/ folder in your WordPress root, drop the file in, and add:

.well-known/bimi/logo.svg

If the exact URL doesn’t matter (BIMI lets your DNS record point at any URL), the uploads folder is fine:

wp-content/uploads/bimi/logo.svg

You can also list a whole folder ( wp-content/uploads/bimi ) or a wildcard ( wp-content/uploads/bimi/*.svg ) instead of naming each file. Rebuild + Deploy, and the file lands at the matching path on the live site. Then set your BIMI DNS record’s location to that final URL.

Two BIMI-specific notes the plugin can’t do for you: the SVG must be the “SVG Tiny Portable/Secure” profile that mailbox providers require, and if you use a VMC certificate its URL goes in the a= tag of the same record. The plugin’s job here is just making sure the file is actually there to be fetched.

This is the most common cutover mistake, and it also blocks redeploys. Symptom: clicking into wp-admin sends you to the public host’s login, e.g. https://example.com/wp-login.php?redirect_to=https%3A%2F%2Fdashboard.example.com%2Fwp-admin%2F... . But example.com is now the static Cloudflare Pages site with no WordPress on it, so login fails — and you can’t reach the plugin to redeploy.

Cause: WordPress’s own WP Address ( siteurl ) and Site Address ( home ) are still set to the public host ( example.com ). WordPress builds the login URL from siteurl , so it sends you to the static site instead of your dashboard.

Fix: point WordPress’s two addresses at your dashboard host. The reliable way (works even when you’re locked out of wp-admin) is to add these to wp-config.php , just above the line /* That's all, stop editing! Happy publishing. */ :

define( ‘WP_HOME’, ‘https://dashboard.example.com’ ); define( ‘WP_SITEURL’, ‘https://dashboard.example.com’ );

Save, then log in from a private/incognito window (so stale cookies don’t interfere) at https://dashboard.example.com/wp-admin .

Important — keep the two settings separate. WordPress itself lives on dashboard.example.com ; the plugin’s Public Site URL stays https://example.com . The renderer rewrites the dashboard host to the Public Site URL during export, so the deployed static site still shows clean example.com links. Only WordPress’s own WP Address / Site Address move to the dashboard subdomain — never the plugin’s Public Site URL.

The rebuild runs on a WordPress scheduled event a few seconds after you click, so it depends on WP-Cron. You’ll see Full rebuild queued (manual). in the log immediately, but if DISABLE_WP_CRON is defined or the site gets almost no traffic, the event may never fire and you won’t see Full rebuild started. . Load any front-end page to nudge WP-Cron, or set up a real system cron hitting wp-cron.php every minute.

Account ID, API token and project name are required — one of the three fields is blank. Fill all three and Save before testing. Project not found — the Pages Project field must be the project slug only (e.g. mysite ), never the full mysite.pages.dev URL. Also confirm the project is in the same Cloudflare account whose Account ID you pasted. An authentication / HTTP 403 message — the API token is wrong, expired, or under-scoped. Recreate