Someone on your team shipped the file everyone was posting about, waited three weeks, checked, and nothing had changed. Now there is a second list of tactics circulating and a reasonable amount of scepticism in the room about whether any of this is real.
That scepticism is the right instinct applied at the wrong moment. The problem is not that people tried something. The problem is that the tactic was adopted at a level of confidence its evidence did not support, so there was no way to interpret the result. This post is a sorting exercise: for each circulating tactic, what is actually documented, what is plausible but unproven, what is unsupported, and specifically what evidence would move it.
A note on where we sit: RankRift publishes vendor-neutral measurement guidance, so we have an interest in you measuring things. We have tried to be explicit below about which claims rest on provider documentation and which rest on nothing yet. Our conflicts are set out on the disclosure page.
Why quick fixes dominate the conversation
Three forces push the conversation toward files and one-off edits.
The first is that assistants are opaque. When you cannot observe a mechanism, a concrete artifact you can ship feels like progress in a way that "improve the accuracy of how you are described everywhere" does not.
The second is that the practitioner community is running an enormous, uncontrolled, unlogged experiment. Thousands of people change several things at once, then attribute whatever moves next to the most recent change. The reports that circulate are the positive ones. Nobody posts the null result.
The third is that the incentive to publish a tactic is much stronger than the incentive to publish the caveat. A short post claiming a new lever gets attention. A long post saying "we ran this and could not detect an effect at our sample size" does not.
None of that makes the tactics wrong. It means the confidence attached to them is unearned, and unearned confidence is what makes an unmeasured programme feel like a failure.
The matrix: effort versus strength of evidence
Two axes. Effort is your cost to implement and maintain. Evidence is the strength of the public basis for believing it does anything.
We use three evidence classifications throughout:
- Documented. A provider states in its own documentation that the system uses or honours this. You still need to check the date, because docs change.
- Plausible but unproven. There is a coherent mechanism, but no provider statement and no published measurement we would accept. Worth one bounded experiment, not a programme.
- Unsupported. No mechanism, no documentation, and reasoning that does not survive contact with how retrieval works. This is a claim about the current evidence, not a permanent verdict.
The useful rule: high effort plus weak evidence is the only quadrant that is always wrong. Low-effort speculative work is fine if you time-box it and log it. High-effort documented work is the actual job.
| Tactic | Effort | Evidence classification | Why it lands there |
|---|---|---|---|
| Crawler access and correct status codes | Low–medium | Documented | Providers publish crawler identities and access controls |
| Server-rendered, fetchable content | Medium–high | Documented | If a retriever cannot get the text, nothing downstream matters |
| Accurate, consistent entity description | Medium | Documented in principle, unproven in magnitude | Mechanism is clear; the size of the effect is not published |
| Presence in sources that answers actually cite | High | Plausible, partly observable | You can observe citation patterns; you cannot prove causation |
| Standard structured data | Low–medium | Mixed: documented uses exist, AI-answer effect unproven | Useful elsewhere; effect on assistant answers not established |
llms.txt | Low | Plausible but unproven | Voluntary proposal; adoption by any consumer of it must be checked, not assumed |
| Chunk-friendly section structure | Medium | Plausible, mechanism-backed | Follows from how extraction works; no provider confirmation of specifics |
| Publishing dated, original data | High | Plausible | Citable material is more useful to a system summarising a topic; unmeasured |
| Keyword-style repetition for models | Low | Unsupported | Imported from a different system's logic; no mechanism |
| Hidden text aimed at retrievers | Low | Unsupported and hazardous | Deceptive; covered defensively in our manipulation tactics piece |
| Paid inclusion in "AI-optimised" directories | Medium–high | Unsupported | Cost is certain; mechanism is not |
Documented: what providers actually say they use
This category is short, which is the point.
Crawler and fetcher access. Providers publish the identities of their crawlers and the controls site owners have over them. This is documented in the strict sense: a named party says what it does. It is also the one place where a mistake is unambiguously fatal, because a blocked or broken path removes you from the retrieved-document pool entirely. Verify what you are serving to those agents rather than what your config file says you serve. The AI readiness hub covers the checks.
Whether the content is there at all. If your text only exists after client-side execution, or behind an interstitial, or on a page returning a soft error, then everything else in this post is moot. This is not glamorous and it is regularly the actual finding.
What your pages say about you. Not documented as a ranking mechanism, but documented in the trivial and important sense that a system summarising your company can only use statements that exist. Entity clarity is the cheapest work in this category and the one most often skipped in favour of a file.
What would move something into this class: a dated, linkable provider statement describing the behaviour. That is the whole bar. It is not a high bar and very few circulating tactics clear it.
Plausible but unproven: worth an experiment, not a programme
llms.txt. A proposed file for giving language models a curated, machine-readable map of a site. The idea is coherent and the file is trivial to produce. What is not established is who consumes it and what they do with it, which is the only question that matters for your decision. Our position: shipping it is cheap enough to be defensible, believing in it is not, and maintaining an elaborate one is a cost with no known return. We go through what it proposes and what we can and cannot observe in what llms.txt actually does.
What would move it up: a provider documenting that a named system reads it, or a controlled test with enough samples to detect a difference between sites that have it and sites that do not. What would move it down: providers stating they do not use it, or a well-powered test finding nothing.
Chunk-friendly structure. Self-contained sections, defined terms, and stable tables follow logically from the fact that retrieval systems work with fragments rather than whole pages. There is a mechanism. There is no provider confirmation of any specific implementation, and claiming to know a particular chunking scheme is fabrication. Structuring content this way also makes it better for humans, which is why we do it and why the downside is close to zero.
Structured data. It has documented uses in other systems. Whether it changes assistant answers is a separate and unresolved question. A minimum viable set is a sensible hedge. A schema programme justified purely by AI visibility is spending against an unproven return.
Original, dated data and clear comparisons. A summarising system needs material to summarise, and specific, attributable, current material is more useful than generic material. Plausible, unmeasured, and expensive. Worth doing for reasons that survive even if the AI-visibility case does not.
How to run one of these properly: change one thing, on a defined set of pages, with a baseline captured before the change, a frozen prompt set, enough samples that ordinary run-to-run variance will not fool you, and a written prediction of what you expect to see. If you cannot say in advance what result would make you drop the tactic, you are not running an experiment.
Unsupported: what to stop doing
Marked unsupported as of this post's date. If the evidence changes, this section changes, and we will date the change.
Repetition of phrases for the benefit of models. This imports the logic of a keyword-matching system into one that does not work that way. The cost is readable prose, and degraded prose is worse source material for extraction.
Text hidden from readers but visible to fetchers, and instructions embedded in pages aimed at assistants. No credible mechanism, and it sits on the wrong side of a line we take seriously. We cover this class defensively only, in terms of what it is, how it is detected, and what it costs when it fails.
Paying for inclusion in directories that promise AI visibility. The invoice is real. The mechanism is asserted rather than shown. If a vendor cannot describe how inclusion is supposed to reach an answer, and cannot show a measurement you could reproduce, treat the offer as unproven and priced as if it were proven.
Volume publishing to occupy topic space. Thin pages produced at scale have a documented history of going badly in other retrieval systems and no demonstrated benefit here.
What would move any of these up: a provider statement, or an independent test with a published prompt set, model versions, sample size, run dates, and variance. We would publish that finding even where it contradicts this section.
Where that time is better spent
If you have a fixed number of hours this quarter, spend them roughly in this order.
- Confirm you are retrievable. Access, rendering, status codes. Fix anything broken before doing anything else.
- Fix how you are described. Name, category, attributes, relationships, on your properties first and then on the third-party sources that describe you.
- Establish a baseline you can defend. A frozen prompt set, several models, multiple runs, dates and versions recorded. Without this, every later change is unmeasurable and every claim you make internally is an opinion.
- Improve the pages a buyer would actually be shown. Structure them so a single extracted section still says something true and complete.
- Then, and only then, time-box the speculative items. One at a time, logged, with a stopping rule.
Most teams do step five first, skip steps one to three, and conclude the category is nonsense. The category is not nonsense. The measurement discipline is missing, and that is the fixable part. The what actually changes recommendations hub sequences the legitimate levers with honest uncertainty attached to each.
In Plain English
What this means: very little of what circulates as AI-visibility tactics is documented. Some of it is plausible and cheap enough to test. Some of it has no mechanism at all. The mistake is not trying things; it is trying them without a baseline and then drawing conclusions.
Who this helps: teams who shipped a quick fix, saw nothing, and are now deciding whether to invest further or write the whole area off.
When to use it: before your next planning cycle, as a filter on the tactic list someone will bring you.
What to do next: classify every proposed tactic as documented, plausible, or unsupported. Write down what evidence would change your classification. Do the documented work first. Time-box the rest.
Download the AI-readiness audit checklist from our resources library and work through the documented items in order.
Primary-source verification
Checked July 28, 2026. The operational and factual guidance above was reviewed against the primary references below. Provider features, prices, policies, interfaces, jurisdictions, and account-specific results can change; recheck the controlling first-party document and your own account or measured data before acting.
- Google Search: AI features and your website - How Google describes eligibility, preview controls, and appearance in its AI search features.
- Google: common crawlers and special-case user agents - Current Googlebot and Google-Extended identities and controls.
- OpenAI: overview of OpenAI crawlers - Current GPTBot, OAI-SearchBot, and ChatGPT-User descriptions and publisher controls.
- Anthropic: web-crawler controls - Current ClaudeBot, Claude-SearchBot, and Claude-User descriptions and controls.
- Perplexity: crawler and user-agent documentation - Current PerplexityBot and Perplexity-User descriptions and controls.
- Google Search: structured-data introduction - Supported structured-data behavior and validation guidance.