JumpsuitAI – llms.txt + Markdown Endpoints

प्रश्नोत्तर

Where is the llms.txt file?

After activation, visit /llms.txt on your site. The canonical URL does not use a trailing slash. On a supported single-site installation with direct filesystem access, JumpsuitAI synchronizes the completed artifact to llms.txt in the website home root. If that is not available, the existing WordPress endpoint continues to serve the private completed artifact.

What happens if a root llms.txt file already exists?

JumpsuitAI does not overwrite or delete a file it cannot prove it created. The Settings screen reports the conflict. Remove or rename the other file, or disable the other llms.txt generator, and then use Retry public /llms.txt now to retry only the root publication.

Why is the physical root file not active?

The website root may not allow unattended direct writes, a conflicting file may already exist, the server may use an unusual filesystem layout, or the site may use WordPress multisite. The virtual endpoint remains available whenever WordPress handles the request. The Settings screen distinguishes root-detection, permissions, existing-file, symbolic-link, temporary-write, activation, and verification failures. Expand Technical details to see the selected path, how it was detected, the WordPress filesystem method, the server response, and every root candidate that was checked.

Why can an older error appear even though /llms.txt exists?

A previous background worker may have stored an error before a later attempt successfully activated the file. Version 1.1.7 associates status, errors, and ownership records with the exact publication attempt and runtime, so an obsolete result is shown only as previous history. Use Retry public /llms.txt now for an immediate current result.

Is the physical file removed when the plugin is deactivated or deleted?

Yes, when the last active JumpsuitAI Free or Pro build stops managing the shared artifacts. The plugin removes only an llms.txt file whose path and exact hash prove that JumpsuitAI created it, and removes only its marked robots.txt block. A byte-identical file left by an earlier 1.1.7 test build can be recovered once from the completed private artifact so it can be cleaned up safely. A file changed by another system is left untouched.

Does physical root publishing work on managed hosts with a symlinked WordPress core?

Version 1.1.7 resolves the logical directory represented by the site’s Home URL instead of treating the resolved WordPress-core path as the public root. It first maps WP_CONTENT_DIR and its public URL back to the Home URL, then considers the server document root and validated WordPress fallbacks. This supports layouts where WordPress core is symlinked but wp-content and public files live in the site’s own document root. A jsai_llmstxt_public_root_path filter is available for uncommon custom deployments; filtered paths still have to pass the plugin’s normal local-path and directory checks.

Does the robots.txt option change crawler permissions?

No. The opt-in setting adds only a comment containing the /llms.txt URL. It does not add or replace User-agent, Allow, Disallow, or sitemap directives. Existing robots.txt content is preserved.

Does the plugin create a physical robots.txt file?

No. If a physical robots.txt exists, JumpsuitAI can add or remove only its marked comment block. If no physical file exists, the plugin uses WordPress’s virtual robots.txt filter so SEO plugin output remains intact.

Is physical root publishing supported on multisite?

Not automatically in version 1.1.7. Multiple multisite sites can share one document root, so JumpsuitAI keeps the existing virtual endpoints rather than risk one site overwriting another site’s root file.

How are the generated resources kept current?

Relevant WordPress content and plugin-setting changes queue regeneration through WordPress cron. The previous complete artifacts remain available while normal updates are being built. Changes that make content nonpublic are withheld until safe replacement artifacts are ready.

Why don’t I see updates right away?

Check JumpsuitAI – llms.txt + Markdown Endpoints → Settings for the static file status. Use Retry public /llms.txt now for an immediate root-publication result without rebuilding content, or Regenerate all static artifacts when the private Markdown artifacts also need to be rebuilt. WordPress cron must be able to run queued full rebuilds. An external page cache or CDN may also need to revalidate or purge its stored response.

Which URLs get a Markdown endpoint?

The plugin supports requesting an eligible public URL with .md appended. Content must be published, password-free, selected by post type in Settings, and allowed for anonymous public output. Post types controlled by an active access-restriction system may be withheld from public exports.

Is /llms-full.txt enabled automatically?

Yes, it is enabled by default for new installations and installations that have never saved an explicit preference. An existing manual choice to disable it is preserved during the upgrade.

What if rendered content depends on an external system or custom data source?

The plugin automatically tracks normal WordPress content, reusable blocks, plugin visibility/grouping data, and relevant settings. Custom integrations can request regeneration with do_action( 'jsai_llmstxt_request_regeneration', $post_id, false );, or pass 0, true to request a full rebuild.