Troubleshooting

Generation produces empty or partial output

Symptom: The Generate button completes but llms.txt is empty, or most entries are missing.

Checking the generation log: Open LLMs.txt → Settings and expand the Last Generation Log section at the bottom - it auto-expands when errors are present. Each entry that failed or produced a warning is listed with a reason.

Likely causes to check:

  • The content type you expect is not toggled on in Settings → Content to Include.
  • All pages in that type are in the excluded pages list.
  • Max Items per Content Type is set to a low number (e.g. 1).
  • The page has no published content (draft, private, or password-protected posts are skipped).
  • Pages marked noindex or nofollow in your SEO plugin are excluded by design.

Full-page scrape falls back to published content

What this means: By default the generator reads your published content (blocks, shortcodes, and page-builder output run through WordPress’s content filters). If you set Extraction Method to Full-page scrape under Settings → Content Extraction, the generator instead loads each page over an internal HTTP request. When that request fails, it falls back to reading your published content.

Blocks and shortcodes still come through on the fallback, because they expand through the same content filters. What the fallback can miss is anything that only exists in the rendered page and not in post_content - for example ACF values printed by your theme, or a section your theme or a hook-based builder (such as Elementor) injects outside the editor. To capture ACF and custom fields reliably, use Pro field mapping rather than the scrape.

Common causes of scrape failure:

  • The site is behind HTTP authentication, a staging login wall, or a maintenance-mode plugin.
  • The server blocks loopback requests (requests from the server to itself).
  • The site URL in Settings → General does not match the actual URL the server resolves (e.g. HTTP vs HTTPS mismatch).

How to confirm: Look for scrape-failure warnings in the Generation Log noting a fall back to published content.

Fix: If you rely on Full-page scrape, ensure yoursite.com is publicly reachable during generation, or whitelist the server’s own IP in any access-control layer. If you don’t need the scrape, leave Extraction Method on Auto, which reads published content directly. On a permanently private staging environment, consider the WP-CLI command on a publicly accessible clone:

wp llmstxt generate

File permission error - cannot write llms.txt

Symptom: Generation completes but no file appears at /llms.txt, or an error in the log says the file could not be written.

Cause: The plugin writes static files to the WordPress root directory. That directory must be writable by the web server user (typically www-data or nobody).

Check: Go to LLMs.txt → Settings → Advanced Settings. The File Delivery Mode panel shows a green Writable or red Not writable indicator for the root directory.

Fixes:

  1. Fix permissions - set the root directory to writable by the web server user: chmod 755 /path/to/wordpress (or ask your host).
  2. Switch to Live Endpoint mode - this serves files via WordPress rewrite rules without writing anything to disk. Go to Settings → Advanced → File Delivery Mode and select Live Endpoint.

Output is stale after publishing new content

Symptom: You published a new post but it doesn’t appear in llms.txt.

Free plan: Output is only updated when you manually click Generate or Regenerate on the Generate tab. There is no automatic update on free.

Pro plan Pro: Enable Auto-Regeneration under Settings → Auto-Regeneration. Once on, the plugin regenerates automatically whenever a post, page, or product is published or updated. A 5-minute debounce prevents rapid saves from stacking multiple jobs.

WP-CLI: Trigger a fresh generation from the command line at any time - useful in deploy scripts or cron jobs:

wp llmstxt generate

Bulk imports (WP All Import, etc.): Imports often bypass normal publish hooks, so auto-regeneration may not run. Hook pmxi_after_xml_import and fire do_action( 'llmstxt_regenerate' ) when the import finishes. See After any import completes → for a copy-paste example.

Individual .md file not found at /llms/slug

Symptom: You expect a file at e.g. /llms/blog/my-post but get a 404.

Causes and fixes:

  1. Pro required - Individual .md files require a Pro license. The toggle is visible on free plans but does nothing without Pro. Upgrade →

  2. Toggle not enabled - Go to Settings → Individual .md Files and ensure the toggle is on.

  3. No regeneration after enabling - Enabling the toggle does not immediately write files. Run a full regeneration from the Generate tab.

  4. File Delivery Mode mismatch - If the global or per-type mode is set to Physical file but the root directory is not writable (see above), no files are written. Either fix permissions or switch to Live Endpoint mode.

Running on Nginx

Everything works on Nginx. One detail worth knowing: individual .md files Pro are stored in wp-content/llmstxt-md/ and served through WordPress at /llms/slug.md.

On Apache, an .htaccess file blocks direct access to the storage folder. Nginx ignores .htaccess, so the stored files are also reachable at their direct wp-content path. The content there is the same public content served at /llms/*.md, so nothing private is exposed - but if you want the storage path blocked too, add a small location rule to your Nginx config:

location ^~ /wp-content/llmstxt-md/ { deny all; }

Where to get help

Check the Generation Log first - it’s the fastest way to diagnose most issues. If you’re still stuck, you have two ways to reach us:

  • Contact us directly if you’d rather reach the developer one-on-one. We read every message and usually reply within one business day.
  • Open a support thread on WordPress.org with your log output included. This one is public, so other users hitting the same issue can find the fix too.