LSI Keywords: A Term Google Says Does Not Exist

There is no such thing as an LSI keyword. Google has said so in those words, has never documented anything of the kind, and the lists these tools produce are ordinary related-terms exports with a 1990s label on them. The underlying advice, cover your topic properly, is sound. The mechanism offered for it is invented.

What Google said, and when

John Mueller of Google answered the question on Twitter on 30 July 2019, in a post reported by Search Engine Roundtable the following morning. The wording left no room for interpretation:

There's no such thing as LSI keywords -- anyone who's telling you otherwise is mistaken, sorry.

That is not a hedge of the sort Google usually offers about ranking systems. It is a denial that the category exists. It has not been walked back, and nothing in Google's published documentation since has introduced the term.

This fits a pattern worth recognising, because it is how most SEO folklore ends. Google's SEO Starter Guide carries a section headed "Things we believe you shouldn't focus on", which states that Google "doesn't use the keywords meta tag" and that "the length of the content alone doesn't matter for ranking purposes". The helpful content guidance puts it more bluntly, asking whether you are writing to a word count "because you've heard or read that Google has a preferred word count", and answering its own question: "(No, we don't.)"

LSI keywords belong on that list. The tell is the same every time: a specific-sounding mechanism, no documentation behind it, and a tool sold against it.

What a related-terms list actually contains

The practical instruction attached to LSI keywords is always the same. Link-Assistant's SEO wiki page LSI keywords - definition, explanation + SEO tips tells you to "Sprinkle these related terms throughout your text in a natural and meaningful way", and that "Once you have a list, incorporate these keywords naturally into your content". Generate a list of terms related to your keyword, then work them into the copy. So it is worth looking at what one of those lists contains.

This is not the output of an LSI tool. It is Ahrefs' related terms report for "schema markup", pulled for the United States on 3 November 2026, These are the first twenty rows the report returned in its own order, not the twenty largest, and we have sorted them by search volume for the table. The report merges two views: queries the pages in the top ten also rank for, and phrases those pages also use. Both halves are in the twenty below. We used it because the instruction names no tool. It says generate a list of terms related to your keyword, and this is what a reputable one hands back. An LSI tool would return a different twenty rows; the question is what any such list asks a writer to do.

Related term	US searches a month
schema	41,000
schema code	1,900
rich result test	700
markup website	700
structured data in seo	500
rich snippet test	200
why schema markup is important	200
schema review markup	150
types of structured data markup	100
schema.org structured data	100
schema code in seo	100
validate schema	100
schema markup test	100
google structured data generator	60
content schema	30
help search	20
mark up your aggregate rating semrush	10
schema org tester	10
understand content	0
json rich snippets	0

Now try to follow the instruction. Seven of the twenty rows draw under a hundred US searches a month. Those seven are not seven separate problems: two of them register no measurable demand at all, two are sentence fragments rather than queries, "understand content" and "help search", and one names a rival tool's product. Both fragments come from the half of the report that lists phrases the top ten pages use, rather than queries those pages rank for. At the other end, the single biggest entry, "schema" at 41,000, comes from that same half and is a broader term than schema markup rather than a variation on it.

A writer told to sprinkle these through a page about schema markup would produce something worse than what they started with. The entries worth covering, validating your markup, testing for rich results, choosing a format, are things you would have covered anyway by knowing the subject. This twenty adds nothing except the fragments, and the fragments are noise.

Why the name survives the denial

Latent semantic indexing is a real technique from information retrieval. That is exactly why the term has outlived its debunking: it sounds like a thing because it is a thing, just not one Google has ever connected to how it ranks your page. Borrowing a genuine technical term is what separates durable folklore from the obvious kind.

The second reason is commercial. "Write about your topic thoroughly" cannot be sold. A generated list of twenty terms can be, and it arrives with the comforting property of being checkable: you can tick items off, and the page turns green. Advice that produces a checklist will always outcompete advice that produces a judgement call, regardless of which one is true.

The strongest objection: covering a topic properly does matter

Here is the case against this article, and it is a real one.

Pages that rank well for a term do tend to contain the vocabulary of that term's subject. Google does understand language well beyond exact string matching, and has for years. A page about schema markup that never mentions JSON-LD, rich results or validation is a worse page, and it will probably perform worse. So if "add LSI keywords" is bad advice with a fake mechanism, is it not at least pointing at something true?

It is. The objection stands, and only the mechanism fails. But the mechanism is not a harmless detail, because it changes what you do:

• Believing in LSI keywords makes vocabulary the goal. You add terms to a finished page, which is the definition of writing for the engine rather than the reader.
• Understanding why coverage matters makes the subject the goal. You find the parts of the topic you have not addressed, write them, and the vocabulary follows because you cannot explain validation without the word validation.
• The first produces keyword stuffing at the margin. Google's spam policies name that explicitly, which means a technique that does not exist can still get you into one that does.

Same destination, opposite method, and only one of them survives contact with a reader.

What to do instead

Replace the tool with a question: what does someone who typed this query still not know after reading my page?

1. Pull the People Also Ask block for your term and treat the on-topic questions as a coverage checklist. These are real questions from real searchers, not rows from a related terms export. Our measurement of what those blocks contain is in the People Also Ask study.
2. Read the pages currently ranking and list the sections they have that you do not. Then decide which of those gaps are real and which are padding, because plenty of it is padding.
3. Use a related-terms export the way it is actually useful: to find separate queries that deserve their own pages, not strings to sprinkle into this one. Content gap analysis is the method for that.
4. Check your own coverage against the subject, not against a list. If you cannot explain a part of the topic, that is the gap. If you can and chose not to, that was an editorial decision and it is allowed.

The thing being sold as LSI is semantic coverage, and semantic coverage is earned by understanding the subject rather than by decorating a page with its vocabulary. Entity SEO and topical authority are where that leads once you stop looking for a word list.