Si tu web migró a JavaScript o las reseñas han desaparecido, el marcado inválido puede hundir CTR y ventas justo en las páginas que más importan. Necesitas pasos claros, plantillas listas y garantías contra errores técnicos o sanciones para recuperar visibilidad y conversiones.
Los rich snippets (FAQ, HowTo, Reviews) usan schema para destacar tu contenido en Google y aumentar CTR. Este artículo contiene plantillas JSON‑LD editables y listas para copiar, pasos para implementarlo en sitios estáticos y SPA (SSR/prerender), validación con herramientas oficiales, scripts CI para tests automáticos, checklist de monitorización y soluciones rápidas si Google deja de mostrar los rich results, más pautas legales y anti‑fraude para reseñas y AggregateRating. Seguir la hoja de ruta permite aplicarlo y comprobar resultados en horas.
Resumen del proceso: 6 pasos para tener snippets visibles
Aplica este proceso y tendrás marcado válido y comprobado en horas en páginas críticas. Los pasos siguientes cubren detección, plantillas, integración en JS, pruebas automáticas, despliegue y monitorización.
- Detectar y validar errores en Search Console y Rich Results Test.
- Pegar y adaptar plantillas JSON‑LD para Product, Review, FAQPage y HowTo.
- Servir JSON‑LD desde SSR/prerender en sitios JS o prerenderizar HTML.
- Añadir pruebas en CI que ejecuten Rich Results Test API y Puppeteer.
- Desplegar con rollback y hacer A/B para medir CTR y conversiones.
- Mantener monitorización y auditoría legal de reseñas.
¿Por qué empezar por search console?
Search Console da la lista de páginas afectadas y fechas de fallo en un solo lugar. Conserva hasta 16 meses de datos para comparar periodos (dato 2024).
¿Qué cubre el proceso en pocas palabras?
El proceso cubre corrección técnica, cumplimiento de políticas de reseñas y pruebas de indexación en entornos que ejecutan JavaScript. La solución completa evita pérdidas de visibilidad tras migraciones.
Paso 1: detectar y validar problemas con rapidez
Revisa Search Console y el Rich Results Test para identificar páginas y errores concretos. Localiza la primera página afectada y la fecha del cambio para correlacionar con despliegues.
¿Cómo validar con search console?
Abre el informe de "Resultados enriquecidos" y filtra por tipo de rich result. Marca la fecha del primer error y exporta la lista de URLs afectadas.
¿Cómo usar rich results test y la API?
Ejecuta Rich Results Test en una URL y compara la salida con la que ve un usuario real. Para automatizar, usa la Rich Results Test API desde CI y compara JSON entre builds.
Señal práctica: qué mirar primero
El error más frecuente en este punto es usar URLs relativas en el campo "image" o en "@id" del JSON‑LD. Eso rompe la indexación aunque el JSON sea sintácticamente correcto.
Search Console identifica páginas concretas afectadas y sugiere el tipo de error. Usar esa información reduce el tiempo de diagnóstico a minutos.
Los impactos en CTR y conversiones de los rich snippets varían según intención de búsqueda y formato: en tests controlados de ecommerce y contenidos HowTo se observan rangos distintos por tipo de snippet. Resúmenes prácticos de múltiples pruebas A/B muestran que FAQPage y HowTo aportan mejoras de visibilidad en consultas informacionales (mejoras de CTR que suelen oscilar entre un 5% y un 20% en búsquedas con intención de guía), mientras que AggregateRating y reseñas en páginas de producto tienden a aumentar CTR y tasa de clics comerciales en rangos más conservadores (por ejemplo, 5%–15%), condicionados por el volumen de impresiones y la calidad de la tienda.
Estos números son indicativos: la única forma de confirmar el efecto en tu dominio es ejecutar A/B tests con objetivos de CTR y conversión, y medir con Search Console y herramientas de analítica para aislar el impacto del fragmento enriquecido.
Paso 2: implementar plantillas JSON‑LD listas para copiar
Pega estas plantillas y edítalas sustituyendo los campos entre corchetes. Cada bloque incluye notas de adaptación y problemas comunes que requieren corrección inmediata.
Plantilla: Product con offer y aggregateRating
{
"@context": "https://schema.org",
"@type": "Product",
"@id": "https://ejemplo.com/producto/sku-123#product",
"name": "Nombre del producto",
"image": ["https://ejemplo.com/images/sku-123-1200x1200.jpg"],
"description": "Descripción breve del producto en español.",
"sku": "SKU-123",
"gtin13": "0123456789012",
"brand": { "@type": "Brand", "name": "Marca S.A." },
"offers": {
"@type": "Offer",
"url": "https://ejemplo.com/producto/sku-123",
"priceCurrency": "EUR",
"price": "49.90",
"availability": "https://schema.org/InStock",
"priceValidUntil": "2025-12-31"
},
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.4",
"reviewCount": "48"
}
}
Plantilla: Review individual vinculada a Product
{
"@context": "https://schema.org",
"@type": "Review",
"reviewAspect": "calidad",
"itemReviewed": { "@type": "Product", "@id": "https://ejemplo.com/producto/sku-123#product" },
"author": { "@type": "Person", "name": "Cliente anónimo" },
"reviewRating": { "@type": "Rating", "ratingValue": "5", "bestRating": "5" },
"datePublished": "2024-03-18",
"reviewBody": "Texto de la reseña..."
}
Plantilla: FAQPage con múltiples Q/A
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "¿Cómo se instala este producto?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Instrucciones paso a paso..."
}
}
]
}
Plantilla: HowTo con imágenes y tiempos
{
"@context": "https://schema.org",
"@type": "HowTo",
"name": "Montaje de mesa",
"totalTime": "PT30M",
"estimatedCost": { "@type": "MonetaryAmount", "currency": "EUR", "value": "0" },
"step": [
{
"@type": "HowToStep",
"name": "Desembalar",
"text": "Sacar las piezas y colocarlas sobre una superficie plana.",
"image": "https://ejemplo.com/images/step1.jpg",
"time": "PT5M"
}
]
}
Adaptación y errores comunes al pegar
El error típico es no actualizar el campo "@id" y dejar URLs del entorno de pruebas. También es habitual olvidar el idioma en el texto y usar imágenes con tamaño inferior a 800x800, lo que da warning en Rich Results Test.
Para escenarios de servicio y FAQs complejas conviene usar plantillas JSON‑LD adaptadas que reflejen campos específicos de Service y estructuras ricas de preguntas. Por ejemplo, el tipo Service en schema.org admite serviceType, provider, areaServed, termsOfService y offers (si aplican), lo que permite a Google entender mejor el alcance comercial y conectar reseñas (aggregateRating) a un servicio concreto. En FAQs extensas, utiliza varias entradas Question en FAQPage, cada una con su acceptedAnswer; para respuestas alternativas puede repetirse la Question con diferentes matices o separar en secciones por intención.
En HowTo complejos incluya HowToStep como array, image como array de URLs de alta resolución y totalTime/performTime en formato ISO 8601 (ej. PT1H30M). Estos detalles mejoran la calidad de los datos estructurados y aumentan la probabilidad de que Google genere fragmentos enriquecidos relevantes que impacten el CTR desde la SERP.
Paso 3: integración en sitios JavaScript: SSR
Sirve el JSON‑LD dentro del HTML que entrega el servidor para que Googlebot lo vea sin ejecutar JavaScript. Esto evita la mayoría de problemas de indexación en SPAs.
¿SSR, prerender o cliente?
Priorizar SSR o prerender en páginas de producto y guías HowTo. Usar CSR solo en piezas no críticas que no necesiten rich results.
Ejemplo en next.js
js
// pages/producto/[slug].js
import Head from 'next/head'
export default function Producto({ productJsonLd }){
return (
<>
{/
resto de la página /}
</>
)
}
Ejemplo en nuxt: head con SSR
Usar el objeto head() en la página o componente y devolver el JSON‑LD serializado. Probar con "nuxt generate" y verificar HTML final.
1 Detectar
Search Console + Rich Results Test para listar URLs
2 Marcar
JSON‑LD por plantilla para Product/FAQ/HowTo/Review
3 Servir
SSR/prerender para que Googlebot vea el marcado
Esto funciona bien en teoría
Algunos proveedores de hosting añaden cachés que sirven HTML obsoleto. Las implementaciones SSR requieren invalidación de cache y comprobación de HTML final tras deploy; sin eso, Google verá la versión vieja.
Paso 4: playbook operativo cuando Google quita
Sigue estos pasos en orden: detectar, aislar, corregir, desplegar, monitorizar y reportar. Cada paso tiene acciones concretas y un tiempo objetivo.
Detectar: señales y rapidez de actuación
Detecta la caída con alertas en Search Console y monitor de CTR; actúa en 24–72 horas para evitar pérdida de tráfico prolongada. Un control rápido del primer día reduce pérdidas en semanas.
Aislar: identificar plantillas o cambios
Comprobar commits recientes, deploys y cambios de CDN. Un caso habitual: una librería de imágenes cambió URL base y el campo "image" quedó roto en miles de páginas.
Corregir y desplegar
Corrige el marcado y despliega en staging. Ejecuta tests automáticos y validación manual con Rich Results Test antes de promoción a producción.
Automatizar pruebas en CI
Incluye este ejemplo de GitHub Actions para ejecutar Puppeteer y la API de Rich Results Test.
Yaml
name: schema-check
on: [push]
jobs:
test-schema:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Install Node
uses: actions/setup-node@v3
with: node-version: '18'
- run: npm ci
- run: node scripts/run-rich-test.js
Monitorizar y medir recuperación
Vigila CTR y posición durante 2–4 semanas tras el fix. Un A/B controlado permite confirmar que la recuperación ocurre por el snippet y no por otros cambios.
Un test A/B suele requerir entre 2 y 4 semanas para alcanzar significación estadística en búsquedas con tráfico medio.
La evidencia visual de la diferencia entre HTML servido y HTML renderizado por cliente es clara en capturas de Fetch as Google en Search Console.
Automatizar la validación de datos estructurados dentro de CI reduce el riesgo de romper rich snippets tras deploys. Una práctica efectiva combina Puppeteer (o Playwright) para renderizar la página y extraer el HTML final, con llamadas a la Rich Results Test API para validar la respuesta de Google sobre tipos soportados y errores (valid, status y lista de problemas). El script puede:
- Lanzar un navegador headless
- Navegar a la URL y esperar el DOM final
- Extraer todos los bloques
<script type="application/ld+json">
- Enviar el HTML o la URL a la API y
- Fallar el job si aparecen errores críticos. Integrado en GitHub Actions, GitLab CI o un pipeline propio, este flujo permite notificar automáticamente al equipo (Slack/email) y bloquear merges que introduzcan marcado inválido, manteniendo control sobre
schema.org, JSON-LD y fragmentos enriquecidos en entornos con SSR o prerender
Errores que arruinan el resultado: lista priorizada
Corrige estos errores antes de cualquier optimización de contenido; son los que más frecuentemente hacen desaparecer rich results.
¿URLs relativas en campos críticos?
Usar URLs relativas en "image", "@id" o "url" provoca fallos de validación y falta de indexación. Usar siempre URLs absolutas completas.
¿Marcar contenido duplicado o con poco valor?
Marcar páginas sin contenido único reduce la probabilidad de que Google muestre rich results. El motor evita premiar contenido sin valor añadido.
¿Reseñas incentivadas o sin procedencia?
Publicar AggregateRating a partir de reseñas no verificadas puede provocar pérdida del snippet y problemas legales. La AEPD y la normativa de la UE obligan a transparencia.
| Opción |
Tiempo típico |
Riesgos |
Cuándo elegir |
| SSR (Next/Nuxt) |
minutos a horas |
Complejidad de despliegue |
Páginas críticas con alto tráfico |
| Prerender (Rendertron/Puppeteer) |
horas |
Caché de snapshots |
SPAs con pocas rutas críticas |
| CSR (cliente) |
instante |
Google puede no ejecutar JS siempre |
Recursos no críticos sin snippets |
Cuándo no funciona este método y alternativas
No conviene priorizar rich snippets si la página no tiene contenido único (por ejemplo, páginas internas sin preguntas, listados sin descripciones o productos sin reseñas reales). Tampoco aplicar AggregateRating si no se puede verificar la procedencia de las reseñas o si existen incentivos no declarados. En esos casos priorizar meta títulos, mejoras en descripción y datos estructurados básicos para mejorar CTR sin riesgo.
Disponibilidad de auditoría técnica bajo pedido para revisar marcado, pipelines de CI y cumplimiento de reseñas.
Preguntas frecuentes
¿Rich snippets Google qué es?
Los rich snippets son fragmentos enriquecidos que muestran información adicional en la SERP basada en datos estructurados. Mejoran la visibilidad y el CTR cuando Google decide mostrarlos.
¿Qué es un marcado de esquema para reseñas?
El marcado de reseñas describe Review, Rating y itemReviewed usando JSON‑LD, Microdata o RDFa. Google recomienda JSON‑LD para la mayoría de casos.
¿AggregateRating cuándo aplicarlo?
Aplicar AggregateRating solo si las reseñas provienen de usuarios verificables y están moderadas. Publicar ratings sin control puede invalidar los rich results.
¿Cómo probar que Google ve el schema en una SPA?
Usar Fetch as Google en Search Console o capturas de HTML final tras prerender. Si el HTML no contiene el JSON‑LD, Google no lo indexará.
¿Qué coste tiene optimizar rich snippets?
El coste varía según alcance: auditoría técnica puntual puede costar entre 300 y 1.200 EUR (orientativo, 2024). Integración completa en ecommerce suele requerir más tiempo y presupuesto.
¿Qué hacer si Google anuncia que deja de soportar un tipo de marcado?
Seguir el playbook: identificar páginas afectadas, retirar marcado obsoleto y migrar a tipos soportados. Mantenerse al día con Google Search Central y documentación de Schema.org.
