How to Cloak a WordPress Website: Complete Integration Guide

🤔 Why WordPress Needs a Different Setup

A normal white page is a folder of static HTML files. You upload it, point your flow's white page setting to it, and you're done — the cloaking engine serves it directly with no extra steps. WordPress is not a folder of static files. It is a PHP application with its own front-controller (index.php) and its own routing rules baked into .htaccess. Every single URL on a WordPress site — the homepage, blog posts, category pages, even images and feeds in some setups — passes through that one index.php file before WordPress decides what to actually render.

This creates a direct conflict: your downloaded cloaking index.php also wants to be the front controller of the domain. Two front controllers cannot both occupy index.php at the same time. If you don't understand this conflict and just overwrite WordPress's file, you will get a broken site, missing click logs, or duplicate entries. This guide explains exactly how to set it up so WordPress works as a real, fully-clickable white page with zero side effects.

❌ The Wrong Way (and Why It Fails)

The instinct most people have is: "I'll rename WordPress's index.php to something else, drop the cloak's index.php in its place, and set the white page to redirect to the renamed file." This half-works and creates two separate problems depending on how you wire it up:

Redirect-based linking: If your white page setting redirects the browser to the renamed WordPress entry file (e.g. https://yourdomain.com/site.php), the visitor's address bar changes to that URL. From that point on, every link the visitor clicks inside WordPress is served directly by WordPress — completely bypassing your cloak. You lose the ability to log those clicks, and worse, a moderator who reloads the page or revisits later may suddenly see WordPress directly with no cloaking layer at all.
Direct overwrite without an include: If you only swap the files without telling the cloak how to render WordPress in place, the homepage may load WordPress directly (cloak never runs) while every internal link 404s, or you get the opposite — the homepage cloaks correctly but every internal page shows the wrong (offer) content because the engine has no idea what page WordPress was asked for.

🚫 Neither outcome is acceptable for a real campaign. The fix is not a workaround — it's using the correct white page type that CyberCloakTDS already supports for exactly this situation.

✅ The Correct Method: "Loading (Local File)" White Page

CyberCloakTDS has a white page mode built specifically for this scenario: Loading (Local File). Instead of redirecting the browser to another URL, the engine includes the local PHP file directly from inside index.php while keeping the original request untouched. This one detail is what makes WordPress integration work correctly:

📍 The browser's address bar never changes — the visitor stays on your campaign domain the entire time.
🧩 $_SERVER['REQUEST_URI'] (the exact path the visitor asked for — homepage, a blog post, a category page, anything) is preserved across the include.
🔄 WordPress receives that original request path, runs its own routing exactly as it normally would, and renders the correct page — homepage, post, category, search results, all of it.
📊 Every single visit — including internal navigation inside WordPress — still passes through the cloak first, so your click logs stay accurate and bots/moderators always see the cloak's verdict applied.

💡 This is the same architecture used by every serious cloaking platform for CMS integrations — the cloak's front controller stays in charge of the decision, then hands off rendering to the CMS without losing the request context.

🔧 Step-by-Step Setup

📄 Step 1 — Rename WordPress's Entry File

On your campaign domain (where WordPress is already installed and running normally), locate the existing index.php in the web root and rename it to something that will never collide with the cloak's file — for example site.php or wp-front.php. Do this through your hosting file manager or FTP/SFTP. WordPress itself does not care what its front-controller file is named — it only matters that something correctly loads wp-blog-header.php and the WordPress bootstrap, which the renamed file still does untouched.

⚠️ Do not delete or modify the contents of this file. You are only changing its filename so the cloak's index.php can take the original spot.

⚙️ Step 2 — Build Your Flow with the Correct White Page Type

Go to Flows → New Flow (or edit your existing flow) and in the white page section, choose Loading (Local File) as the white page type. In the file path field, enter the path to the renamed WordPress entry file relative to your domain root — for example:

site.php

Configure the rest of the flow exactly as you would for any other campaign — Offer URL, traffic filters, Block Bots, Block VPN, click limits, warmup mode. None of that changes for WordPress integrations. The only thing that's different is the white page type and path.

📥 Step 3 — Download and Upload index.php

Save the flow and click Download index.php. Upload this file into the web root of your campaign domain — the exact same folder where WordPress lives, and the exact same location where the original index.php used to be. The filename must be exactly index.php so the web server treats it as the default entry point.

At this point your folder structure should look like this:

public_html/
├── index.php          ← cloak's generated file (NEW — this runs first)
├── site.php           ← renamed WordPress entry file (the OLD index.php)
├── wp-admin/
├── wp-content/
├── wp-includes/
├── wp-config.php
└── .htaccess

🧹 Step 4 — Disable Page Caching, Then Purge It

🚨 This step is mandatory, not optional — skipping it is the single most common reason WordPress cloaks "don't work." Any plugin or system that caches full rendered HTML pages — LiteSpeed Cache, WP Super Cache, W3 Total Cache, WP Rocket, hosting-level full-page cache, or Cloudflare APO — will intercept the request before your PHP code ever runs.

Cloaking depends entirely on PHP making a fresh, per-visitor decision on every single request. A page cache defeats that by serving the same saved HTML to everyone — bot or real visitor, no difference, no decision made.

What To Do	Why It Matters
Open your caching plugin's settings (e.g. LiteSpeed Cache → Cache tab)	This is where full-page caching is toggled on or off
Turn Enable Cache OFF completely	Stops the plugin from intercepting requests at the server level going forward
Click Purge All immediately after disabling	Removes any HTML pages that were already cached before you turned it off — without this, old cached pages keep being served until they naturally expire
Do NOT manually edit `.htaccess` cache rules	Most caching plugins auto-regenerate their `.htaccess` block on every save — manual edits get silently overwritten

💡 You can safely keep other optimization features active — image compression, minification, database/object caching, and CDN delivery for static assets (CSS, JS, images) do not interfere with cloaking. Only full HTML page caching is the problem.

🧪 Step 5 — Test Thoroughly Before Going Live

Open your campaign domain in a fresh incognito window and confirm:

✅ The homepage loads correctly and a click log entry appears with the expected verdict
✅ Clicking through to internal pages (a blog post, a category, an "about" page) renders the correct WordPress content — not the offer page, not a 404
✅ Each navigation generates exactly one click log entry — not zero, not two
✅ Set your own IP in the flow's Filter List as an allow-rule and confirm the offer page opens correctly when you visit from that IP

🤖 What CyberCloakTDS Already Handles For You

WordPress sites run dozens of background requests that real visitors never see — SEO plugin analytics pings, REST API calls from page builders, scheduled cron triggers, RSS feeds, asset requests for icons. None of these are real "visits" and none of them should ever generate a click log entry or be evaluated as a visitor. Every index.php generated by CyberCloakTDS automatically detects and skips these system-level requests before they ever reach the cloaking engine — including:

📁 favicon.ico, apple-touch-icon*.png, robots.txt — browser auto-requested assets
🔄 /wp-json/... — the WordPress REST API gateway used by Rank Math, Yoast SEO, WooCommerce, Elementor, Jetpack, and most modern plugins for background analytics and AJAX calls
🛡️ /wp-admin/..., /wp-includes/..., /wp-content/... — WordPress core and asset directories
⚙️ xmlrpc.php, wp-cron.php — WordPress system endpoints
📡 /feed/ — RSS/Atom feed routes

✅ You do not need to configure or whitelist anything for this — it ships built into every downloaded index.php automatically. This is what keeps your click counts accurate and prevents the "double entry" issue that plagues naive WordPress cloaking setups on other platforms.

🚨 Common Mistakes to Avoid

❌ Mistake	What Happens	✅ Correct Approach
Setting white page type to "Redirect URL" pointing at the renamed WordPress file	Browser address bar changes, visitor leaves the cloak permanently, internal clicks are never logged	Use Loading (Local File) so the include preserves the request and address bar
Leaving page caching enabled "just to test"	Same cached HTML gets served to everyone regardless of bot/real-visitor status — cloaking effectively does nothing	Disable full-page cache and Purge All before testing anything
Renaming the cloak's downloaded file instead of WordPress's file	WordPress remains the front controller, cloak never executes, offer is exposed to everyone including bots	The cloak's file must be named exactly `index.php` in the web root; WordPress's original file is the one that gets renamed
Forgetting to re-download after changing flow settings	Live site keeps running on the old configuration baked into the previously downloaded file	Always re-download and re-upload `index.php` after any flow change — settings are baked in at download time, not synced live

🏁 Final Checklist

📝 WordPress's original index.php renamed (e.g. to site.php) — contents untouched
⚙️ Flow's white page type set to Loading (Local File), path pointing to the renamed file
📥 Cloak's downloaded index.php uploaded to the exact same web root, named exactly index.php
🧹 All full-page caching plugins/features disabled and Purged completely
🔍 Homepage and at least two internal pages tested and rendering correctly
📊 Click Logs show exactly one entry per visit with the expected verdict
🧪 Test IP added to filter list and offer page confirmed working from that IP

🏆 Once these steps are complete, your WordPress site behaves exactly like any other white page — fully clickable, fully indexed-looking, and fully protected by the cloaking layer on every single request. This setup is what separates a cloak that survives manual ad review from one that gets flagged the moment a moderator clicks a second link.