The starting point of this work was a simple but critical need: to build a website that is both secure and high-performance. Over time, this goal evolved beyond making a site “faster” and led to questioning the architecture itself. WordPress was a powerful content production tool, but when it was also responsible for content delivery, it introduced unnecessary security and performance risks. To address this, WordPress was deliberately limited to content production only, while all published content was delivered through a fully static website. This architectural decision resulted in significant gains on both the security and performance fronts.

---

The Problem: Dynamic CMS and Public Exposure

In a typical setup, WordPress:

• Produces content
• Stores content
• Serves content directly to end users

In enterprise environments, this creates several risks:

• A large attack surface (PHP runtime, plugins, admin panel)
• Performance degradation under traffic spikes
• Content management and content delivery tightly coupled

The key objective of this project was clear:

Strictly separate content management from content delivery.

---

The Solution: WordPress and Static Site Separation

Roles were deliberately split across the architecture.

The Role of WordPress

• Manages editorial workflows
• Produces content
• Exports content as ZIP files
• Exposes a read-only API listing available exports

WordPress:

• Does not serve content
• Does not handle traffic
• Does not maintain runtime state

---

The Role of the Static Website

• Delivers content to end users
• Consists purely of HTML, CSS, and JavaScript
• Runs without PHP, databases, or server-side logic

As a result:

• The attack surface is drastically reduced
• Performance becomes independent of traffic volume

---

Content Synchronization and Internal Network Security

Content produced in WordPress is handled by a dedicated Content Sync Service:

• Periodically checks the export list
• Detects new ZIP packages
• Uses Redis-based locking to prevent duplication
• Transfers ZIP files into the internal network
• Extracts content and produces static site output

In this model:

• WordPress never accesses the internal network
• Internal systems are never exposed publicly
• Data flow is strictly one-directional (pull-based)

This aligns well with enterprise IT and information security best practices.

---

Performance

Performance gains come directly from architectural decisions:

• A single ZIP transfer instead of thousands of files
• Static assets served from disk or CDN
• Complete removal of PHP execution and database queries

As a result:

• Initial load times are minimal
• Traffic spikes do not impact performance
• User experience remains consistent

---

Security

From a security perspective, the architecture ensures:

• No executable backend on the public website
• WordPress is fully isolated from content delivery
• Content processing remains within the internal network
• State and synchronization are centralized and controlled

This provides a clear answer to a critical question:

Even if WordPress is compromised, the static site and internal network remain unaffected.

---

Dynamic Search on a Static Site (with Algolia)

The only dynamic feature on the static website is search functionality, implemented using Algolia.

• Content is produced in WordPress and published as static files
• The same content is indexed in Algolia
• The static site queries Algolia via JavaScript

From the user’s perspective:

• Instant search results
• Filtering capabilities
• Smooth navigation experience

From a technical standpoint:

• No backend runtime
• No application state
• No direct connection to WordPress

Users experience a dynamic interface while actually browsing a fully static website.

---

Conclusion

With this architecture:

• WordPress was simplified
• Content delivery became fully static
• Security and performance were achieved together
• The system became suitable for enterprise-scale use

After the architectural change, the website’s loading performance improved by 45%.

In short:

WordPress produces content, the static site delivers it, and users never interact with WordPress directly.