Amazon backend keywords: the 500-byte rule (2026)

Short answer: Amazon backend keywords live in the Generic Keywords field — in Seller Central you reach it by editing the listing and opening the keywords section. It is the only place where search terms are stored without a shopper ever reading them. And it carries a trap: the limit is 500 bytes, not 500 characters — a German umlaut or an ß costs two of them — and exceeding it risks the entire field being ignored, not just the overflow.

This guide takes the byte rule apart, sorts what belongs in the field from what must stay out, and shows where the terms worth entering actually come from. Current as of August 2026.

The 500-byte rule, precisely

Bytes and characters are the same thing as long as you stay in plain ASCII: a to z, digits, spaces. Add anything else and that stops being true. In UTF-8 — the encoding your text arrives in — ä, ö, ü, ß and every accented letter take two bytes instead of one. So a field written in German, Spanish or French fills up earlier than your editor's character counter suggests.

The arithmetic is uncomfortably concrete. A string made purely of umlauts would hit 500 bytes at 250 characters — half of what the counter implies. Realistic German keyword text sits somewhere in between, but a string your editor reports as 249 characters can already be pressed hard against the ceiling. The character count simply does not tell you where the limit is.

So count bytes, not characters: run the string through a UTF-8 byte counter before you paste it in, and leave yourself a buffer. Do not rely on the interface to warn you in time.

This matters more than it sounds. Go over the limit and the whole field can be ignored — it is not the last term that drops, it is potentially every term. One word too many neutralizes all the backend work you did. Nothing in the listing shows the fault; you notice it only because the terms never take hold.

If you sell only on English-language marketplaces this looks like a non-issue, and mostly it is. It becomes an issue the moment you localize — the same term set that fits comfortably in English will not fit in German or Spanish.

What belongs in the field

The job of the field is narrow: it carries the search terms that have no room in the visible copy, or that would read badly there.

• Synonyms and alternative names for the same product — any word a shopper might type that would sound clumsy in a title.
• The language of your reviews: what buyers actually call the product and the problem it solves, usually not what your marketing calls it.
• Use cases and situations: what the product gets bought for, not only what it is.
• Audience words: who it is for — beginners, left-handers, frequent travellers, workshop rather than household.
• Regional variants where one listing serves several regions of the same language: the same object is not called the same thing everywhere.
• Terms your visible copy deliberately leaves out because they would dilute it. Here they cost bytes, not readability.

What must not go in

Amazon's rules for the field are short, and a large share of common practice either breaks them or simply wastes room.

• Competitor brand names. That is a guideline breach, and depending on the brand a legal exposure on top.
• Words already used in the title, the bullets or the description. They are captured either way; in the backend they only cost bytes.
• Singular and plural side by side. Amazon normalizes both forms, so the second one is wasted.
• Upper- and lower-case variants of the same term. Also normalized — write everything in lower case.
• Commas as separators. Spaces are enough, and every comma is a byte that can no longer be part of a keyword.
• Misleading or irrelevant terms — other product categories, attributes your product does not have. That breaks the rules and buys clicks that do not convert.

Where the terms come from

The richest source is reviews — your own and those of your three strongest competitors. That is where customers describe their problem in their own words, and those are the words they search with. Note the recurring phrasings, not the one-offs.

The second source is a diff against your own visible copy. Put the title, bullets and description next to your term list and delete everything already present. What is left is exactly what the field exists for — which is why you fill it last, not first.

The third source is how people search now. A growing share of shoppers phrase a question rather than a keyword, with a situation, a constraint and a purpose in it. That vocabulary belongs in your listing. Where it works hardest — in the visible copy or in the backend field — is not publicly documented, so the defensible order is: spell the use case and the audience out in the title, bullets and description first, and use the backend field for the variants that will not fit there.

A short checklist

• Finish the visible copy first, then fill the field. Before that you do not know which terms are already covered.
• Lower case throughout, separated by spaces, each form once.
• Count bytes rather than characters before pasting, and keep a buffer.
• One term set per marketplace. A literal translation of the English field is not one.
• No competitor brands, no repeats from the visible copy, no misleading terms.
• Revisit the field after every title or bullet change: what moved to the front can come out of the back.

When a tool earns its place

For a single listing this is manual work, and manual is fine here: read the reviews, gather terms, diff against the visible copy, count the bytes, paste.

The arithmetic breaks with catalogue size. Every marketplace has its own field, every title edit makes part of the stored terms redundant, and nobody maintains three hundred backend fields on the side. Torch Listings derives the backend terms from the same evidence as the visible copy — reviews, competitor listings and demand data — instead of inventing them.

What no tool decides for you: which terms genuinely describe your product. A full field of near-misses is more expensive than a half-full one that is right.