Una auditoría técnica SEO para una tienda WooCommerce revisa puntos clave con foco práctico. Revisa velocidad, indexación, estructura de URLs y etiquetas canónicas. También comprueba datos estructurados de producto, navegación por filtros, rendimiento del servidor y errores de crawling. Dicho de otro modo, entrega una lista priorizada de reparaciones con estimación de tiempo. En la práctica se incluyen pruebas antes y después en Search Console, Analytics y Lighthouse. Este trabajo tarda entre 1 y 5 días según el tamaño de la tienda.
Resumen del proceso
- Preparar acceso y datos esenciales
- Crawling completo con Screaming Frog y extracción de issues
- Revisar Search Console y errores de indexación
- Comprobar estructuras canónicas y paginación
- Auditar product schema para productos simples y variables
- Analizar navegación facetada y parámetros
- Medir rendimiento con Lighthouse y revisar servidor
- Ejecutar arreglos rápidos y validar en preproducción
- Priorizar con matriz impacto versus esfuerzo
- Entregar informe y KPI antes/después
Paso 1 preparar accesos y datos rápidos
La auditoría comienza pidiendo accesos y datos concretos al equipo técnico o al proveedor. Solicitar usuario de Search Console con permisos de propietario o propietario delegado. Pedir acceso a Google Analytics o GA4. Añadir FTP/SFTP o cPanel y credenciales de administrador de WordPress y WooCommerce. Solicitar credenciales temporales para el entorno de pruebas. Además pedir una copia del sitemap XML y la lista de URLs principales como categorías, productos y atributos. Este paso suele tardar entre 30 y 90 minutos.
Por eso es frecuente el error de pedir solo lectura. Si falta permiso para inspeccionar o para indexar no se podrán validar correcciones. Si la tienda tiene más de 50.000 URLs pedir un dump del sitemap por lotes. Esto tarda más y ralentiza el inicio del análisis.
Paso 2 crawling con Screaming Frog y comandos WP CLI
Hacer un crawling completo con Screaming Frog para replicar cómo rastrea Google. Configurar en modo spider y activar renderizado JavaScript si el tema usa bloques. Desactivar "respetar robots.txt" solo cuando se audita una versión de producción bloqueada. Filtrar por contenido duplicado con Duplicate Content en Screaming Frog. Verificar etiquetas canónicas en Search > Canonicals. Exportar los resultados en CSV y añadir columnas de prioridad y horas estimadas antes de pasar a desarrollo. Esto acelera el trabajo del desarrollador.
Ejemplos de filtros útiles en Screaming Frog:
- Encontrar URLs con query strings usando regex /? en Address
- Detectar páginas de facetas buscando términos comunes como filter, orderby, min_price, color
Comandos WP-CLI imprescindibles:
- Listar productos:
wp post list --post_type=product --fields=ID,post_title,post_name --format=csv (tarda 10 a 60 segundos según la base de datos)
- Eliminar transients acumulados que ralentizan:
wp transient delete --all (advertencia abajo)
- Regenerar permalinks si hace falta:
wp rewrite flush (usar con cuidado; obliga a reconstruir caché)
Consejo práctico: exportar la lista de páginas con problemas desde Screaming Frog en CSV. Añadir una columna "razón" con la etiqueta del problema como noindex, canonical roto o meta vacía. Quien no use Screaming Frog puede usar Sitebulb o el crawler de Ahrefs. La diferencia es que Screaming Frog permite inspección muy granular y añadir notas internas.
💡 Consejo
Exportar los resultados de Screaming Frog por tipo de URL producto, categoría, tag y paginación. Añadir una columna «razón» con la etiqueta del problema como noindex, canonical rotos o meta vacía. Esto acelera la entrega al desarrollador.
Paso 3 comprobar Search Console y problemas de indexación
Abrir Google Search Console y revisar la sección de Cobertura. Descargar el CSV de errores y de páginas excluidas. Filtrar por noindex y por "crawled - currently not indexed". Usar la herramienta de inspección de URL en tres pruebas: una categoría, un producto simple y una página de facetas con parámetros. Registrar el estado de cada URL y guardar capturas de pantalla. Revisar la lista de errores como 5xx, soft 404 y redirecciones.
Dicho de otro modo, no confiar solo en el número total de páginas indexadas. Hacer inspecciones manuales con muestras reales. En WooCommerce es común encontrar miles de URLs marcadas como "excluida por crawl anomaly" por filtros. Revisar 20 a 30 ejemplos representativos toma entre 30 y 60 minutos.
Pasos concretos dentro de Search Console:
- En Cobertura descargar CSV de errores y excluidas
- Filtrar por "noindex" y por "crawled - currently not indexed"
- Inspeccionar 3 a 5 URLs de producto y 3 a 5 de categoría
- En Rendimiento filtrar por páginas concretas y registrar impresiones y CTR de los últimos 90 días
Error que bloquea a la mayoría: confiar solo en estadísticas agregadas. Search Console tarda en actualizarse. Por eso siempre inspeccionar muestras reales.
Paso 4 auditar canónicos y paginación
Comprobar que cada producto tenga una única URL canonical. Evitar que las variaciones canibalicen la URL principal. En WooCommerce la confusión surge cuando las variaciones generan URLs indexables como producto-v1?attribute_color=rojo. Reglas prácticas:
- Productos simples deben tener canonical a la URL limpia sin parámetros
- Productos variables deben canonical a la página principal del producto
- Solo permitir canonical a una variación si tiene contenido propio y stock independiente
- Paginación de listados puede usar
rel="prev/next" o canonical a la primera página según la estrategia
La forma rápida para catálogos grandes es noindex en páginas 2 y siguientes de categoría. La forma correcta es implementar canonical a la página 1 y controlar parámetros con parameter handling en Search Console y ajustes en robots.txt cuando proceda. La versión rápida suele tardar 1 a 2 horas. La implementación correcta con pruebas en staging y cambios en plantilla y plugins puede tardar 4 a 12 horas.
Snippet de rel=canonical para la plantilla de producto (PHP dentro del tema):
<link rel="canonical" href="<?php echo esc_url( get_permalink( $product_id ) ); ?>" />
Infografía del flujo de auditoría
1 Preparar accesos
2 Crawling Screaming Frog
3 Revisar Search Console
4 Canónicos y Pag.
5 Schema Productos
6 Rendimiento
Paso 5 validar product schema y datos estructurados
El product schema es clave para que Google muestre rich snippets y mejorar el CTR. Debe contener al menos Product, Offer, Price, Availability, SKU, brand e image. Para productos variables el Offer puede describir un rango de precios. Evitar generar un schema idéntico para todas las variaciones cuando cambian precio o disponibilidad. Ese error impide que Google use los rich snippets.
Ejemplo mínimo de JSON-LD para producto variable que usa rango de precios:
<script type="application/ld+json">
{
"@context": "https://schema.org/",
"@type": "Product",
"name": "Nombre del producto",
"image": ["https://tu-tienda.com/wp-content/uploads/imagen.jpg"],
"sku": "SKU123",
"brand": {"@type":"Brand","name":"MarcaX"},
"offers": {
"@type": "AggregateOffer",
"lowPrice": "19.99",
"highPrice": "29.99",
"priceCurrency": "EUR",
"offerCount": 3,
"availability": "https://schema.org/InStock"
}
}
</script>
Para cada producto simple usar un Offer individual. Para catálogos grandes generar el JSON-LD de forma dinámica en la plantilla del producto. Herramientas de validación: Rich Results Test de Google y la referencia de schema.org/Product. Tiempo estimado: implementar para 10 a 50 productos tarda entre 2 y 6 horas si el tema lo soporta. Para más de 500 productos conviene generar programáticamente y puede tardar 1 a 3 días.
⚠️ Atención: no añadir ofertas contradictorias en el mismo JSON-LD. Google suele ignorar el schema si hay datos inconsistentes. Si la tienda usa plugins como Yoast o Rank Math revisar duplicados y desactivar inyecciones dobles.
Paso 6 gestionar la navegación facetada y filtros
La navegación facetada suele provocar indexación masiva y consumir el crawl budget. Identificar primero los parámetros de filtro habituales como min_price, max_price, color, size, orderby y page. Decidir qué parámetros generan páginas útiles para indexación y cuáles no. Aplicar noindex,follow a las URLs de facetas que no aportan valor. O bien canonical a la categoría principal si la faceta no tiene contenido propio.
Usar Search Console en Parámetros de URL para indicar a Google cómo tratar parámetros poco relevantes. Por ejemplo, /ropa/camisas/?orderby=price-asc conviene dejarlo noindex y canonical a /ropa/camisas/. Para filtros de color con stock propio, permitir indexación solo si la URL tiene contenido añadido y reseñas.
Snippet para añadir meta robots noindex en plantilla de filtros (PHP):
if ( isset( $_GET['orderby'] ) || isset( $_GET['min_price'] ) ) {
echo '<meta name="robots" content="noindex,follow" />';
}
Opinión experta: la navegación facetada mal gestionada es desperdicio directo del presupuesto de rastreo y reduce la probabilidad de que Google rastree páginas de producto con alta conversión. Por eso priorizar la gestión de facetas suele ofrecer retorno rápido en tiendas medianas y grandes.
Infografía de decisiones de facetas
Parámetro
¿Indexar?
Acción
orderby
No
noindex,canonical
color (stock propio)
Sí si única
indexar si contenido único
Paso 7 rendimiento y optimizaciones específicas para WooCommerce
Medir con Lighthouse en modos Mobile y Desktop. Apuntar a mejoras concretas en First Contentful Paint, Largest Contentful Paint y Time to Interactive. En WooCommerce las causas de lentitud son recurrentes. Ejemplos: consultas no optimizadas en wp_postmeta, transients acumulados, widgets de mini carrito que invalidan la caché y miniaturas sin lazy load.
Optimizaciones prácticas recomendadas:
- Implementar caché a nivel de servidor con exclusiones para carrito y checkout usando Varnish o reglas de Nginx
- Evitar fragment cache que se invalidan en cada visita. Usar fragment caching selectivo y AJAX para el mini carrito
- Optimizar imágenes y servir WebP. Regenerar miniaturas con tamaños exactos
- Reducir consultas por producto revisando meta queries en funciones que listan productos. Transformar a JOINs cuando proceda
La auditoría del rendimiento suele requerir pruebas y ajustes iterativos. Algunas correcciones rápidas dan resultados visibles en horas. Otras optimizaciones profundas pueden necesitar uno o varios días de desarrollo.
Preguntas Frecuentes
¿Qué incluye una auditoría técnica SEO para WooCommerce?
Revisa velocidad, indexación, estructura de URLs, etiquetas canónicas, datos estructurados de producto, navegación facetada, rendimiento del servidor y errores de crawling. Entrega una lista priorizada de reparaciones con estimación de tiempo y pruebas antes/después en Search Console, Analytics y Lighthouse.
¿Cuánto tarda una auditoría técnica SEO en una tienda WooCommerce?
Depende del tamaño y complejidad: una tienda pequeña puede revisarse en 1–2 días, mientras que catálogos grandes o con mucha navegación facetada pueden requerir 3–5 días. El tiempo incluye crawling, análisis, pruebas en preproducción y elaboración del informe con prioridades.
¿Cómo optimizar los datos estructurados (product schema) en WooCommerce para obtener rich snippets?
Asegúrate de que el markup JSON‑LD incluya nombre, SKU, precio, moneda, disponibilidad y valoraciones; usa un plugin fiable (p. ej. Yoast, Rank Math o Schema Pro) y evita marcado duplicado del theme y plugins. Valida los resultados con la herramienta Rich Results Test de Google y corrige errores o campos faltantes.
¿Cómo evitar problemas de indexación con filtros, paginación y parámetros en WooCommerce?
Implementa etiquetas rel=canonical hacia la versión canónica (por ejemplo la primera página de categoría), marca páginas facetadas como noindex,follow cuando no aporten valor y usa manejo de parámetros en Search Console si procede. Además, controla el crawling con robots.txt y limita la generación de URLs mediante buenas prácticas en el frontend (p. ej. carga dinámica de filtros).
