El schema speakable marca con JSON-LD las secciones de una página aptas para ser leídas en voz alta por asistentes. La respuesta corta para 2026: sigue siendo una especificación en beta, orientada sobre todo a medios de noticias, con soporte estrecho fuera de ese caso. Para la mayoría de negocios peruanos no es prioridad; hay alternativas con mejor retorno. Aquí está el estado real del soporte, nuestro test y el veredicto por tipo de sitio.
Tabla de Contenidos
- 1 ¿Qué es el schema speakable y para qué se creó?
- 2 El estado real del soporte en 2026
- 3 Por qué quedó a medio camino: la historia corta
- 4 ¿Qué encontramos al probarlo?
- 5 Veredicto honesto: ¿quién debería implementarlo?
- 6 Las alternativas que sí mueven la aguja hoy
- 7 Si igual quieres implementarlo: lo mínimo viable
- 8 Cómo decidir ante cualquier schema experimental
- 9 Preguntas frecuentes
¿Qué es el schema speakable y para qué se creó?
La propiedad speakable nació para la era de los parlantes inteligentes: permitía señalar, con selectores CSS o XPath, qué dos o tres bloques de una página funcionan bien leídos en voz alta, para que un asistente respondiera consultas habladas con ese fragmento citando a la fuente. La promesa era atractiva: ser la respuesta de voz en lugar de un resultado más.
El contexto cambió desde entonces: los asistentes de voz clásicos cedieron protagonismo a los asistentes con modelos de lenguaje, que generan respuestas desde el contenido completo en lugar de leer fragmentos marcados. Por eso este análisis es parte de nuestra guía de GEO para aparecer en ChatGPT, Gemini, Claude y Perplexity: la pregunta correcta no es si el schema existe, sino si todavía compra visibilidad. Evaluar ese tipo de apuestas es parte de lo que hacemos en el servicio de posicionamiento GEO.
El estado real del soporte en 2026
Tres hechos verificables definen el panorama. Primero: la propiedad sigue documentada como beta en la documentación de Google, años después de su lanzamiento, lo que ya dice bastante sobre su prioridad interna. Segundo: su caso de uso documentado se concentra en contenido de noticias, con disponibilidad históricamente limitada por idioma y región; revisa la documentación vigente de Google para el detalle actual antes de invertir. Tercero: ninguno de los asistentes conversacionales principales documenta que use speakable para elegir qué responder.
A eso se suma el dato de adopción que cualquiera puede comprobar: revisa el código fuente de los principales medios y negocios de tu rubro y cuenta cuántos lo implementan. La escasez no prueba inutilidad, pero cuando una especificación lleva tantos años sin masificarse ni salir de beta, la carga de la prueba está del lado de implementarla.
Por qué quedó a medio camino: la historia corta
El speakable se presentó en 2018, en plena ola de parlantes inteligentes, cuando parecía que la voz sería la próxima interfaz dominante y los asistentes necesitarían saber qué leer en voz alta. La especificación se lanzó acotada a noticias en inglés con promesa de expansión, y esa expansión nunca terminó de llegar: ni a más tipos de contenido de forma documentada, ni fuera del estado beta.
Mientras tanto, la interfaz de voz evolucionó hacia otro lado: de comandos cortos respondidos con fragmentos, a conversaciones con modelos que sintetizan respuestas desde fuentes completas. El problema que speakable resolvía se volvió menos relevante antes de que la solución madurara. Es un patrón que se repite en especificaciones web: la lección no es nunca adoptar temprano, sino adoptar temprano solo lo que ya tiene consumidores reales del otro lado.
¿Qué encontramos al probarlo?
Nuestro test siguió el protocolo de siempre: páginas con y sin speakable, mismas consultas en asistentes de voz y conversacionales, registro de qué fuente responde y si el marcado mostró algún efecto observable en mención o cita. [DATO-KOM: resultados del test propio de speakable con la matriz de registro]
Lo que sí podemos afirmar del proceso, independiente del resultado puntual: el costo de la prueba es bajo (el marcado toma minutos por página) y la medición es el mismo protocolo de auditoría de visibilidad que ya usamos. Si quieres replicarla en tu sitio, marca tus tres páginas más consultadas por voz, espera unas semanas y compara con tu línea base. Sin línea base previa, cualquier conclusión es humo.
Veredicto honesto: ¿quién debería implementarlo?
| Tipo de sitio | ¿Implementarlo? | Por qué |
|---|---|---|
| Medio de noticias | Sí, vale la prueba | Es el caso de uso documentado y el costo es marginal |
| Blog corporativo con contenido de actualidad | Solo si sobra capacidad técnica | Posible beneficio futuro, evidencia actual débil |
| Web de servicios o tienda | No como prioridad | No es su caso de uso; mejor retorno en otras tareas |
| Negocio local | No | La visibilidad por voz local pasa por perfiles y reseñas, no por speakable |
En KOM no lo recomendamos como tarea estándar, y eso también es un entregable: decirte dónde no gastar. La excepción razonable es el medio editorial con equipo técnico propio, donde el costo marginal de probar es casi cero.
Las alternativas que sí mueven la aguja hoy
Si lo que buscas es ser la respuesta hablada o citada, las palancas con evidencia son otras. El primer párrafo que responde la consulta completa en 60 a 80 palabras: los asistentes conversacionales toman exactamente ese tipo de fragmento. Los bloques de pregunta y respuesta visibles con su FAQPage. La autocontención por secciones, para que cualquier fragmento recuperado se entienda solo. Y el schema Article bien armado con autoría y entidad, que define quién responde.
Todas comparten una propiedad que speakable no tiene: funcionan para texto y voz a la vez, porque optimizan el contenido en sí y no una etiqueta lateral. Lo que un asistente puede leer en voz alta con claridad es, casi por definición, lo que también cita bien por escrito.
Si igual quieres implementarlo: lo mínimo viable
El marcado es corto. Dentro de tu nodo Article o WebPage agregas la propiedad con selectores hacia tus bloques aptos para voz:
"speakable": {
"@type": "SpeakableSpecification",
"cssSelector": [".resumen-hablable", ".respuesta-corta"]
}Dos reglas de oro: marca solo bloques breves y autocontenidos, de dos a tres oraciones que suenen naturales leídas en voz alta, y nunca marques titulares con juegos de palabras ni párrafos con referencias visuales del tipo como muestra la tabla. La prueba de fuego es leer el bloque por teléfono a alguien: si se entiende sin la página delante, sirve.
Cómo decidir ante cualquier schema experimental
Este caso deja un criterio reutilizable para el próximo marcado de moda. Hazte cuatro preguntas en orden. Uno: ¿hay un caso de uso documentado por la plataforma que lo consume, y mi sitio encaja en él? Dos: ¿algún sistema que me importe declara usarlo hoy, o todo es potencial? Tres: ¿cuánto cuesta probarlo de verdad, con implementación, mantenimiento y medición incluidos? Cuatro: ¿tengo línea base para detectar el efecto, o voy a decidir por sensaciones?
Con dos respuestas negativas, archívalo con fecha de revisión a seis meses y vuelve a lo que rinde. El SEO técnico serio no consiste en implementar todo lo que existe, sino en ordenar las apuestas por evidencia y costo. Esa disciplina es la diferencia entre una web optimizada y una colección de experimentos sin medir.
Preguntas frecuentes
¿El schema speakable funciona en español?
La disponibilidad por idioma y región ha sido históricamente limitada y cambia con el tiempo, así que la respuesta responsable es: revisa la documentación vigente de Google antes de asumir cobertura en español. Lo que no cambia es la matemática de la decisión: si el soporte en tu idioma es incierto, el retorno esperado baja y las alternativas ganan.
¿ChatGPT, Claude o Perplexity usan speakable para responder?
No hay documentación de ninguno de los principales asistentes conversacionales que indique uso de speakable como señal. Estos sistemas procesan el contenido completo de la página y arman su propia respuesta. Por eso la escritura autocontenida y el answer-first rinden donde speakable no: alimentan directamente el mecanismo real de esos asistentes.
¿Tener speakable puede perjudicar mi sitio?
Daño directo, no: es marcado válido y unos bytes más de JSON-LD no afectan nada. El riesgo es indirecto: horas de implementación y mantenimiento gastadas en una etiqueta de retorno incierto mientras tareas con evidencia esperan turno. En sitios con marcado desordenado, además, suma un nodo más que mantener sincronizado.
¿Qué secciones debería marcar si decido probarlo?
Tu primer párrafo answer-first, si responde la consulta completa en pocas oraciones, y las respuestas de tu bloque de preguntas frecuentes que sean breves y autónomas. Evita marcar más de dos o tres bloques por página: la especificación está pensada para fragmentos selectos, no para señalar el artículo entero.
Tu siguiente paso: antes de tocar speakable, confirma que tus diez páginas principales tienen párrafo de respuesta directa y FAQ visible con su marcado. Esa base rinde con o sin voz. Si después te sobra capacidad técnica y tu contenido es editorial, corre la prueba con línea base y decide con tus propios datos. Y guarda el criterio de las cuatro preguntas: lo vas a necesitar con el próximo marcado de moda que te quieran vender como urgente, porque siempre hay uno nuevo en camino, y la respuesta correcta casi nunca es la que más ruido hace en redes.
