What Google added to Lighthouse, and why ecommerce teams should care
Google has added an llms.txt check to Chrome Lighthouse, bringing machine-readable site structure into a standard technical audit. The file now sits alongside crawlability, indexability, and structured data in the technical work teams already do.
For ecommerce teams, that matters because it changes the status of machine-readable access. Google is signalling that the way a site presents itself to automated systems belongs in the quality conversation, alongside the basics that keep pages discoverable in search. If a store has tidy titles but a chaotic information structure, the audit now has another way to expose the gap.
This does not mean llms.txt sends traffic by itself. A file does not create demand, fix weak category pages, or make a product range easier to compare. What it does is make weak information architecture harder to hide, which is often the more useful outcome anyway.
Ecommerce SEO now has to serve two audiences at once. Shoppers still need clear categories, obvious filters, and pages that answer buying doubts. Machines also need a site they can summarise, compare, and retrieve product information from without guessing what matters.
If you want the wider strategic picture, the adjacent posts on AI search visibility and answer-layer content cover the bigger shift in discovery. This article stays on the technical audit angle, because that is where the new Lighthouse check changes day-to-day work.
Why llms.txt is a forcing function, not a traffic tactic
llms.txt is useful because it forces teams to decide what matters on the site in plain language in a place machines can read. The hard part is agreeing on what belongs there, and that conversation exposes problems quickly.
Used on its own, it is weak. There is no credible reason to expect a file by itself to change rankings, drive referrals, or earn AI citations if the site underneath is disorganised. A neat note at the door does nothing for a shop with boxes piled across the aisle.
The work it pushes teams towards is unglamorous and valuable. Category hierarchy gets cleaner, and product grouping becomes clearer.
Orphan pages get found and either linked properly or removed. Internal linking starts serving the way the catalogue is actually sold, rather than how it happened to grow.
That job differs from old SEO habits. The goal is still discoverability, but the audience now includes systems that summarise content, compare options, and pull out useful details before a shopper ever lands on the site. If a machine cannot tell which pages define the range, it will miss the store’s purpose.
Take a shop with hundreds of near-duplicate product pages for the same trainer, each with a slightly different colourway, size availability, and thin copy. A file will not tidy that up. The site needs structure first, then the file can point to the pages that matter.
Where llms.txt belongs on an ecommerce site
The practical placement is straightforward, the file belongs at the site root so automated systems can find it quickly. Put it anywhere else and you have turned a visibility file into a scavenger hunt. That defeats the point before the audit even begins.
The operational questions are the ones store owners actually need answered. Who owns the file? Who reviews it when the catalogue changes?
Those decisions should be settled once and then applied consistently when merchandising, SEO, and content teams push for different priorities.
The file should reflect the site’s most useful entry points. For most stores, that means the homepage, core category pages, key buying guides, and policy pages that shape trust.
A returns page matters when people are comparing stores. A shipping page matters when basket abandonment is being driven by surprise costs. Machines need the same cues shoppers do.
Do not bury it in a subfolder or treat it like a hidden technical asset. If a system has to work to find it, the file has already failed its job. The point is speed and clarity, not secrecy.
Multi-language and multi-region stores need a clear rule as well. Some teams will maintain separate files for each market, while others will centralise the structure and mirror it across versions. Pick one approach and document it, because a patchwork setup creates different signals for different versions of the same shop.
What to include, and what to leave out
The file should read like a shop floor map rather than an inventory dump. Include the pages that help a machine understand what the store sells and how people buy, then leave the rest alone.
Start with category pages, top-selling product families, buying guides, size guides, shipping and returns pages, and the other pages that answer common pre-purchase questions. Those are the pages with durable value, because they still matter when a product line changes, a promotion ends, or a range gets refreshed.
If a page keeps helping shoppers choose, compare, or trust the store six months from now, it deserves a place. If it only exists because someone made it for a campaign, it probably does not.
Leave out thin tag pages, filtered faceted URLs, duplicate variants, expired seasonal pages, internal search pages, and anything else that creates noise for machines. A summary system does not need twenty near-identical pages for red trainers in size 7, size 8, and size 9. It needs the main trainers collection, the relevant product family, and support pages that explain fit, delivery, or returns.
Make the hierarchy obvious. Put primary pages at the top, supporting pages underneath them, and use context pages only when they genuinely help explain the site. This distinction matters because a machine summarising your store needs to know what is central and what is background.
Use a blunt rule here because blunt rules save time. If a page would confuse a shopper when shown in a summary, it probably should not be in the file.
How llms.txt fits with schema, internal links, and indexability
Treat llms.txt as one layer in a wider machine-access stack. It works alongside schema, internal linking, canonical tags, robots rules, and clean indexable URLs. Remove any one of those elements and the setup becomes less stable.
Each part has a job. Schema tells systems what a page is, internal links show what matters, indexability decides what can be crawled, and the file gives a curated map. A search engine or AI system that sees all four gets a much cleaner picture than one that is guessing from scattered signals.
Ecommerce examples make this plain. Product schema helps a product page read as a product page, breadcrumb schema shows where a category sits in the hierarchy, and internal links from category pages point towards the products and guides that deserve attention. A size guide linked from the running shoes collection carries more weight than a lonely footer link tucked away on page 43 of the site.
None of these fixes a weak site on its own. Schema without links is decoration. Links without indexable URLs leave important content stranded. A tidy file with no crawlable pages behind it is a neat list of dead ends.
Indexability comes first. If a page is blocked, canonicalised away, or buried behind poor navigation, a file will not rescue it. Machines cannot use content they cannot reach.
That is why the warning in Lighthouse matters. It asks whether your store has a clear machine-readable structure or depends on human patience and guesswork. Stores that do this work make fewer bad assumptions later.
The technical audit questions Lighthouse now forces you to answer
The check is useful because it turns a vague best practice into a set of direct questions. Can a machine find the file. Can it understand the main sections of the store.
It can reach the pages that matter without friction. If any part of the process is messy, the site needs work.
Ecommerce sites usually stumble here. Faceted navigation can explode URL counts, weak category copy leaves a collection page looking like a holding pen, duplicate product descriptions blur the difference between similar items, and orphaned content sits on the site with no meaningful route in. These problems are common, and they are not harmless.
Audit the site from the machine’s point of view. Start at the homepage, follow the main category paths, then check whether the structure still makes sense without any brand memory or shopper context. If you need to explain why a page matters, the architecture is already doing too little.
For a lean team, this is the fast way to find information architecture problems hiding behind the phrase “we have plenty of content”. Plenty of content means very little if the important pages are hard to reach, repeated in several versions, or diluted by low-value pages that keep getting in the way. The site may look busy and still be difficult to read.
That is the real value of the Lighthouse check. It makes machine readability concrete so you can inspect and fix issues. Once you review the site this way, weak spots are easier to identify.
A shopper can usually sense the same thing, even if they never see the plumbing. The store feels organised, or it feels cluttered.
What llms.txt cannot do for ecommerce SEO
The Lighthouse check for llms.txt is a warning light. It tells you a machine can find a file and read its structure, but it does nothing to create authority, repair weak copy, or make poor merchandising useful to AI systems.
That distinction matters because a lot of teams treat any new machine-readable file as a shortcut. It is not. If your category pages are thin, your product descriptions repeat manufacturer text, and your trust pages are vague, the file simply points to a messy site with clearer labels on the boxes.
It also will not fix the problems that already slow search performance. Indexing issues stay indexing issues. Crawl waste from faceted filters stays crawl waste. Duplicate variants, weak category structure, and missing product details do not improve because a file exists in the root directory.
That expectation gap is what teams need to close. llms.txt signals organisation and shows that a team knows what matters and where it lives. It does not drive traffic on its own, and it does not earn summaries from machine systems by itself.
The same applies to answer content. If a shopper wants to know whether a jacket runs small, how a mattress feels for side sleeping, or whether a blender handles frozen fruit, the page has to answer that plainly. Machines summarise what they can read, and they struggle when the copy gives them nothing but brand language and a size chart buried below the fold.
Take a store with messy filters, duplicate collection pages, and thin descriptions on every SKU. A perfect file will not make that store look tidy. It will still look like a site built for internal convenience first and shoppers second, and machine systems expose that structure quickly.
That is why the Lighthouse check should be read as a warning. It shows whether the store is legible and does not fix broken parts.
A practical AI search readiness stack for small ecommerce teams
When time is tight, order the work in the right sequence. Start with indexability, then schema, then internal links, then llms.txt, then content cleanup. That order matters because a machine cannot use a page that search engines cannot reliably crawl, and it cannot trust structure that is absent or broken.
Build the stack around the pages that pay the bills. Category pages, best sellers, comparison content, and trust pages should sit at the centre because those pages shape discovery and conversion. A tidy file that points to low-value pages is busywork.
Here is the lean-team version of the operating model:
- One person owns the file and keeps it current.
- SEO sets the page priorities and checks indexability.
- Content owns the wording, headings, and answer sections.
- Merchandising makes sure the linked pages match what is actually being sold.
That split keeps the work moving without turning it into a committee project. One person can maintain the file, but the structure behind it needs input from more than one seat. If SEO writes the map alone, it will miss commercial reality. If merchandising handles it alone, it will miss search behaviour.
Review the file and the pages it points to every quarter. Product ranges shift, seasonal collections come and go, and site architecture changes when teams launch new categories or retire old ones. A stale file sends the wrong signal fast, especially on stores with broad catalogues and frequent range changes.
That cadence also keeps the work tied to revenue pages, which is where it belongs. A comparison page for running shoes, a returns policy that answers size and exchange questions, and a category page for black ankle boots all need to stay aligned with the current range. If those pages drift, machine-readable structure starts pointing at yesterday’s business.
The larger point behind the Lighthouse warning is that machine-readable structure is becoming basic ecommerce hygiene, the same way clean URLs, clear canonicals, and sensible category logic already are. The check makes the gap visible.
Frequently asked questions
Does llms.txt improve rankings?
llms.txt does not improve rankings by itself. Search engines still rank pages using crawlability, content quality, internal links, schema, and page experience signals. Treat llms.txt as a machine-readable guide for large language models, not as an SEO shortcut.
Should every ecommerce site add llms.txt?
No, every ecommerce site does not need llms.txt right away. It makes the most sense for stores with a large catalogue, messy site structure, or pages that are hard for machines to interpret quickly. A small store with a clean architecture and strong structured data may get little practical value from it.
What pages belong in llms.txt for an online store?
Put pages in llms.txt that help a machine understand the store and answer shopping queries accurately. Include the homepage, key category pages, top product pages, shipping and returns pages, size guides, and contact or brand pages. Leave out thin filters, duplicate variants, and low-value pages that add noise.
Is llms.txt a replacement for schema markup?
llms.txt is not a replacement for schema markup. Schema gives search engines structured facts they can use in search results, while llms.txt is a separate guide for language models. An ecommerce store still needs proper Product, Breadcrumb, Organisation, and FAQ markup where it fits.
Can llms.txt fix faceted navigation problems?
llms.txt cannot fix faceted navigation problems. If filters create crawl traps, duplicate URLs, or index bloat, those issues need to be handled with canonical tags, noindex rules, parameter control, and sensible internal linking. llms.txt can point machines toward the right pages, but it cannot clean up the underlying site structure.
Where should llms.txt live on the site?
llms.txt should live at the site root, usually at /llms.txt. That makes it easy for machines to find without crawling the whole site first. Keep it plain text, keep the file stable, and make sure it reflects the pages you actually want machines to use.
Written by Richard Newton, Co-founder & CMO, Sprite AI.
Sprite builds brand authority through continuous, automated improvement. Quietly. Consistently. And at Scale.
See What You Could Save
Discover your potential savings in time, cost, and effort with Sprite's automated SEO content platform.