What each screen in the plugin is for, what its numbers actually mean, and — for each one — the thing people most often misread.
Almost every misunderstanding of this plugin comes from collapsing two separate settings into one. They are not alternatives, and they do not override each other:
Tulapp
wp-admin and the
WordPress runtime at all. The Admin Access Gateway, Zero-WordPress Mode and Vault
Mode live here.
Any Serving Mode can be combined with any isolation setting. A Hybrid site can run a sealed Vault; a Fully Static site can have no isolation beyond the gateway. When something says "protection", check which of the two axes it is talking about.
What is true about this site right now.
The landing screen: build status, static coverage, your active configuration, and a grid of tiles summarising each Shield feature. The tiles are deliberately live values, not switches — they answer "what is actually true", not "what did I turn on".
The numbers:
Most misread: a tile saying Not scanned yet or Not checked is not the same as a clean result. The plugin never reports "clean" for something it has not actually checked — if it cannot reach Tulapp Cloud, it says so rather than implying everything is fine.
How pages are delivered to visitors.
Three modes, changed only through the Configuration Wizard so the change is always a deliberate, guided one:
| Mode | What reaches WordPress | Best for |
|---|---|---|
| Fully Static | No public request reaches the WordPress runtime at all — only static files and narrow Shield services. | Brochure sites, blogs, high-security needs |
| Static + Bridges | Static for every visitor, with a small number of explicit routes bridged back to WordPress. | Sites with a contact form or consent banner |
| Hybrid | Static by default, dynamic where required — WordPress stays reachable for anything not explicitly built. | Shops and complex sites |
Most misread: Hybrid is not "half protected". Every page that serves statically in Hybrid is exactly as static as it would be in Fully Static — the difference is what happens to the requests that aren't covered. Hybrid leaves WordPress reachable for those; Fully Static does not.
Every component installed, how Static Shield classifies it, and what it found.
One expandable row per installed component. The row summarises the classification, confidence, update state and security findings; expanding it shows the individual features, their risks, the public routes the component genuinely needs, and its full advisory list.
The columns:
Most misread: "Not checked" in the Security column means Tulapp Cloud has not been able to check that component — usually because the site is not connected yet. It does not mean no vulnerabilities exist.
Proving what is genuinely dynamic, rather than assuming.
Renders a page twice as two independent anonymous visitors and diffs the results. Whatever still differs between two anonymous loads is genuinely dynamic — not just page-to-page noise. A third render, authenticated as a dedicated minimal-privilege internal account (never a real admin session), shows what additionally changes for a logged-in viewer.
You can scan a single page, or every route in the current build manifest as a background job in Tulapp Cloud.
Why two anonymous renders and not one? Plenty of markup differs between any two page loads for uninteresting reasons — nonces, timestamps, rotating banners. Diffing two anonymous renders removes that noise, so what remains is a real difference worth acting on rather than a false positive you learn to ignore.
Reducing the free signals that say "this is WordPress".
Removes passive fingerprint exposure from your public static site: generator tags, discovery links, and version query strings that tell an automated scanner what you are running, and which version, at no cost to the scanner.
The tab reports a reduction percentage — how much of the detectable fingerprint it removed compared with the unshielded output.
Most misread: this reduces fingerprint exposure. It does not make WordPress undetectable, and we will not claim it does. A determined human looking at your markup, URLs or asset paths can still identify WordPress. The value is against automated mass scanning that fingerprints cheaply and moves on — not against a targeted analyst.
What is actually reachable from the public internet.
A map of which parts of this WordPress installation respond to a real request — verified against live HTTP responses, not inferred from configuration. Each known core route carries a policy (Private, Blocked, Required, Hybrid, Review, Replaceable) and a risk rating, and the scan reports anything reachable that shouldn't be.
Unexpected routes is the number worth watching: routes answering publicly that your policy says should not be.
Verified from outside, deliberately. A probe run by the server against itself loops back through the site's own network and can look like trusted traffic even when it isn't. Scans that matter run from Tulapp Cloud, on infrastructure separate from your site, so a "blocked" result means blocked for the internet — not merely blocked for something asking from inside the building.
Who can reach WordPress dynamically, and how completely it can be isolated.
Three layers, increasingly strict:
wp-login.php and
wp-admin answer only for allowlisted addresses. Everyone else is refused.
wp-admin, and it reseals automatically.
Also here: the local allowlist, and a read-only view of your Cloud-synced Trusted IPs.
Before you enable any of these, read Recovering access. Every one of these layers can lock you out of your own site — that is what they are for — and each has a specific WP-CLI command to undo it. Knowing the command in advance costs nothing; discovering it exists while locked out is a different experience.
Telling your webserver to serve the static release.
Static Shield builds the static site, but your webserver decides whether to serve it.
Apache and LiteSpeed both read .htaccess, and WordPress already manages rules
there for permalinks — this uses the same mechanism to add its own block ahead of
WordPress's rules, so it takes priority. One click, no manual editing.
nginx, Caddy and IIS cannot be configured from inside WordPress; the tab gives you copy-paste snippets instead. See Webserver configuration.
Verification fetches your own homepage and checks whether the response really looks like a static file — a hidden cache stamp, plus caching headers a static file gets and a PHP response never does.
Most misread: a successful build does not mean visitors are being served static pages. Until the webserver rule is in place and verified, WordPress is still answering every request and the build is just sitting on disk. This is the single most common reason a site "isn't any faster".
See the shielded site before anyone else does.
Builds a complete Static Shield candidate without touching your live site. You can review it, compare it against the current dynamic WordPress, and enable it when you're ready — or not at all. Your public site stays exactly as it is until you explicitly click Enable.
The Compatibility Validation Checklist tracks the manual checks worth doing before you publish — the things only you can judge, like whether a form still submits or a members' area still behaves.
Validation runs in Tulapp Cloud, not on your server. It needs a real browser to render pages, and it needs to see the candidate from outside. That makes it a Pro feature, and it means the result reflects what a visitor would get rather than what your own server thinks it would send.
Search without executing WordPress.
WordPress's native search (?s=) is a live database query on every search — one
of the few remaining reasons a "static" site still hits PHP. Static Search generates an
index from your published content during each build and serves results from it instead.
The tab reports the document count and how many WordPress requests a search now costs. With search analytics enabled that figure is 1, not 0 — recording a search term writes to the database, so the honest number is one request, and we show it rather than rounding it to zero.
The index is a build artefact. Content published after the last build is not in it until you rebuild. If search results look stale, that is why.
What this installation is, and what changed.
A versioned fingerprint captured on every build and diffed against the previous version automatically, across four layers:
This is what powers change detection ("a plugin updated itself overnight"), vulnerability matching against exactly what is installed, and the Shield posture used for mitigation estimates.
What is never sent: post content, form submissions, user data, passwords, or plugin settings. DNA is counts, names, versions and classifications — the minimum needed to tell you a vulnerable version is installed.
Version, tier, licence and support.
Which build of the plugin you are running, which runtime tier it detected, your licence state, and how to get help.
Runtime tier is worth understanding because it changes which features exist at all. The plugin ships two bootstraps: a modern one using namespaced PHP 8.1 classes, and a legacy-safe one that runs as far back as PHP 5.6. Features built on the modern runtime — the Hybrid Compatibility Layer among them — are unavailable on the legacy tier, and the plugin says so plainly rather than showing you an empty screen.