LSI Keywords Aren’t Magic — The Prompt Workflow That Makes Them Useful

Let’s get the awkward bit out of the way. Latent Semantic Indexing, the 1980s information-retrieval method, is not how Google ranks your blog in 2026. SEOs kept the nickname anyway, the same way we still say “go viral” for a Reel that got 8,000 views. When peopel say LSI keywords now, they mean related terms, entities, and the vocabulary that proves a page is actually about the topic.

I still use the phrase with clients becuase it is the handle they already hold. Then I quietly do something more useful: I build a semantic list from SERPs, Peopel Also Ask, and a few strict prompts, and I weave those words in like a human who knows the subject — not like a person hiding spinach in a smoothie.

This is the prompt engineer’s version of that job. Not “generate 50 synonyms.” A workflow you can rerun when the SERP shifts, wich it will, expecially once AI Overviews start quoting a different angle than last quarter.

What you’re actually collecting (please stop stuffing synonyms)

A usefull related-term list is not 40 ways to say the same noun. If the page is about NPWP registration for freelancers in Indonesia, you do not need “tax id,” “tax ID,” “tax identification,” “nomor pokok,” all in one paragraph. You need the concepts a real explainer would mention: e-fin, DJP Online, NPWP 16 digit, status PKP, kode akun pajak, what happens if you only have NIK, the difference for badan vs orang pribadi.

Those are entities and neighbouring topics. Search systems — Google’s, and the anwser engines that cite you — use that neighbourhood to decide if you covered the subject or just repeated a head term. Thin AI articles fail here in a very specfic way: they loop the primary phrase and never touch the messy local nouns.

So the job of your prompts is to pull three buckets:

1. Must-mention entities — brands, laws, tools, places, prodcut types.
2. Intent phrases — how people actualy ask, including Bahasa campur English.
3. Boundary terms — related but not this article, so you can internally link instead of muddying the page.

If a prompt cannot seperate those buckets, it is a synonym machine and you should close the tab.

Do not start in the chat. Start in the SERP.

I paste real materials into the model. Titles of the current top 8, the H2s if I can scrape them, PAA questons, a few autocomplete ideas, maybe a Reddit thread title. Withotu that, the model invents a Unted States version of your topic. Ask for “coffee shop POS” and you will recieve Square and toast tabs. Ask with Indonesian SERP titles and you get QRIS, Olsera, Moka, “kasir online untuk warung.”

That last set is the difference betwen ranking in ID and writing a tourist brochure.

Minimum context pack: primary query, location/langauge, 8 competitor titles, 6 PAA questons, 3 things your page must not become (e.g. “not a plugin roundup,” “not a legal opinion”).

Yes, this is slower than “give me LSI keywords for X.” It also does not waste a writer’s afternoon weaving in junk like “best” and “guide” as if those were semantic gold.

The prompt stack I actually reuse

I dont use one mega-prompt. Mega-prompts get half-followed. Four small ones, same thread or same system message.

Prompt 1 — extract, don’t create

You are a semantic researcher, not a copywriter.
Primary query: {q}
Market: Indonesia, mix of Bahasa Indonesia and English queries.
Here are competitor titles and H2s:
{paste}

Return three lists only:
A) Entities (proper nouns, products, regulations, institutions)
B) Phrases users would type or speak (keep original language)
C) Off-topic neighbours we should link out to, not rank with

No synonyms of the primary query unless they appear in the source text.
Mark each item with [seen in SERP] or [inferred]. Inferred items need a one-line why.

The [seen] vs [inferred] tag is how you keep the model honest. Inferred is allowed — “e-Fin” might not be in a title but belongs. Inferred without a why gets deleted.

Prompt 2 — map to search intent, not density

Using list B, group phrases by intent:
- learn (what / how / syarat)
- compare (vs, alternatif, harga)
- do (daftar, beli, download, cek)
For each group, say whether our URL should rank for it or whether it needs a seperate page.
If Bahasa and English mean the same job, merge them. Do not double the brief.

This is where you stop writing one giant article that tries to rank for “apa itu,” “harga,” and “download template” at once. Indonesian SERPs love splitting those.

Prompt 3 — turn terms into placement, not a shopping list

You will not write the article. You will write a placement map.
For each must-mention entity:
- natural section it belongs in (H2/H3 idea)
- whether it should appear in intro, FAQs, or a table
- a warning if forcing it into the intro would sound stuffed

Also list 5 terms that look fancy but would make the tone worse. Drop them.

I love that last line. Models adore “leverage,” “robust,” and “comprehensive ecosystem.” Drop them. Your reader is a person on the TransJakarta Wi-Fi trying to finish a task.

Prompt 4 — the anti-hallucination check

Here is the draft. Here is the allowed term list.
Highlight any claim that uses an entity we did not source.
Highlight any paragraph that repeats the primary query more than once.
Suggest cuts, not additions, if the draft already covers the intent.

Most “SEO prompts” only add. Adding is how you get 3,000 words of oatmeal. The useful prompt engineer asks for cuts.

A worked example: “mesin kasir untuk UMKM”

Say you run a SaaS from Jakarta selling a simple cashier app. Head term is competitive, mix of “aplikasi kasir” and brand names. You do not need twenty LSI keywords like “cashier machine application software.” You need a map like this:

• Entities: QRIS, GoPay, OVO, DJP (pajak), stok barang, struk thermal, offline mode (listrik / wifi mati — very local pain), multi-cabang.
• Intent phrases: aplikasi kasir gratis vs berbayar, mesin kasir Android, kasir untuk warung makan, laporan penjualan harian, integrasi Shopee.
• Boundaries: full accounting (Jurnal/Accurate) belongs on another URL. Hardware cash drawers mayb an affiliate page, not the main explainer.

A weak model draft will say “point of sale solution for small bussiness owners seeking operational excellence” three times. A good placement map says: first H2 is warung makan and antrian, not “digital transformation.” Mention QRIS in the payments section with a boring sentence about settlment, not a hymn. Put “offline mode” in a short story about wifi dropping during lunch rush in a ruko. That story does more for topical depth than a bullet list of synonyms.

When I brief writers, I dont give them the raw list and say “include these.” I give them the placement map. Inclusion-by-checklist is how you get a paragraph that names Olsera, Moka, Majoo, and five others withotu a point. That’s not semantics. That’s a roll call.

How many terms is “enough”?

Fewer than your tool’s export. Clearscope-style coverage scores can be helpful as a recap, terrible as a religion. If the SERP is a 1,200-word answer, you do not need 80 terms. You need the 12 the winners share and the 3 they all missed (often the local constraint: COD, PPN, pengiriman ke luar Jawa).

A personal rule: if I cannot explain why a term earns its place in one spoken sentance, it doesnt go in. “We mention PPN becuase cashiers in Indonesia get asked whether harga already includes tax.” Good. “We mention ‘retail management’ becuase the tool said so.” Not good.

For AI citations — Perplexity, Google’s overviews, the chat boxes peopel use insted of ten blue links — unique entities plus a clear definition sentence beat a high density of the head term. Anwser engines like to quote compct, source-looking lines. Write one clean definition, then go deep on the messy local stuff those overviews still skip. That is how you get the click after the summary.

Bahasa, English, and the fake-bilingual article

Indonesian sites love mixing languages. Sometimes that is how people search. Sometimes it is the writer showing off. Your prompt should say wich langauge the H1 lives in, and that related terms in the other langauge belong in FAQs or a glossary, not stuffed into every H2.

Exmaple: page in Bahasa about “gaji UMR Jakarta 2026.” Related English like “minimum wage” might apear in PAA. One mention is orientation. Five mentions is a page that ranks for nothing becuase it looks translated by a committee. I ask the model to label each term id or en and cap the minority language at a percentage of headings, not body word count. Headings are the smell test. If half your H2s flipped langauge, you dont have a semantic strategy. You have indecision.

Common prompt failures (aka why your “LSI list” is trash)

Asking for a round number. “Give me 25 LSI keywords” guarantees padding. Ask for “as many as the SERP supports, no padding.”

No negative examples. If you dont say “we are not a visa agency,” a prompt about “kerja di Singapura” will drift into work-permit fanfiction.

Letting the model invent statistics. Related terms are not facts. “UMR Jakarta 2026 is Rp X” needs a source. Put a rule: numbers only from the pasted sources. I have seen drafts confidently quote last year’s UMP as this year’s. Awkwrd.

Optimising the list instead of the outline. Semantics live in sections. If your outline is Intro / Benefits / Conclusion, no term list will save you. Force H2s to match the jobs in Prompt 2.

Using the same stack for YMYL and for a cafe menu. Medical, legal, tax — entities must be sourced. A prompt that is playful on a skincare blog should be boring and citation-first on a “cara klaim BPJS” piece. Tone is part of semantic trust, not a seperate beauty pass.

A tiny quality bar before you brief the writer

I run this on my own drafts and it stings, which means it works:

• Read the H2s out loud. Do they sound like questions a person asked, or like keyword fridge magnets?
• Circle the first 100 words. If the primary query apears twice already, cut one.
• Find one paragraph that would only be written by someone who has done the thing (waited at KPP, argued with a thermal printer, etc.). If none exists, the semantic list never made it into lived detail.
• Check internal links against bucket C. Neighbour topics should leave the page, not camp in a fake H2.

That third bullet is the whole “experience” part of E-E-A-T that peopel try to fake with adjectives. A related-term workflow does not replace experiance. It makes space for it so the draft is not alredy full of synonyms.

What to do tomorrow morning

Pick one URL that ranks 5–15 for a query you care about. Build the context pack from the live SERP, not from memory. Run the four prompts. Compare the placement map to your currnt H2s. You will usualy find two missing entities and one H2 that exists only to repeat the title.

Rewrite that page with the map on the desk, not the synonym list. Then save the prompt stack in your team doc with one worked exmaple from your own niche — a Javanese wedding vendor, a Bali villa site, a fintech help center, whatever you actually ship. Generic prompt libraries produce generic neighbourhoods.

And if a tool still wants to call them LSI keywords, fine. Smile, import the list, and immediately sort it into entities, intents, and not-this-page. The nickname can stay. The stuffing does not have to.

I also keep a living glossary per site, not per article. For a hospital group that would include poli names, BPJS terms, and the way reception actually anwsers the phone. For a coffee roaster in Bandung it is process words (washed, natural, honey) plus café service words (takeaway, QRIS, wifi). The glossary feeds Prompt 1 so the model stops inventing US chains. Update it when a term shows up in Search Console three times. That is how semantic work becomes an asset instead of a one-off chat. That’s the whole craft, honestly. Teach the model to collect a neighbourhood. Teach yourself to write like you live there.