Sign In

llms.txt for HubSpot: when it helps and how to publish it responsibly

An llms.txt file is an optional, curated guide to a website's useful information. It can give a supporting agent a short introduction and links to relevant resources. It does not guarantee citations, change crawler permissions, or make a weak service page more persuasive.

For HubSpot owners, there is also a publishing constraint: uploading a text file into HubSpot Files does not place it at your domain's root. HubSpot explicitly says a root-level plain-text file such as llms.txt must be hosted externally.

Treat llms.txt as a small information-access experiment after your core pages are clear and reachable. Our HubSpot AEO guide explains those foundations.

Understand the proposal before adopting it

The proposal at llmstxt.org describes a Markdown file containing a site or project name, concise context, and organized links. Its August 2026 revision supports a file at the root or a subpath and recommends links to content suited to agent consumption, including clean Markdown versions.

This is a community proposal. Adoption by a documentation website does not establish that every search system reads the file or uses it to select sources.

Google's current guidance is explicit: Google Search does not use llms.txt for visibility or rankings, including its generative AI features. Creating the file is therefore not a Google eligibility requirement.

The useful question is narrower: does a system your audience actually uses consume this file, and can you make its linked information easier to navigate? If you cannot identify a use case, spend the time improving your main pages first.

Keep four website resources distinct

ResourceRole in your website work
Visible page contentExplains your business, services, evidence, and next steps to visitors
Structured dataExpresses relevant page facts in a defined machine-readable vocabulary
robots.txtCommunicates crawler access rules to agents that follow them
llms.txtOffers a curated context and navigation file under the community proposal

Use the appropriate resource for the problem. A missing service description belongs on the service page. A crawler-access decision belongs in the relevant access controls. A confusing organization identity needs consistent business information, with Organization schema where appropriate.

Publishing llms.txt cannot grant access to an authenticated page. It also cannot replace a functioning website navigation structure or an up-to-date sitemap.

Choose a small, defensible scope

For a service business, begin with the information a prospective customer needs to evaluate the offer:

  • What the business does and who it serves.
  • Its main services and relevant limitations.
  • Where it operates.
  • Where to find evidence, policies, and contact information.

Prefer the current authoritative pages. Do not copy every blog post into the index, add unpublished commercial terms, or describe capabilities that are absent from the public website.

Choose an owner who can review both the file and its destinations when services change. A compact file with accurate links is easier to maintain than a second version of your entire website.

If you provide Markdown copies of pages, generate them from the same approved content where practical. Independently maintained copies can drift. A service available only in one market should not become “available worldwide” in an abbreviated machine-readable version.

A fictional example

The following example is for a fictional business. The example.com destinations illustrate a proposed site structure; they are not live service resources.

Markdown example
# Cedar Bridge Consulting

> A consultancy helping UK B2B teams plan HubSpot website migrations.

This guide covers public service and evaluation information.
Project scope and availability are confirmed during discovery.

## Services

- [Website migration](https://example.com/services/migration.md): Scope and exclusions.
- [Content operations](https://example.com/services/content-operations.md): Delivery process.

## Business information

- [About](https://example.com/about.md): Company background and service area.
- [Contact](https://example.com/contact.md): How to discuss a project.

Before adapting that structure, make sure every destination exists and contains the promised information. Adding .md to an ordinary HubSpot page URL does not create a Markdown version. Those representations need their own supported publishing mechanism.

If you have only HTML pages, first assess whether maintaining additional representations is useful for your intended consumer. Never advertise nonexistent resources simply to resemble an example.

Plan the HubSpot route before uploading

HubSpot's Files tool assigns generated file URLs, including /hubfs/ or hosted-file paths. Its documentation says those uploads cannot be placed at the domain root. An uploaded file's presence therefore does not prove that https://yourdomain.com/llms.txt works.

There are two practical decisions:

If you require /llms.txt on the main domain: involve the administrator who controls the domain's delivery infrastructure. They need to confirm an approved external hosting and routing mechanism that can serve that exact request. Whether an existing edge or proxy setup can do this depends on the website's architecture. A DNS record by itself does not route a single URL path.

If you control only a documentation subpath or separate site: consider whether a scoped file can meet the use case. The proposal permits subpaths, but the intended consumer still needs to discover and support that scope. A file on a separate host is not automatically a root file for the main website.

Avoid treating a redirect to an uploaded file as identical to serving the resource directly. Test the redirect chain and final response with the actual consumer. Do not introduce new delivery infrastructure solely for an unmeasured visibility promise.

Verify the published response and maintain it

After publishing, request the final URL outside the CMS editor and check:

  1. The intended path returns the actual Markdown text, with an appropriate text content type.
  2. The response is accessible without login, cookies, or a browser-only challenge.
  3. The body is the file, rather than an HTML page wrapped around it.
  4. Every listed resource is reachable and matches its description.
  5. Facts agree with the current public website.
  6. The content owner has a review trigger for changed services, URLs, and policies.

A successful response proves delivery. An agent finding the correct service information through the file provides a more useful consumption test. Neither observation proves a citation or commercial impact.

Use AI bot tracking if your infrastructure exposes request records. Track any answer or referral changes separately using the AI visibility measurement guide. Record other website changes during the same period so a later result is not automatically attributed to llms.txt.

Sources