Frequently Asked Questions

Questions about
NinjaWeb5

Execution, governance, auditability, SEO, AI integration, security, and delivery-time control — explained.

What is NinjaWeb5

A programmable delivery-time control layer for the web.

NinjaWeb5 operates after HTML is generated and before it reaches the browser — governing delivery, not generation.

It does not store content, render pages, or replace CMSs, frameworks, or backend systems. It introduces a controlled execution phase that has never existed as a structured architectural layer.

Delivery Path
Origin / CMS / App
→
⚡ NinjaWeb5
→
Browser
NinjaWeb5 governs delivery, not generation.
Governed Deterministic Auditable
Browse by Topic

Jump to a category

01 General 02 Architecture & Execution 03 Rules & Governance 04 Audit & Traceability 05 Security 06 AI Integration 07 SEO 08 Conversion & CRO 09 Compliance & Legal 10 Enterprise & Operations 11 Comparison
Start Here

Quick answers

⚡
What is NinjaWeb5?

A programmable HTML delivery layer that operates after HTML is generated and before it reaches the browser. Governed. Deterministic. Auditable.

🌐
Where does it run?

At the edge, in the delivery pipeline — after the origin server, before the browser, outside application runtimes.

🚫
Is it a CMS or framework?

No. NinjaWeb5 does not store content, render pages, or replace CMSs or frontend frameworks. It governs delivery, not generation.

🔧
Is it JavaScript-based?

No. NinjaWeb5 does not rely on client-side DOM mutation, JavaScript SDKs, or browser execution.

📋
Can it be audited?

Yes. Every execution records rule matches, decisions, execution order, duration, and failure reasons — in both dry-run and live mode.

🧪
Can it be tested before production?

Yes. Dry-run executes the full real pipeline without delivering changes to users. Safe testing against real HTML.

General

Core concepts and product fundamentals

What is NinjaWeb5?
NinjaWeb5 is a programmable HTML delivery layer that operates after HTML is generated and before it reaches the browser. It introduces a controlled execution phase — post-generation, pre-delivery — that has not previously existed as a structured architectural component in the web stack.
Is NinjaWeb5 a CMS or a frontend framework?
No. NinjaWeb5 does not store content, render pages, replace frontend frameworks, or replace CMSs. It governs delivery, not generation. Existing stacks remain untouched.
Is this a JavaScript-based solution?
No. NinjaWeb5 does not rely on client-side DOM mutation, JavaScript SDKs, or browser execution. It operates server-side, at delivery time — before the browser receives HTML.

Architecture & Execution

Where NinjaWeb5 runs and how execution phases work

Where does NinjaWeb5 run?
NinjaWeb5 runs in the delivery pipeline, typically at the edge. It sits after the origin server, before the browser, and outside application runtimes. Backend logic, APIs, and business rules remain untouched.
What does "delivery-time execution" mean?
Delivery-time execution means changes are applied after HTML exists but before users receive it. This is distinct from generation (CMS, SSR, static build) and distinct from client-side mutation (JavaScript DOM changes after page load).
What are execution phases?
NinjaWeb5 supports three execution phases: Request phase (before HTML is fetched from origin), Response phase (after HTML is generated, before delivery), and Both (decisions made at request time, applied at response time).
Why is the Response phase important?
The Response phase gives access to the complete HTML structure. This is where structural modifications, semantic enforcement, and safe transformations are applied — making it the critical phase for SEO, compliance, and conversion work.
Why would a rule use Both phases?
Some decisions must be made before HTML exists — for example, routing or user-context evaluation — but the resulting changes can only be applied after HTML is generated. The Both phase handles this split-execution pattern cleanly.

Rules & Governance

How rules are defined, evaluated, and tested

What is the rules model?
Every rule explicitly defines WHEN it runs, WHERE it applies, WHAT it changes, and HOW it executes safely. Rules are not scripts — they are structured, auditable declarations of behavior.
Are rules deterministic?
Yes. Rules are ordered, evaluated sequentially, auditable, and reversible. Given the same input and conditions, a rule produces the same output — always.
What happens if a selector does not match?
Execution behavior is explicit: the rule either skips safely (no change) or fails visibly with a logged reason. There is no silent failure and no undefined behavior.
Can rules be tested before production?
Yes. Dry-run executes the full real pipeline against real HTML without delivering changes to users. Diffs, audit traces, and execution logs are available — identical to live mode.
Additional Topics

Specific areas

Audit & Traceability

What does NinjaWeb5 audit?
Every execution records rule matches, action decisions, applied vs skipped steps, execution order, duration in milliseconds, and failure reasons.
Is audit available in production?
Yes. Audit works identically in dry-run and live execution. The record is consistent regardless of mode.
Can audit data be used for compliance?
Yes. Audit enables legal verification, SEO review, security review, and performance analysis. Records are structured and exportable.
Can changes be rolled back?
Yes. Rules and components can be disabled instantly, version-locked, and rolled back without redeployment or CMS access.

Security

Does NinjaWeb5 execute arbitrary code?
No. NinjaWeb5 executes declarative actions, not arbitrary scripts. Execution scope is bounded by the rule definition.
How does NinjaWeb5 prevent XSS?
Through strict URL scheme validation, attribute sanitization, selector validation, and execution caps on all rule actions.
Does NinjaWeb5 require elevated permissions?
No. NinjaWeb5 does not require database access, source code access, or CMS admin permissions. It operates on the delivery layer only.

AI Integration

How is AI used in NinjaWeb5?
AI is treated as a content source, not an execution engine. AI-generated components pass through the same governance layer as any other content.
Can AI content be reviewed before delivery?
Yes. AI-driven components can be previewed, dry-run tested, approved, and version-locked before reaching users.
Can AI output be rolled back?
Yes. Rollback is instant and does not require CMS changes or redeployment. Version history is preserved.

SEO

How does NinjaWeb5 help SEO?
NinjaWeb5 enables semantic HTML enforcement, meta and schema injection, structural consistency, and deterministic output — all applied before the browser receives the page.
Does Google see the modified HTML?
Yes. Search engines receive the final delivered HTML, not a mutated DOM. Changes are real and crawlable.
Is this safe for indexing?
Yes. Changes are server-side and deterministic. There is no flicker, no JavaScript dependency, and no deferred rendering that could affect crawlers.

Conversion & CRO

How is this different from A/B testing tools?
Traditional A/B tools mutate the DOM after page load, cause visible flicker, and depend entirely on JavaScript execution. NinjaWeb5 applies changes at delivery time — before the browser renders anything.
Can NinjaWeb5 replace A/B testing tools?
It can replace delivery-time experiments, layout-level tests, and conversion UI changes. For statistical experiment management, it complements rather than replaces analytics platforms.

Compliance & Legal

Can NinjaWeb5 enforce legal requirements?
Yes. NinjaWeb5 can inject compliance banners, enforce disclaimers, remove outdated legal text, and target content by region — all at delivery time without touching origin code.
Is compliance auditable?
Yes. Audit trails provide verifiable proof of what was delivered, when it was delivered, under which rules, and under which conditions.

Enterprise & Operations

Is NinjaWeb5 suitable for large organizations?
Yes. It supports centralized governance, multi-team control, versioned rollouts, and safe experimentation across large and distributed web properties.
Can agencies use NinjaWeb5?
Yes. Agencies use it to manage multiple clients, reuse component packs, enforce standards, and scale delivery governance without requiring CMS access.
Does NinjaWeb5 scale across platforms?
Yes. It is CMS-agnostic, framework-agnostic, and language-agnostic. Any HTML-delivering system is compatible.

Comparison

How is NinjaWeb5 different from client-side JavaScript tools?
Client-side tools run after page load, mutate the DOM, introduce visual flicker, and are invisible to governance systems and crawlers. NinjaWeb5 operates before the browser — changes are real, auditable, and crawlable.
How is NinjaWeb5 different from server-side rendering?
Server-side rendering is part of application logic. NinjaWeb5 operates outside the application — after HTML is generated, independent of the rendering framework or language.
How is NinjaWeb5 different from templating engines?
Templating engines generate HTML. NinjaWeb5 governs already-generated HTML. The two phases are distinct — NinjaWeb5 does not replace templating; it operates after it.
What does NinjaWeb5 replace?
NinjaWeb5 does not replace existing systems. It introduces control where there was none — a delivery-time governance layer that previously did not exist as a structured architectural component.
Still have questions?

See NinjaWeb5 in action.

Dry-run a real rule against real HTML. No code changes required.

Request Demo
Try Live Demo →