Optimización para búsqueda por voz: Schema para seguir siendo visible en 2026

"Oye Siri, ¿cómo optimizo mi base de datos?" es hoy una forma normal de empezar una búsqueda: altavoces inteligentes en la oficina, asistentes en el coche, auriculares conectados al móvil. El usuario hace una pregunta y escucha una respuesta, sin lista de enlaces que recorrer.

Para quien gestiona plataformas WordPress empresariales, el cambio es estructural. En lugar de competir solo por la primera página visual, el objetivo pasa a ser la respuesta breve que un asistente puede leer en voz alta. Ese objetivo tiene límites concretos, documentados por Google, Apple y Amazon, y esta guía separa lo que esas plataformas prometen por escrito de lo que es solo buena práctica editorial.

#Cómo los agentes de IA cambian la búsqueda por voz

Los primeros asistentes buscaban una palabra clave y leían el primer resultado. Hoy varios productos funcionan como agentes conversacionales apoyados en modelos de lenguaje:

• Síntesis contextual: el agente no lee párrafos enteros; analiza documentos y extrae la respuesta más concisa que puede verificar.
• Atribución de la fuente: en el único caso que Google documenta (Speakable para noticias), el asistente nombra la fuente al leer el fragmento y envía la URL completa del artículo al móvil del usuario. Fuera de ese caso, ninguna plataforma promete una mención hablada de tu marca.
• IA ambiental: los usuarios consultan mientras conducen, cocinan o hacen ejercicio. El contenido tiene que entenderse sin pantalla, solo por audio.
• Ecosistema de dispositivos: altavoces inteligentes (Amazon Echo, Apple HomePod, Google Nest), asistentes de coche y wearables. Cada uno es un punto de entrada para preguntas habladas.

#Por qué ya no se puede crear una acción propia para Google Assistant

Durante unos años, la forma de “estar” en Google Assistant era una Conversational Action: una aplicación de voz con intents, escenas y webhooks. Esa vía está cerrada. La documentación de Google para desarrolladores indica que las Conversational Actions quedaron obsoletas el 13 de junio de 2023. Cualquier artículo que aún recomiende crear una acción de voz para Assistant está desactualizado.

A un sitio WordPress le quedan tres caminos: ser una fuente que los sistemas de búsqueda puedan rastrear y citar, marcar fragmentos con Speakable donde Google lo admite, y publicar contenido en formatos que un asistente consume directamente, como el feed de flash briefing de Alexa descrito más abajo.

#Qué promete realmente Google con Speakable

La propiedad speakable es la pieza más citada en las guías de búsqueda por voz y también la peor descrita. La página oficial Speakable (Article, WebPage) structured data es breve y clara:

• Está en beta. Google advierte que los requisitos y las directrices pueden cambiar.
• Funciona en un solo mercado. Según la documentación, la propiedad funciona para usuarios de EE. UU. con dispositivos Google Home configurados en inglés, y para editores que publican contenido en inglés.
• Sirve para noticias. Google Assistant usa Speakable para responder consultas sobre noticias de actualidad en altavoces inteligentes y devuelve hasta tres artículos de distintas publicaciones.
• Atribuye y reenvía. Cuando Assistant lee una sección marcada, atribuye la fuente y envía la URL completa del artículo al móvil del usuario a través de la app de Google Assistant.

“Para una experiencia de audio óptima, recomendamos unos 20 a 30 segundos de contenido por sección de datos estructurados speakable, o aproximadamente dos o tres frases.”

Google Search Central, documentación de Speakable (traducción propia)

Las directrices técnicas añaden detalles que casi ningún tutorial menciona. No marques el lugar de redacción de la noticia, los pies de foto ni las atribuciones de fuente, porque suenan confusos en audio. Usa cssSelector o xPath, nunca los dos en la misma especificación. Y, como con todos los datos estructurados, Google no garantiza que la función aparezca.

La consecuencia práctica para un sitio en español: Speakable no produce hoy ningún resultado de voz documentado para páginas en español ni para usuarios en España o Latinoamérica. Marcar un resumen no perjudica, pero no es un interruptor de “SEO de voz” y nadie debería prometer a un cliente resultados de voz basándose en él. Lo que sí se traslada a otros mercados y asistentes es la disciplina editorial que pide Google: resúmenes cortos, frases autónomas, nada que necesite una imagen para entenderse.

#Cómo implementar schema speakable en WordPress

Google documenta speakable como datos estructurados para Article y WebPage. La propiedad apunta con selectores CSS (o XPath) a fragmentos candidatos a la lectura en voz alta. La definición de referencia está en schema.org/SpeakableSpecification.

#Ejemplo de JSON-LD con speakable

Envuelve tus resúmenes más concisos en la propiedad JSON-LD speakable:

{
  "@context": "https://schema.org",
  "@type": "WebPage",
  "name": "Guía de búsqueda por voz WordPress 2026",
  "speakable": {
    "@type": "SpeakableSpecification",
    "cssSelector": [
      "#introduccion",
      ".resumen-ejecutivo",
      ".respuesta-principal"
    ]
  }
}

#Cómo añadir Speakable desde functions.php sin plugin

Para no depender de un plugin pesado, añade speakable en la cabecera con el hook wp_head:

add_action('wp_head', 'wppoland_speakable_schema_es');

function wppoland_speakable_schema_es() {
    if (!is_singular('post')) {
        return;
    }

    $post_id = get_the_ID();

    $schema = [
        '@context'    => 'https://schema.org',
        '@type'       => 'Article',
        'headline'    => esc_html(get_the_title($post_id)),
        'url'         => esc_url(get_permalink($post_id)),
        'inLanguage'  => 'es',
        'speakable'   => [
            '@type'       => 'SpeakableSpecification',
            'cssSelector' => ['#introduccion', '.respuesta-voz'],
        ],
    ];

    echo '<script type="application/ld+json">' . wp_json_encode($schema, JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE) . '</script>' . "\n";
}

Comprueba que los selectores existen en el HTML renderizado (Gutenberg, patrones sincronizados o el tema) y escapa siempre la salida. La prueba de resultados enriquecidos de Google no incluye Speakable entre los tipos que reporta, así que valida la sintaxis en el Schema Markup Validator. Si un plugin SEO ya emite Article, añade speakable a ese nodo en lugar de duplicar Article en la misma página.

#Qué contenido marcar con Speakable

• Primer párrafo de cada sección principal, que debe contener la respuesta directa.
• Bloques de resumen de dos o tres frases, unos 20 a 30 segundos de lectura.
• Definiciones: “qué es X” seguido de una respuesta concisa.

#Errores comunes al implementar Speakable

1. Marcar demasiado contenido: Google pide centrarse en los puntos clave, no en el artículo entero.
2. Secciones demasiado largas: la recomendación oficial es de dos o tres frases por sección.
3. Marcar elementos que confunden en audio: pies de foto, lugar de redacción, atribuciones de fuente.
4. Mezclar cssSelector y xPath en la misma especificación.
5. Esperar resultados fuera de EE. UU. o del inglés, donde la función no está disponible.

#Cómo usar palabras clave de cola larga en la búsqueda por voz

Las consultas de voz son personas hablando: largas, desordenadas y llenas de contexto. Mientras que la búsqueda por texto usa “seguridad WordPress”, la búsqueda por voz pregunta “cuál es la mejor manera de proteger el acceso a mi WordPress”.

La diferencia decisiva es la intención. Tres patrones hablados merecen un tratamiento editorial distinto:

1. Procedimiento (“cómo…”, “qué pasos…”): un bloque corto y pasos numerados visibles.
2. Definición o comparación (“qué es…”, “qué diferencia hay entre…”): un párrafo factual de dos o tres frases, sin preámbulo.
3. Local u operativo (“cerca de mí”, “en Valencia”, “hoy”): depende de datos NAP coherentes y de schema de negocio local, no de un artículo largo.

#Cómo estructurar el contenido en torno a preguntas

Patrón de contenido optimizado para voz:

1. Usa un H2 o H3 para la pregunta exacta.
2. Responde directamente en las primeras 40 a 60 palabras.
3. Amplía con detalles, ejemplos y matices.

Ejemplo optimizado:

## Cómo proteger el acceso a WordPress

La forma más fiable de proteger el acceso a WordPress es combinar
contraseñas únicas, autenticación en dos pasos, actualizaciones al día
y un límite de intentos de inicio de sesión. Ninguna medida por sí sola
basta, por eso se aplican en capas.

[Contenido ampliado...]

#Cómo encontrar palabras clave conversacionales

Herramientas para encontrar preguntas reales:

• AnswerThePublic: genera preguntas a partir de una palabra clave semilla.
• People Also Ask de Google: preguntas que la gente hace de verdad.
• AlsoAsked: árbol de preguntas relacionadas.
• Autocompletado de Google: escribe “cómo…” y observa las sugerencias.
• Google Search Console: filtra consultas que empiezan por “cómo”, “qué”, “cuál”, “dónde” y “cuándo”.

#Qué cambió en los resultados enriquecidos FAQ y HowTo en 2023

Las preguntas frecuentes y los procedimientos siguen siendo formatos naturales para la intención hablada dentro del texto, pero los resultados visuales de Google cambiaron. El 8 de agosto de 2023, Google anunció en el blog de Search Central cambios en los resultados enriquecidos HowTo y FAQ:

• FAQ: los resultados enriquecidos de FAQPage solo se muestran para sitios gubernamentales y de salud conocidos y con autoridad. Para el resto ya no se muestran de forma habitual.
• HowTo: primero se limitaron a escritorio; el 13 de septiembre de 2023 Google dejó de mostrarlos también allí y declaró el tipo obsoleto.
• Marcado existente: Google dice que no hace falta eliminarlo, porque los datos estructurados sin uso no causan problemas, pero tampoco tienen efecto visible en la búsqueda.

#Cómo estructurar una página de preguntas frecuentes para voz

Una página de preguntas frecuentes bien hecha sigue siendo útil para la voz, porque cada par pregunta y respuesta es un fragmento que un asistente puede extraer, aunque Google ya no muestre el resultado enriquecido FAQ para sitios comerciales:

• Pregunta como H2, tal como la diría un usuario hablando.
• Respuesta directa en las primeras 50 palabras.
• Si mantienes schema FAQPage, debe reflejar exactamente el texto visible.
• Nada de preguntas inventadas solo para el marcado.

#Cómo optimizar los fragmentos destacados para respuestas por voz

Los fragmentos destacados de Google invierten el formato habitual: muestran primero el extracto y después el enlace. La lógica editorial es la misma que sirve a un asistente: pregunta en el título, respuesta directa en el primer párrafo, detalle después. No existe un marcado para pedir un fragmento destacado; Google elige el extracto a partir del texto.

No fuerces fragmentos con trucos de formato. El texto tiene que ser correcto y citable; un extracto erróneo daña la marca cuando se lee en voz alta.

#Cómo controlar lo que los asistentes pueden citar

La otra mitad de la optimización es decidir qué no debe leerse. La documentación de Google sobre la metaetiqueta robots y el atributo data-nosnippet define tres controles que también alcanzan a superficies de voz e IA:

• nosnippet impide cualquier fragmento de texto de la página. Según Google, abarca la búsqueda web, Imágenes, Discover, AI Overviews y AI Mode, y el contenido deja de usarse como entrada directa para AI Overviews y AI Mode.
• max-snippet:[número] limita el fragmento a un número de caracteres. La lista de superficies afectadas incluye Assistant, y el límite también restringe cuánto texto puede usarse como entrada directa para AI Overviews y AI Mode.
• data-nosnippet es un atributo HTML para elementos span, div y section que excluye partes concretas de la página de los fragmentos.

En un sitio WordPress esto resuelve casos reales. Una tabla de condiciones comerciales que cambia cada semana, un aviso legal o un ejemplo deliberadamente incorrecto (“no lo hagas así”) pueden ir dentro de data-nosnippet, mientras el párrafo de respuesta sigue disponible. Ojo con la prioridad: si una página tiene nosnippet y data-nosnippet a la vez, gana nosnippet y no se muestra ningún fragmento. Un max-snippet muy bajo también aparta la página de los fragmentos destacados.

#Cómo encuentra Siri contenido web

Apple no publica un equivalente a Speakable. Lo que documenta es su rastreador. Según la página de soporte About Applebot, los datos que recoge Applebot alimentan varias funciones de Apple, entre ellas Siri, Spotlight y Safari. Para WordPress, esto se traduce en cuatro reglas comprobables:

1. No bloquees Applebot por accidente. Applebot respeta las directivas de robots.txt dirigidas a él. Si el archivo no tiene reglas para Applebot pero sí para Googlebot, Applebot sigue las de Googlebot. Un bloqueo pensado solo para Google puede sacar el sitio de Siri.
2. Crawl-delay no funciona con Applebot. Si necesitas limitar la carga, hazlo en el servidor o en la CDN.
3. Applebot-Extended no es un rastreador. Solo indica si el contenido recogido por Applebot puede usarse para entrenar los modelos fundacionales de Apple. Las páginas que bloquean Applebot-Extended pueden seguir apareciendo en resultados de búsqueda, y Apple dice que esas reglas no cuentan para el ranking.
4. Excluirte del entrenamiento no te saca de Siri. Incluso con Applebot-Extended bloqueado y nosnippet aplicado, Apple afirma que el contenido sigue siendo localizable a través de Spotlight, Siri y Safari.

Después de cada cambio hecho con un plugin SEO, revisa el robots.txt que se sirve de verdad en producción, no solo la pantalla de ajustes.

#Cómo publicar un flash briefing de Alexa desde WordPress

Amazon ofrece una vía que no depende del ranking: la Flash Briefing Skill API. Según la documentación de Amazon, un flash briefing ofrece a los clientes de Alexa titulares y otros contenidos breves, en texto o audio, desde un feed HTTPS en RSS o JSON. El contenido puede actualizarse como máximo cada 15 minutos y debe actualizarse al menos una vez al día.

La referencia del feed fija reglas que un editor WordPress tiene que cumplir:

• Texto leído por síntesis de voz: el campo mainText (o description en RSS) es lo que Alexa lee al cliente.
• Menos de 4500 caracteres por elemento: si se supera, el texto se corta en la frase más cercana por debajo del límite.
• Solo texto plano: sin SSML, HTML ni XML. El contenido de una entrada debe pasar por wp_strip_all_tags().
• La puntuación marca las pausas: comas y punto y coma dan pausas cortas; puntos, signos de interrogación y de exclamación, pausas más largas. Amazon desaconseja la puntuación no estándar.
• Actualidad: Alexa ignora los elementos con fecha de más de 7 días, y el orden debe ir del más reciente al más antiguo.
• Enlace “Read More”: redirectionUrl lleva al artículo en la app de Alexa.

Un endpoint REST mínimo que genera el feed JSON a partir de las entradas recientes:

add_action('rest_api_init', function () {
    register_rest_route('briefing/v1', '/feed', [
        'methods'             => 'GET',
        'callback'            => 'wppoland_alexa_briefing_feed',
        'permission_callback' => '__return_true',
    ]);
});

function wppoland_alexa_briefing_feed() {
    $items = [];
    foreach (get_posts(['numberposts' => 5, 'date_query' => [['after' => '7 days ago']]]) as $post) {
        $items[] = [
            'uid'            => 'urn:wp:post:' . $post->ID,
            'updateDate'     => get_post_modified_time('Y-m-d\TH:i:s\Z', true, $post),
            'titleText'      => get_the_title($post),
            'mainText'       => mb_substr(wp_strip_all_tags(get_the_excerpt($post)), 0, 4400),
            'redirectionUrl' => get_permalink($post),
        ];
    }
    return rest_ensure_response($items);
}

El extracto manual de cada entrada pasa a ser el texto hablado, así que conviene escribirlo como una sección Speakable: dos o tres frases autónomas, sin abreviaturas que la síntesis de voz deletree.

#Qué velocidad y TTFB necesita WordPress para búsqueda por voz

En una conversación, el silencio se nota antes que en un navegador con indicador de carga, y una página lenta también retrasa a quien abre la URL en el móvil después de la respuesta. Ninguna plataforma de voz publica un umbral de TTFB para elegir fuentes, así que usa la referencia pública: el artículo de web.dev sobre Time to First Byte indica, como guía aproximada, que un TTFB bueno es de 0,8 segundos o menos y que los valores por encima de 1,8 segundos son malos. El mismo artículo recuerda que el TTFB no es una métrica Core Web Vitals.

#Cómo reducir el TTFB en WordPress

La documentación de rendimiento de WordPress cubre caché, object cache e higiene de plugins.

1. Caché en el edge: Cloudflare APO o una CDN con caché de HTML para servir el contenido desde el nodo más cercano al usuario.
2. Arquitectura headless: migrar a Astro o Next.js genera HTML estático cuando el tema no se puede aligerar.
3. Redis Object Cache: elimina consultas repetidas a la base de datos; aísla las sesiones de WooCommerce.
4. Compresión Brotli o Gzip de las respuestas HTML.
5. HTTP/3: reduce la latencia de conexión, sobre todo en redes móviles.

#Lista de comprobación de rendimiento para voz

• TTFB de 0,8 s o menos en las regiones de tu audiencia, medido con WebPageTest o datos CrUX
• Sin JavaScript bloqueante en la ruta crítica
• Caché de página completa activada para el contenido público estable
• Comparación con los competidores que ya aparecen como respuesta en tu nicho

#En qué se diferencia la búsqueda por voz de la búsqueda de texto

#SEO local para búsquedas por voz

Muchas búsquedas habladas en el móvil son locales: “¿Dónde hay un desarrollador WordPress cerca?”

#Cómo configurar el schema LocalBusiness para búsqueda por voz

• Usa LocalBusiness (o un tipo más específico como ProfessionalService) con address, geo y openingHoursSpecification que coincidan con la realidad.
• Alinea nombre, dirección y teléfono (NAP) entre la web, el Perfil de Empresa de Google y Apple Maps.
• No inventes sedes ni direcciones: un asistente que guía a alguien a una oficina inexistente daña la marca más que no aparecer.

#Cómo optimizar Google Business Profile para búsqueda por voz

Mantén tu perfil de Google Business actualizado con:

• Horarios correctos, incluidos los festivos
• Fotos recientes del equipo y la oficina
• Respuestas a las reseñas
• Categorías de servicio precisas

#Cómo optimizar SEO de búsqueda por voz en sitios WordPress multilingües

Para sitios multilingües, cada versión necesita su propio trabajo:

1. Hreflang correcto: las etiquetas hreflang deben apuntar a las versiones correctas en cada idioma.
2. Expectativas por idioma: Speakable solo tiene efecto documentado en inglés; en las demás versiones, lo que cuenta es la respuesta escrita.
3. Contenido nativo: no traduzcas literalmente; adapta las preguntas al patrón conversacional de cada idioma.
4. Entidades localizadas: usa referencias relevantes para cada mercado.

#Cómo medir el SEO para búsquedas por voz

La voz casi nunca aparece como canal limpio en la analítica. Indicadores útiles:

1. Fragmentos destacados y People Also Ask en Search Console para tus preguntas objetivo.
2. Consultas en forma de pregunta: filtra las que empiezan por “cómo”, “qué”, “por qué”.
3. Presencia en motores de respuesta: pruebas manuales periódicas con un conjunto fijo de preguntas del sector.
4. Peticiones al feed de flash briefing en los logs del servidor, si publicas uno.
5. Tráfico de marca directo: relaciónalo con fechas de campaña sin afirmar causas que no puedas demostrar.

#Conclusión

Respuestas directas, schema honesto (Speakable solo donde Google lo admite, FAQ y procedimientos que reflejan el DOM), control de fragmentos y un TTFB medido preparan una instalación WordPress para ser citada, en pantalla y en audio. Empieza por unas pocas páginas ancla, comprueba los selectores, prueba las preguntas objetivo por voz en un móvil real y solo después extiende el patrón al resto del sitio.

Si quieres revisar tu sitio con este enfoque, consulta nuestros servicios de SEO, GEO y AEO para WordPress o contáctame.