{"id":5262,"date":"2024-10-11T06:24:10","date_gmt":"2024-10-11T06:24:10","guid":{"rendered":"https:\/\/zonhack.com\/?p=5262"},"modified":"2026-08-31T12:11:59","modified_gmt":"2026-08-31T12:11:59","slug":"amazon-backend-keywords","status":"publish","type":"post","link":"https:\/\/zonhack.com\/zh\/amazon-backend-keywords\/","title":{"rendered":"Amazon Backend Keywords: The 250-Byte Field, Used Properly"},"content":{"rendered":"

Amazon backend keywords<\/strong> live in the generic keyword attribute, a hidden field capped at 250 bytes<\/strong>,
\nand that word matters: bytes, not characters.<\/strong> An accented letter can cost two bytes. A non-Latin
\ncharacter can cost three. Sellers who count characters routinely lose space they never knew they had.<\/p>\n

The second thing almost every guide gets wrong: do not repeat words that already appear in your title or
\nbullets.<\/strong> Amazon indexes the whole listing. A word present in the title is already indexed, so putting it
\nin the backend field again spends bytes on nothing.<\/p>\n

Those two rules recover most of the field for most sellers. Below: what belongs in it, what is prohibited,
\nhow to check whether a term actually indexed, and an honest account of how much this matters.<\/p>\n

What the field is, and what it is not<\/h2>\n

Five points, and the third is the one that reframes the work.<\/p>\n

It is one attribute, not five.<\/strong> Some interfaces present multiple search term lines, and the limit applies
\nto the field as a whole. Treat the budget as a single 250 bytes, and I’d write the term list somewhere else first.<\/p>\n

Bytes are the unit.<\/strong> Standard letters, numbers, and spaces are one byte each. Accented characters,
\nArabic, Japanese, and emoji cost more. If you sell in a non-English marketplace this is not a technicality,
\nit is a third of your field.<\/strong><\/p>\n

Amazon deduplicates across the listing.<\/strong> Title, bullets, description, and backend are indexed together.
\nRepetition adds nothing. I’d audit for it before adding a single new term.<\/p>\n

No punctuation, and no commas.<\/strong> Single spaces between terms. Commas consume bytes and do no work.<\/p>\n

Word order does not matter.<\/strong> Amazon matches combinations, so “stainless steel bottle” and “bottle steel
\nstainless” behave alike. You do not need to write phrases, only the words, and in our experience that realization frees up considerable space.<\/p>\n

The byte problem in non-English marketplaces<\/h2>\n

Worth its own section, because this is where the character-versus-byte distinction stops being pedantic and
\nstarts costing you a third of the field.<\/p>\n

Latin letters, digits, and spaces cost 1 byte each.<\/strong> So an English-only field genuinely holds around 250
\ncharacters, which is why so many guides get away with conflating the two units.<\/p>\n

Accented Latin characters typically cost 2 bytes.<\/strong> French, Spanish, German, Polish. A field that looks
\nlike 250 characters in the editor can be over budget before you finish.<\/p>\n

Arabic and most non-Latin scripts cost 2 bytes.<\/strong> Japanese, Chinese, and Korean characters commonly cost
\n3. In practice a Japanese field holds closer to 80 characters than 250,<\/strong> and I’d plan the term list
\naround that from the start rather than trimming afterwards.<\/p>\n

Truncation is silent.<\/strong> Amazon does not warn you that the last third of your terms was discarded. In our
\nexperience this is the single most common invisible failure in international listings, because the seller
\nsees the text they pasted and assumes it saved.<\/p>\n

What I’d do about it.<\/strong> Count bytes before pasting, prioritize the highest-value terms first so anything
\nlost is the least important, and verify indexing on the terms that matter using the ASIN-plus-keyword
\nsearch. Three steps, and the third one is the only proof.<\/p>\n

What belongs in it<\/h2>\n

The field exists for what will not fit naturally in customer-facing copy.<\/p>\n

Synonyms and alternate names.<\/strong> “Pram” alongside “stroller”. “Torch” alongside “flashlight”. The words a
\ndifferent customer would use for the same object, and I’d ask somebody outside your category what they would call it.<\/p>\n

Common misspellings, sparingly.<\/strong> Amazon handles many automatically, so I’d include only the ones that
\nare genuinely frequent rather than every typo you can imagine.<\/p>\n

Regional and spelling variants.<\/strong> British and American spellings where both are searched, for a
\nmarketplace where both occur.<\/p>\n

Use cases and occasions.<\/strong> “Camping”, “gift”, “dorm”, “travel”. The context somebody searches from, which
\nis frequently absent from a specification-driven listing.<\/p>\n

Material and attribute words<\/strong> that could not fit in the title. I’d take these from the specification sheet rather than from memory.<\/p>\n

Related-item words<\/strong> where genuinely relevant. Not competitor products.<\/p>\n

In our experience the highest-value additions are use-case words, because sellers write titles about what a
\nthing is and shoppers search for what they need it for.<\/p>\n

What is prohibited, and what is simply wasteful<\/h2>\n

Two different lists, and people merge them.<\/p>\n

Prohibited, and it can cost you the listing:<\/strong><\/p>\n