Keywords de backend en Amazon: la regla de los 500 bytes (2026)

Respuesta corta: las keywords de backend van en el campo Generic Keywords — en Seller Central lo encuentras al editar el listing, en la sección de palabras clave. Es el único sitio donde se guardan términos de búsqueda sin que ningún comprador los lea. Y tiene una trampa: el límite es de 500 bytes, no de 500 caracteres — una vocal con tilde, una ñ o una diéresis alemana consumen dos — y pasarse arriesga que se ignore el campo entero, no solo lo que sobra.

Esta guía desmonta la regla de los bytes, separa lo que va en el campo de lo que no debe entrar y muestra de dónde salen los términos que sirven. Datos a agosto de 2026.

La regla de los 500 bytes, con precisión

Bytes y caracteres coinciden mientras te quedes en ASCII puro: de la a a la z, cifras y espacios. En UTF-8 — la codificación en la que llega tu texto — á, é, í, ó, ú, ñ, ü y ß ocupan dos bytes en lugar de uno, así que un campo en español o en alemán se llena antes de lo que marca el contador de caracteres de tu editor.

La cuenta es incómodamente concreta. Una cadena formada solo por vocales acentuadas llegaría a 500 bytes con 250 caracteres, la mitad de lo que sugiere el contador. Un texto real queda entre medias, pero una cadena que tu editor cuenta como 249 caracteres ya puede estar pegada al límite. El número de caracteres no te dice dónde está el techo.

Cuenta bytes, no caracteres: pasa la cadena por un contador de bytes UTF-8 antes de pegarla y deja un margen. No confíes en que la interfaz te avise a tiempo.

Y el detalle pesa: al superar el límite se puede ignorar el campo completo. No cae el último término, caen potencialmente todos. Una palabra de más anula todo el trabajo de backend, y el fallo no se ve en el listing — solo notas que los términos no funcionan.

Qué va en el campo

La función del campo es estrecha: recoge los términos de búsqueda que no caben en el texto visible o que ahí se leerían mal.

• Sinónimos y nombres alternativos del mismo producto: cualquier palabra que un comprador pueda teclear pero que quede torpe en el título.
• El lenguaje de las reseñas: cómo llaman los compradores a tu producto y a su problema, normalmente distinto de tu marketing.
• Casos de uso y situaciones: para qué se compra, no solo qué es.
• Palabras de público: para quién es — principiantes, zurdos, viajeros frecuentes, taller en lugar de hogar.
• Variantes regionales, si un mismo listing atiende a varios países del mismo idioma: el mismo objeto no se llama igual en todas partes.
• Términos que tu texto visible evita a propósito porque lo diluirían. Aquí cuestan bytes, no legibilidad.

Qué no debe entrar

• Marcas de la competencia. Incumple las directrices y, según la marca, añade un riesgo legal.
• Palabras que ya están en el título, los bullets o la descripción. Se registran igualmente; en el backend solo gastan bytes.
• Singular y plural juntos. Amazon normaliza ambas formas, así que la segunda se pierde.
• Variantes de mayúsculas y minúsculas del mismo término. También se normalizan: escribe todo en minúscula.
• Comas como separador. Bastan los espacios, y cada coma es un byte que ya no puede ser keyword.
• Términos engañosos o irrelevantes — otras categorías, atributos que tu producto no tiene. Incumple las normas y atrae clics que no compran.

De dónde salen los términos

La fuente más rica son las reseñas, las tuyas y las de tus tres competidores más fuertes: ahí los clientes describen su problema con sus palabras, y con esas palabras buscan. Apunta las formulaciones que se repiten, no los casos aislados.

La segunda fuente es comparar con tu propio texto visible. Pon el título, los bullets y la descripción junto a la lista de términos y borra todo lo que ya aparezca. Lo que queda es justo aquello para lo que existe el campo — por eso se rellena al final, no al principio.

La tercera es cómo se busca ahora: cada vez más compradores formulan una pregunta en lugar de una palabra clave, con situación, restricción y propósito dentro. Dónde rinde más ese vocabulario — en el texto visible o en el backend — no está documentado públicamente, así que el orden defendible es escribir el caso de uso y el público en título, bullets y descripción, y reservar el backend para las variantes que allí no caben.

Checklist breve

• Termina primero el texto visible; antes no sabes qué términos ya están cubiertos.
• Todo en minúscula, separado por espacios, cada forma una sola vez.
• Cuenta bytes antes de pegar, con margen.
• Un juego de términos por marketplace. Una traducción literal no lo es.
• Sin marcas ajenas, sin repetir el texto visible, sin términos engañosos.
• Revisa el campo tras cada cambio de título o de bullets.

Cuándo compensa una herramienta

Para un listing suelto esto es trabajo manual y está bien que lo sea: leer reseñas, reunir términos, comparar con el texto visible, contar bytes y pegar.

La cuenta se rompe con el tamaño del catálogo: cada marketplace tiene su propio campo, cada cambio de título deja obsoleta una parte de los términos guardados y nadie mantiene trescientos campos de backend de pasada. Torch Listings genera los términos de backend a partir de la misma evidencia que el texto visible — reseñas, listings de la competencia y datos de demanda — en lugar de inventarlos.

Lo que ninguna herramienta decide por ti: qué términos describen de verdad tu producto. Un campo lleno de aproximaciones sale más caro que uno a medias pero correcto.