La mayoría de developers indie de iOS tratan el keyword field como un campo extra. Pegan los términos que se les ocurren, llegan a los 100 caracteres y siguen adelante. Algunos lo dejan medio vacío. Algunos copian ahí su subtítulo, palabra por palabra.

Esta es la palanca más desaprovechada en la distribución de apps de iOS.

El keyword field no es algo complementario a tu título y subtítulo. Para la mayoría de las apps pequeñas, es la parte de tu metadata que más se prueba, más se cambia y da la señal más clara sobre si tus keywords elegidos están funcionando. Si no lo tratas así, estás corriendo tu estrategia de ASO con una mano atada.

Qué hace realmente el keyword field

Apple le da a cada app un campo oculto de 100 caracteres por locale en App Store Connect. Los usuarios nunca lo ven. La búsqueda de App Store sí lo lee.

Cada token de ese campo queda indexado. Si escribes cardio,strength,hiit,yoga, Apple va a considerar tu app para cualquier búsqueda que contenga esas palabras. Si un usuario busca “hiit workout” y tu subtítulo dice algo sobre entrenamiento por intervalos pero tu keyword field tiene hiit, tienes dos señales independientes diciéndole a Apple que esta app es relevante.

El campo se formatea como keywords separados por comas, sin espacios alrededor de las comas. Cada locale tiene su propio presupuesto de 100 caracteres. Cinco locales activos significan 500 caracteres de espacio de keywords oculto, completamente separado de tus títulos y subtítulos.

Lee la guía completa de formato y reglas para el keyword field.

Por qué los developers lo desaprovechan

Hay tres patrones que le quitan valor al keyword field.

Duplicar el título y el subtítulo. Si tu título es “FitTracker: Workout Log” y tu subtítulo es “Gym and Cardio Planner”, escribir fittracker,workout,gym,cardio,planner en el keyword field son 44 caracteres desperdiciados. Apple ya indexa cada palabra de tu título y subtítulo. El keyword field es para palabras que no están en ningún otro lado de tu metadata.

Dejarlo medio vacío. Un keyword field de 60 caracteres en una app con título de 30 caracteres y subtítulo de 30 caracteres significa que estás usando 120 de los 160 caracteres posibles por locale. Eso es 25 por ciento de tu presupuesto de keywords sin usar, antes de contar locales adicionales.

No pensar en cross-locale. Apple indexa los keywords de tu app globalmente. Un usuario alemán que busca “gym” va a encontrar tu app si gym está en tu keyword field en inglés, incluso si tu metadata en alemán no contiene esa palabra. La mayoría de los equipos traducen su keyword field palabra por palabra, lo que duplica coverage que ya tienen en vez de extender el pool de keywords.

Los números detrás del desperdicio

Mirando las apps trackeadas en Marteso, aparece un patrón consistente. Las apps que rankean en el top 50 para sus términos principales tienden a usar 90 o más caracteres de su keyword field. Las apps que les cuesta llegar al top 100 en cualquier término suelen tener keyword fields de menos de 60 caracteres o llenos de palabras que repiten su título.

Esto no es casualidad. Las apps con keyword fields pobres no le dan a Apple suficiente diversidad de señal para posicionarlas en algo que no sean sus uno o dos términos obvios.

Una app de fitness que solo apunta a “workout tracker” compite contra todas las demás apps de fitness que apuntan al mismo término obvio. Una app que además cubre calisthenics,hiit,strength,plan,routine,abs,trainer le da a Apple diez señales adicionales sobre a qué usuarios podría servir. Incluso si solo uno de esos términos rankea en el top 30, suma impresiones que “workout tracker” solo no puede dar.

El keyword field como entorno de pruebas

Acá está el reframe que cambia cómo lo usas.

El keyword field es el lugar más seguro de tu metadata para experimentar. A diferencia del título y el subtítulo, que afectan cómo los usuarios perciben tu app en la página de resultados de búsqueda, el keyword field es invisible. Cambiarlo no cambia cómo se ve tu app. Solo cambia para qué búsquedas te considera Apple.

Esto lo convierte en el lugar correcto para testear hipótesis de volumen. Agregas un keyword, esperas de 10 a 14 días, revisas si aparecen rankings, y después decides si promoverlo a tu subtítulo o título, donde sería visible y tendría más peso.

El workflow se ve así:

  1. Encuentra un keyword con popularidad moderada (50 a 80) y dificultad baja en relación a su popularidad.
  2. Agrégalo al keyword field en tu próximo release.
  3. Revisa tus rankings de keywords después de dos ciclos completos de review de App Store (10 a 14 días).
  4. Si el término aparece en el top 50, tiene potencial de ranking. Si rankea en el top 20, vale la pena probarlo en el subtítulo.
  5. Si no aparece ningún ranking después de 14 días, reemplázalo por otro candidato.

El keyword field es un tablero de hipótesis rotativo. La mayoría de los developers lo tratan como un string estático que configuran una vez y olvidan. Tratarlo como una capa de testing activa cambia el resultado.

Errores comunes que anulan keywords válidos

Espacios alrededor de las comas. Escribir keyword1, keyword2 en vez de keyword1,keyword2 te cuesta un carácter por keyword de un presupuesto de 100 caracteres. Con diez keywords, son 10 caracteres perdidos.

La palabra “app”. Nadie escribe “fitness app” esperando encontrar una app de iOS. Escriben “fitness” y ya están dentro del App Store. La palabra “app” no te da nada y te cuesta cuatro caracteres más una coma.

Singular y plural de la misma palabra. Apple stemea la mayoría de los plurales. workout normalmente cubre workouts. Listar ambos gasta dos slots en un keyword efectivo.

Tu nombre de developer o de marca. Apple indexa tu nombre de developer por separado. No es necesario en el keyword field.

Si sacas esos patrones de tu campo actual, típicamente liberas entre 20 y 30 caracteres para términos completamente nuevos, sin cambiar una sola decisión de contenido.

Un campo que vale dos horas al mes

Optimizar bien el keyword field de 100 caracteres toma unas dos horas: auditar el estado actual, quitar caracteres desperdiciados, investigar candidatos de reemplazo y actualizar. Esas dos horas se multiplican en cada locale que tengas activo.

No es glamoroso. No cambia nada que un usuario vea alguna vez. Pero es la palanca que la mayoría de los developers indie no ha usado, y en la que no estás compitiendo contra la ventaja de tres años de una app establecida. Estás compitiendo contra developers que no llegaron a leer hasta acá.

Lectura relacionada