Serving llms.txt from a Dockerized WordPress + Nginx Setup

Serhii Pylypenko — Fri, 06 Mar 2026 09:21:50 +0000

If you're running WordPress in Docker with Nginx and PHP-FPM in separate containers, you've probably hit this kind of problem before: a plugin generates a file inside the WordPress container, but Nginx can't see it because the filesystems are isolated.

That's exactly what happened when I tried to enable llms.txt support via AIOSEO on a typical Dockerized WordPress setup.

The Problem

llms.txt is a new standard (similar to robots.txt) that helps LLMs understand and index your site's content. AIOSEO generates it automatically — and so does Yoast SEO. Both plugins follow the same pattern: they write a physical file to the WordPress root directory. In a standard single-server setup, this works fine. In Docker, it doesn't.

Here's the catch:

A typical Dockerized WordPress setup looks like this:

Nginx container — handles all incoming HTTP requests
WordPress (PHP-FPM) container — runs the application

The /var/www/html directory is not a shared volume between them. This is intentional — keeping code immutable and containers isolated is good practice. But it means when AIOSEO writes llms.txt into the WordPress container's filesystem, Nginx simply can't find it and returns a 404.

The Solution: PHP Bridge Pattern

Instead of adding a shared volume (which would compromise the immutability design), I used a PHP bridge: Nginx passes llms.txt requests to WordPress, which intercepts and serves the file directly.

Two pieces needed:

1. MU-Plugin (WordPress side)

Create wp-content/mu-plugins/llms-txt-bridge.php:

<?php
/**
 * Plugin Name: LLMs.txt Bridge
 * Description: Serves llms.txt from WP container for Nginx
 */
add_action('init', function() {
    $uri = strtok($_SERVER['REQUEST_URI'], '?');

    if ($uri !== '/llms.txt' && $uri !== '/llms-full.txt') {
        return;
    }

    $filename     = ltrim($uri, '/');
    $uploads_dir  = wp_upload_dir()['basedir'];
    $uploads_file = $uploads_dir . '/' . $filename;
    $abspath_file = ABSPATH . $filename;

    // Sync from ABSPATH to uploads dir if ABSPATH version is newer
    if (file_exists($abspath_file)) {
        $abspath_time = filemtime($abspath_file);
        $uploads_time = file_exists($uploads_file) ? filemtime($uploads_file) : 0;

        if ($abspath_time > $uploads_time) {
            copy($abspath_file, $uploads_file);
        }
    }

    // Serve from uploads if available
    if (file_exists($uploads_file)) {
        header('Content-Type: text/plain; charset=utf-8');
        readfile($uploads_file);
        exit;
    }
}, 1);

Why sync to uploads? The uploads directory is typically a mounted volume, meaning the file survives container restarts. ABSPATH files don't.

2. Nginx Config

Add this location block to your nginx.conf:

location ~* ^/llms(-full)?\.txt$ {
    try_files $uri /index.php?$args;
    expires 30d;
    access_log off;
    log_not_found off;
    add_header Cache-Control "public, no-transform";
}

try_files $uri /index.php means: try to serve the file statically first; if not found, pass to PHP. Since Nginx can't see the file in the WP container, it always falls through to PHP — which is exactly what we want.

How It Works

GET /llms.txt
      │
      ▼
┌─────────────────────────────┐
│  Nginx Container            │
│  try_files → file not found │
│  → passes to PHP            │
└─────────────────────────────┘
      │
      ▼
┌─────────────────────────────┐
│  WordPress Container        │
│  MU-plugin intercepts init  │
│  Syncs file if needed       │
│  Serves with correct headers│
└─────────────────────────────┘
      │
      ▼
  200 OK (text/plain)

Don't Commit the Generated Files

Add these to .gitignore:

wp/llms.txt
wp/llms-full.txt

These files are generated per environment and contain domain-specific URLs. If you accidentally committed them, clean up with:

git rm --cached wp/llms.txt
git rm --cached wp/llms-full.txt

Troubleshooting

404 on /llms.txt

Check that the MU-plugin is in the container:

docker exec your_wp_container ls -la /var/www/html/wp-content/mu-plugins/

Check that AIOSEO generated the file:

docker exec your_wp_container ls -la /var/www/html/llms.txt

If the file doesn't exist, go to AIOSEO settings and toggle LLMs.txt off and on to regenerate.

File returns wrong domain (e.g., mysite.test instead of mysite.com)

The file was generated on a local environment. Fix:

# Delete the stale file
docker exec your_wp_container rm /var/www/html/llms.txt

# Then regenerate via AIOSEO in WP Admin

Nginx not passing requests to PHP

Verify the location block is active:

docker exec your_nginx_container nginx -T | grep llms

Why Not Just Use a Shared Volume?

A shared volume would work technically, but it breaks the immutability model — if both containers write to the same filesystem, you lose the clean separation between "application code" and "runtime state." The PHP bridge keeps infrastructure clean while solving the practical problem.

The Real Fix: Dynamic Generation

The PHP bridge works — but it's a deliberate trade-off, not a clean solution. You're syncing files between paths, intercepting requests at init, and hoping nothing breaks when AIOSEO updates.

There's a cleaner approach that would eliminate the problem entirely: serve llms.txt dynamically via WordPress rewrite rules, with no physical file involved.

WordPress already does exactly this for robots.txt. Before WordPress 5.3, you needed a physical robots.txt file in the document root. Since 5.3, if no physical file exists, WordPress generates the response dynamically through a rewrite rule — no file on disk, no filesystem dependency, works everywhere including read-only environments and isolated containers.

The same pattern applied to llms.txt would look like this:

GET /llms.txt
      │
      ▼
  WordPress rewrite rule intercepts
      │
      ▼
  Check transient cache
      │
      ├── Cache hit → serve immediately
      │
      └── Cache miss → generate content → store in transient → serve

Benefits over the file-based approach:

No Docker filesystem isolation problem (nothing writes to disk)
No permission issues on managed hosting
Works on read-only filesystems
Cache invalidation is explicit and controllable
Generation happens on first request, not on plugin save

For SEO plugin authors, this means replacing file_put_contents(ABSPATH . 'llms.txt', ...) with a rewrite endpoint and transient cache. The content generation logic stays identical — only the delivery mechanism changes.

For WordPress core, there's a reasonable case for adding llms.txt infrastructure the same way robots.txt was added in 5.3: a default dynamic endpoint with filters that plugins can hook into. Given how quickly LLM indexing is becoming relevant for content sites, this seems like a natural next step.

Until either happens — the PHP bridge above does the job.

Key Takeaways

Isolated Docker containers create real filesystem problems for file-based WordPress features
The PHP bridge pattern (Nginx → PHP fallback) is a clean solution that doesn't require infrastructure changes
MU-plugins are ideal for this: no activation needed, always loaded
Nginx caches the response for 30 days after first request, so performance is fine
Generated files with domain URLs should never be in git

If you're running a similar multi-container WordPress setup, this pattern applies to any file that WordPress generates dynamically — not just llms.txt.

Running a similar setup? Let me know how you handled it — or if you've seen SEO plugins already moving toward dynamic generation.

Update: WordPress Core Proposal

After publishing this article, I submitted a feature request to WordPress Core Trac proposing native llms.txt and llms-full.txt support — using the same virtual file architecture that already powers robots.txt.

Trac Ticket: #64959 — Add native llms.txt and llms-full.txt support

The patch adds rewrite rules, conditional tags (is_llmstxt(), is_llmstxt_full()), transient-based caching, and a full set of filters for plugin extensibility. If accepted, this would eliminate the need for the Nginx workaround described in this article — WordPress would serve llms.txt through PHP, just like it does with robots.txt.

DEV Community: Serhii Pylypenko