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: Nginx 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: Scans every rendered page for /wp-content/uploads/... references (<img src>, srcset, og:image, JSON-LD image/logo/thumbnailUrl, inline CSS url(), oEmbed thumbnails). Fetches each unique file from your origin during rebuild. Uploads them into the Cloudflare Pages deploy at their original /wp-content/uploads/... paths. Rewrites 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. After DNS cutover I can't log in to wp-admin — it bounces me to the live site. 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 it with exactly Account · Cloudflare Pages · Edit and Account Resources including the right account. Upload token request failed — the token tested OK but lacks write access; recreate it with the Edit (not Read) permission.

Deploy FAIL: Request body is incorrect — an old plugin build. v1.0.0+ sends multipart/form-data; update the plugin. Skipping "<file>" (NN MB): exceeds Cloudflare's 25 MiB per-file limit — Cloudflare Pages rejects any single file above 25 MiB. The plugin now catches these before the upload, names the file in the log, leaves it out, and deploys the rest. Host the file externally (Cloudflare R2, an object store, a CDN) and link to it, or shrink it under 25 MiB (re-encode the video, compress the PDF, downscale the image). Asset upload failed: HTTP 4xx/5xx ... — Cloudflare rejected the upload. The log now quotes the HTTP status when Cloudflare doesn't return a structured error (older builds showed a bare unknown here). HTTP 413 means a file too large slipped through; a 5xx or a timeout is usually transient, so re-run the deploy. Deployment failed — a Cloudflare-side rejection (the reason is quoted in the log); the common cause is more than 20,000 files in one deployment (CF Pages free-tier limit). Trim Export Scope. check-missing failed — a transient API / token hiccup; re-run the deploy, and re-test the connection if it persists. My exported page is huge (tens of MB) and the deploy hits the 25 MiB limit. On Elementor especially. Almost always a missing stylesheet that "soft-404s". When a CSS file no longer exists, a well-behaved server returns a 404 — but many WordPress setups instead return the homepage with a 200 "OK" status. With Inline CSS on, the plugin asks for that file expecting CSS and gets a whole HTML page back, then embeds the entire page into a <style> block. A few of those and the page balloons into the tens of megabytes. The usual culprit is Elementor's cached Google Fonts. Elementor stores them as CSS files named after your host (wp-content/uploads/elementor/google-fonts/css/roboto-<host>.css). If that cache was generated under a different hostname — common after a migration or when your dashboard lives on a subdomain — the old file is gone and the site serves the homepage in its place. As of 1.8.4 the plugin detects this and refuses to inline anything that comes back as HTML, so the bloat is fixed on the plugin side. To also restore the missing fonts, regenerate the cache: in WordPress go to Elementor → Tools → Regenerate CSS & Data. Then Rebuild + Deploy Now. Some pages didn't render ("Render fail ... HTTP" / "Nothing rendered"). The plugin fetches your own URLs via wp_remote_get. A few failures are harmless; many of them (or Nothing rendered, deploy skipped.) mean the site is blocking itself — HTTP basic auth, an IP allow-list, an aggressive WAF, Cloudflare "Under Attack" mode, or a coming-soon / maintenance plugin. Let the origin fetch itself, or pause the blocker during deploys. For an invalid / self-signed origin certificate during migration, add add_filter( 'sforge_sslverify', '__return_false' );. My .pages.dev URL doesn't redirect to my domain. The redirect is a client-side JavaScript snippet (the Direct Upload API can't run _worker.js / Functions), so curl -I won't reveal it — test in a real browser. It only fires when Public Site URL is a real domain (not a .pages.dev URL) and the "Redirect *.pages.dev to live host" toggle is on. "Sitemap fallback skipped" or "returned no files" in the log. Your origin exposes no sitemap, so the plugin tried to generate one. Sitemap fallback skipped: no post types / archives selected means everything is unticked under Sitemap Generator — tick at least one post type / Homepage / Taxonomies / Authors. Sitemap fallback returned no files means nothing published matched the selection — confirm you have published content in those types. "Bundle uploads enabled, but no /wp-content/uploads/ references found". An image optimiser is swapping image URLs with JavaScript (e.g. EWWW Lazy Load or Easy IO), so the real URLs aren't in the rendered HTML for the bundler to find. Turn off the JS lazy-load / Easy-IO feature (keep the compression) and rebuild.

The plugin scans your post for any of: Yoast FAQ blocks, Rank Math FAQ blocks, SEOPress FAQ blocks, OR native HTML5 <details><summary>Question</summary>Answer</details> markup. If found, a FAQPage schema with Question / Answer items is emitted.