Imagina una tienda en la que todos los paneles de control parecen estar bien. La página de inicio está indexada, Lighthouse está en verde y el validador de datos estructurados no muestra errores. Pero, justo al mismo tiempo, el precio en Google Shopping no coincide con el precio del carrito, el cajón de filtros en móvil atrapa a los usuarios de teclado y cada compra se registra dos veces.
Nada de esto aparece en una revisión de estado rápida. Y es que una tienda online es un sistema conectado, no una simple colección de páginas. Los datos de producto fluyen hacia la página, los datos estructurados y los feeds de compra. Los scripts y las etiquetas de terceros deciden lo rápido que carga todo. El checkout convierte el interés en ingresos, y se supone que la analítica registra con precisión todo el recorrido. Cuando una parte falla, puede distorsionar silenciosamente todo lo demás.
Por eso una auditoría de ecommerce útil sigue al comprador, no al sitemap. La lista de comprobación que tienes a continuación empieza por descubrir la tienda y termina con un pedido completado. Te dará una lista priorizada de problemas reales, cada uno con evidencia, un responsable y una prueba clara para saber cuándo está resuelto.
Cuándo hacer esta auditoría y por qué importa el orden
Ejecuta la auditoría completa cuando asumas un cliente de ecommerce nuevo, después de un rediseño o una migración de plataforma, antes de un gran impulso de crecimiento o cuando una revisión rutinaria detecte una regresión en toda la tienda. Reserva de tres a seis horas para una pasada ligera, o de uno a dos días para una auditoría estándar que pruebe bien cada plantilla importante. Las investigaciones en profundidad de logs, feeds o analítica suelen necesitar tiempo aparte.
El orden es deliberado. No tiene sentido juzgar la fricción de conversión si Google no puede indexar las páginas de categoría, ni tiene sentido fiarse del informe de embudo si la etiqueta de compra se dispara dos veces.
Un evento de compra duplicado no es prueba de más ventas, y una página de producto rápida no está sana si el precio que ve Google difiere del precio del carrito. Por eso la auditoría avanza por etapas. Empieza por el primer descubrimiento, luego pasa a la veracidad del producto, la velocidad y la propia compra, y solo entonces pasa a la medición.
Antes de empezar, reúne lo que necesitas. Es decir, acceso a:
- Search Console,
- Analytics,
- el gestor de etiquetas,
- la fuente del catálogo o del feed,
- Merchant Center,
- una lista de cambios recientes en el sitio.
Etapa 1: ¿Pueden los buscadores encontrar el catálogo?
1. Construye una muestra que represente toda la tienda
La mayoría de los errores de ecommerce viven en plantillas compartidas y en estados de producto poco habituales. Una página de inicio impecable no te dice nada sobre categorías filtradas, lógica de variantes, faltas de stock o checkout. Por eso deberías empezar confirmando que estás probando el sitio de producción en vivo, en el mercado, la moneda y el idioma correctos. Después elige al menos una URL para cada uno de estos casos:
- la página de inicio
- una categoría prioritaria
- una categoría más profunda o una página de filtro aprobada
- un producto típico
- un producto con variantes
- un producto sin stock o descatalogado
- una página de resultados de búsqueda interna, incluida una que no devuelva resultados
- el carrito, el checkout y la página de confirmación del pedido
Añade un ejemplo complicado o poco habitual para cualquier plantilla que parezca arriesgada. El informe de páginas de destino de tu analítica y una exportación del catálogo te ayudarán a elegir.
Has terminado cuando cada plantilla importante y cada estado del checkout tenga una URL de prueba con nombre, y todo lo que no hayas podido probar esté marcado como “no probado”.
2. Comprueba la rastreabilidad, la indexación, las canónicas y los sitemaps
Si la ruta de rastreo está rota, publicar más productos solo multiplicará el número de URL afectadas. Las señales contradictorias también dificultan el diagnóstico de los problemas. Las reglas de robots pueden decir una cosa, mientras que las etiquetas canónicas y el sitemap dicen algo completamente distinto.
Revisa el robots.txt, los sitemaps XML, los códigos de respuesta, las metaetiquetas y cabeceras de robots, las etiquetas canónicas, la paginación y los enlaces internos. Usa la Inspección de URL en Search Console para ver qué canónica eligió realmente Google para tus páginas de muestra. Después compara el sitemap con la realidad. Debería listar páginas activas e indexables que devuelvan un estado 200, no redirecciones, errores, páginas con noindex o duplicados.
Has terminado cuando tus páginas de destino previstas devuelven 200, se pueden rastrear, siguen una política coherente de canónicas e indexación y aparecen en el sitemap. Cada exclusión significativa debería tener una explicación o un responsable.
3. Sigue los enlaces: redirecciones, errores y JavaScript
Una tienda puede parecer completa en un navegador mientras los rastreadores y las tecnologías de asistencia ven una versión mucho más pobre. Ejecuta un rastreador para encontrar enlaces internos rotos, cadenas de redirecciones, bucles y soft 404. Después compara la página renderizada con el HTML sin procesar. Las tarjetas de producto, la paginación, las migas de pan y los enlaces de categoría deberían ser reales y rastreables, y el contenido importante no debería depender solo de JavaScript.
Has terminado cuando los enlaces internos apuntan directamente a su destino final, las páginas de error devuelven el código de estado correcto y los productos prioritarios se pueden encontrar sin depender del scroll infinito.
4. Prueba categorías, filtros, paginación y búsqueda interna
Los sistemas de categorías y filtros pueden crear trampas de rastreo para los buscadores y frustración para los compradores al mismo tiempo. Una página puede ser técnicamente indexable y seguir siendo una página de destino débil si la mitad de los productos que contiene son irrelevantes.
Prueba los filtros en escritorio y en móvil. Comprueba la selección múltiple, “borrar todo”, los recuentos de resultados, la ordenación, la paginación o “cargar más”, y combinaciones de filtros que no devuelven nada. Mira las URL que generan los filtros y compáralas con la política de indexación de la tienda. Fíjate también en si un bloque largo de texto de categoría empuja la cuadrícula de productos por debajo del pliegue.
Has terminado cuando los controles se comportan de forma coherente, las combinaciones aleatorias de filtros no se convierten en páginas de destino accidentales y los compradores pueden deshacer un filtro sin perder su sitio.
¿Listo para hacer crecer tu negocio?
Comienza tu prueba gratuita hoy y ve resultados en días.
Etapa 2: ¿Cuentan los datos de producto la verdad?
5. Reconcilia la identidad del producto, el precio, el stock y las variantes
Un solo campo erróneo no solo puede engañar a un comprador, sino llegar a provocar una discrepancia en el checkout. Y, al mismo tiempo, los datos pueden tener un formato perfecto y seguir siendo incorrectos.
Para un puñado de productos representativos, compara el nombre, la marca, el SKU, el GTIN o EAN, la variante seleccionada, el precio, la moneda, la disponibilidad, las imágenes y las especificaciones clave en todos los lugares donde aparecen. Comprueba lo que se muestra en la página, en los datos estructurados, en el feed del comerciante, en el carrito y en el checkout. Incluye artículos en oferta, variantes, faltas de stock, preventas y productos descatalogados.
Has terminado cuando los datos muestreados coinciden en todas las superficies, y cualquier diferencia intencionada, como marca frente a fabricante, está explícita en el modelo de datos.
6. Valida los datos estructurados contra lo que ven los compradores
Los datos estructurados solo ayudan cuando describen la página con precisión. Un validador aceptará encantado “InStock” mientras la página y el checkout dicen ambos que el producto no está disponible. Por eso deberías pasar cada estado de producto por el Test de resultados enriquecidos de Google o el Validador de Schema.org. Después compara los valores marcados con el contenido visible y con el feed de origen. Para los productos con variantes, comprueba que tu enfoque de marcado y tu configuración de canónicas coinciden con cómo están construidas realmente las páginas.
Has terminado cuando las páginas elegibles muestreadas no tienen propiedades obligatorias ausentes, el marcado coincide con lo visible, y las reseñas y valoraciones solo están marcadas cuando los compradores pueden verlas en ese producto.
Etapa 3: ¿Es la tienda rápida para compradores reales?
7. Mide primero las Core Web Vitals con datos de campo
Los datos de usuarios reales y una única ejecución de Lighthouse responden a preguntas distintas. Lighthouse te ayuda a reproducir un problema, pero no puede decirte si los compradores reales aprueban o suspenden.
Empieza con PageSpeed Insights y el informe de Core Web Vitals en Search Console. Anota si existen datos de campo para la URL exacta o solo para todo el sitio. Los umbrales de “bueno” de Google, medidos en el percentil 75, son:
- LCP (carga): 2,5 segundos o menos
- INP (capacidad de respuesta): 200 milisegundos o menos
- CLS (estabilidad visual): 0,1 o menos
Mira móvil y escritorio por separado. Si no hay datos de campo, registra el resultado como desconocido y trata los resultados de laboratorio como provisionales. Desconocido no es lo mismo que verde.
Has terminado cuando cada plantilla prioritaria tiene un veredicto de campo por dispositivo, o una falta de datos declarada claramente, con la fuente y el rango de fechas registrados.
8. Encuentra la causa, no solo la puntuación
Los consejos genéricos como “comprime tus imágenes” o “reduce el JavaScript” a menudo fallan el verdadero cuello de botella y generan trabajo que no mueve la métrica que falla. Encuentra el elemento, la petición o el script concretos responsables.
Identifica el elemento LCP y qué lo retrasa. Después revisa los sospechosos habituales, como el dimensionado de imágenes, la carga diferida en imágenes que están por encima del pliegue, el CSS que bloquea el renderizado, la carga de fuentes, los scripts de terceros, las tareas largas, el almacenamiento en caché, el tiempo de respuesta del servidor, las fuentes de desplazamiento de diseño y las etiquetas cargadas dos veces.
Ejecuta pruebas repetidas en las mismas condiciones y compara una estadística consistente, no tu mejor ejecución. Recuerda que el Total Blocking Time es una señal de laboratorio útil, pero no es el INP.
Has terminado cuando cada hallazgo de rendimiento significativo nombra la métrica que falla, la plantilla afectada, una causa reproducible y un responsable.
Únete a nuestro boletín
Obtén los últimos consejos, tendencias y ofertas gratis.
Etapa 4: ¿Puede la gente comprar de verdad?
9. Prueba la usabilidad móvil y la accesibilidad en controles de compra reales
Las puntuaciones automáticas no cubren todas las interacciones. Una tienda puede pasar un análisis mientras el cajón de filtros atrapa el foco del teclado, el banner de cookies tapa el botón de añadir al carrito o el selector de talla no tiene etiqueta accesible.
Prueba con anchuras de teléfono de 360 a 390 píxeles, amplía el texto e intenta recorrer todo el proceso solo con el teclado. Observa el orden y la visibilidad del foco en menús, cajones y diálogos. Comprueba que las etiquetas, los botones, los errores de formulario y los objetivos táctiles sigan teniendo sentido.
Has terminado cuando un comprador puede recorrer el proceso principal sin controles ocultos ni trampas de foco, y nada en móvil oculta el precio, la disponibilidad, la elección de variante, el botón de añadir al carrito o el checkout.
10. Ejecuta el carrito y el checkout como una prueba controlada
Un botón de checkout visible no demuestra que el checkout funcione. Los errores de checkout son incidentes comerciales, y además socavan tu analítica.
Para probarlo, añade al carrito un producto normal y una variante. Cambia la cantidad, elimina un artículo y aplica un cupón (o uno deliberadamente inválido) si tienes alguno. Después prueba el checkout como invitado y con cuenta, las opciones de envío, la selección de pago, los errores de validación, el botón de atrás y el diseño móvil. Usa un pedido de prueba o una ruta aprobada que no cobre. Nunca hagas un pedido real sin permiso.
Has terminado cuando la compra se completa o llega al límite de prueba acordado, los totales siguen siendo correctos, los mensajes de error dicen a la gente qué hacer y cualquier ruta bloqueada está documentada con evidencia e impacto en el negocio.
Etapa 5: ¿Estás midiendo bien el recorrido?
11. Verifica la analítica, las etiquetas duplicadas y el consentimiento
Las etiquetas duplicadas inflan las páginas vistas, los eventos de añadir al carrito y las compras. Los valores ausentes o mal formados hacen que los informes de ingresos no sean seguros como base para tomar decisiones. El objetivo es simple: una acción del comprador debería producir un evento, con el producto, el valor, la moneda, el ID de transacción y el estado de consentimiento correctos.
Enumera cada contenedor del gestor de etiquetas, etiqueta de Google, píxel publicitario, script de afiliados e integración del lado del servidor. Después, en una sesión controlada, traza view_item, add_to_cart, begin_checkout y purchase. Compara lo que envía el navegador con GA4 DebugView y con el registro del pedido en el backend. Prueba antes y después de que el comprador tome una decisión de consentimiento.
Has terminado cuando cada acción dispara su evento exactamente una vez, las compras llevan un ID de transacción estable, los valores y la moneda cuadran con el backend, y las etiquetas no esenciales respetan la política de consentimiento.
12. Reconcilia Search Console y Merchant Center con lo que has encontrado
Una prueba local de una página no puede mostrarte todas las canónicas indexadas, advertencias de sitemap, productos rechazados o consultas de búsqueda perdidas. Una alerta del panel, en cambio, puede describir un problema que ya se ha corregido.
Inspecciona tus URL prioritarias en Search Console, revisa los informes de productos y fichas de comerciante, y compara los diagnósticos de Merchant Center con lo que viste en el sitio en vivo. Anota las fechas, porque el rastreo repetido y el procesamiento de feeds van por detrás de los despliegues.
Has terminado cuando cada problema significativo del panel coincide con la evidencia en vivo o está marcado como pendiente de propagarse, y cada problema abierto tiene un responsable.
Etapa 6: ¿Confiaría un comprador en esta tienda?
13. Comprueba las señales de confianza, los datos de contacto, el envío y las devoluciones
La información comercial oculta o contradictoria hace dudar a los compradores y dispara los tickets de soporte. Compara la cabecera y el pie de página, la página de contacto, el checkout y las páginas de políticas.
Has terminado cuando la identidad del negocio es clara, las afirmaciones sobre envío, devoluciones y pago coinciden a lo largo del recorrido, y ninguna insignia de confianza es imposible de verificar.
14. Comprueba HTTPS, contenido mixto e higiene del front-end
Esto no es una prueba de penetración, sino una cuestión de higiene básica de los datos. Confirma que HTTP redirige a HTTPS en un solo salto, que el certificado es válido, que no hay contenido mixto y que los formularios se envían correctamente. Revisa la consola en busca de errores graves. Si algo parece una vulnerabilidad de seguridad real, pásalo a un especialista en lugar de diagnosticarlo a partir de una advertencia genérica.
Has terminado cuando las páginas prioritarias y el checkout cargan de forma segura, las redirecciones se hacen en un solo salto y los formularios se comportan como se espera.
De los hallazgos a las correcciones
15. Convierte los hallazgos en una cola de remediación con responsables
Una auditoría que termina en capturas de pantalla o en una puntuación no reduce el riesgo. Cincuenta síntomas causados por una sola plantilla rota no deberían convertirse en cincuenta tickets sin relación. Agrupa los hallazgos por su causa raíz. Anota si es el componente, la plantilla, la regla del feed o la configuración de seguimiento. Conserva las URL afectadas como evidencia. Después prioriza:
- P0: un fallo activo que bloquea el negocio, o un problema crítico en todo el sitio
- P1: un defecto significativo del que tienes certeza
- P2: un problema importante con alcance limitado
- P3: una mejora que hay que monitorizar
Has terminado cuando cada hallazgo significativo tiene un responsable, una fecha límite, una prueba para saber si está “corregido” y una fecha para volver a comprobarlo tras la publicación.
El entregable
Entrega un documento o una hoja de cálculo versionados, con una fila por hallazgo y un breve resumen al principio. Cada fila debería cubrir:
- El comportamiento,
- el comportamiento esperado,
- las URL afectadas,
- la evidencia y cuándo la recogiste,
- la severidad y la confianza,
- la causa probable,
- la corrección recomendada,
- el responsable y la prueba que demuestra que está hecho.
Pero recuerda que no deberías marcar un problema como corregido porque alguien haya cerrado el ticket. Márcalo como verificado cuando la prueba pase en producción.
Herramientas para el trabajo
No necesitas ninguna suscripción para hacer con éxito una primera pasada sólida. Solo necesitas estas herramientas gratuitas:
- Google PageSpeed Insights para datos de campo (cuando estén disponibles) y diagnósticos de Lighthouse
- Google Search Console para indexación, sitemaps, Inspección de URL, Core Web Vitals e informes de datos estructurados
- Test de resultados enriquecidos de Google y el Validador de Schema.org para datos estructurados
- Chrome DevTools y Lighthouse para comprobaciones de red, rendimiento, desplazamientos de diseño, accesibilidad y consola
- Google Tag Assistant y GA4 DebugView para el seguimiento de eventos
- SSL Labs Server Test para la configuración de TLS
Si quieres un atajo, AmICited te permitirá reunir toda esa evidencia y conservar la línea base para más adelante. La vista de Impacto en el rendimiento compara plantillas por LCP, INP, CLS y tiempo de respuesta del servidor. La Inspección de URL y Sitemaps e indexación hacen seguimiento de la indexación de las URL prioritarias. Productos y Surtido muestran qué partes del catálogo tienen más peso comercial. Las anotaciones en el Centro de informes vinculan cada publicación con lo que ocurrió después. Las herramientas aportan la evidencia. El propietario de la tienda, el desarrollador o el analista siguen decidiendo qué es correcto y qué compromisos son aceptables.
Después de la auditoría
Envía cada problema confirmado al flujo de trabajo especializado que pueda cerrarlo: los problemas de rastreo y renderizado a una auditoría de SEO técnico , los fallos de rendimiento de campo a la corrección de Core Web Vitals , los problemas de facetas y estados de stock a una revisión de categorías y productos , y los problemas de seguimiento a quien sea responsable de la analítica.
No hace falta volver a ejecutar toda la auditoría después de cada corrección. Vuelve a probar el área afectada, anota la publicación para poder ver qué cambió después y deja que la revisión de estado periódica detecte la siguiente regresión.
Volvamos a la tienda donde todo parecía estar bien
¿Recuerdas la tienda del principio? Su página de inicio estaba indexada, Lighthouse estaba en verde y el validador estaba limpio. Y, sin embargo, Google Shopping mostraba el precio equivocado, el cajón de filtros atrapaba a los usuarios de teclado y cada venta se contaba dos veces.
Ningún panel avisó de nada de eso. Esta lista de comprobación habría detectado los tres: la discrepancia de precio en el paso 5, la trampa de foco en el paso 9 y la compra contada dos veces en el paso 11. Cada uno se rompe en algún punto del recorrido del comprador, y ahí es exactamente donde mira la auditoría.
Eso es lo que consigues siguiendo al comprador en lugar del sitemap. Dejas de preguntar “¿parece que el sitio está sano?” y empiezas a hacer cuatro preguntas más difíciles. ¿Puede la gente encontrar el producto? ¿Es verdad lo que la tienda dice sobre él? ¿Pueden comprarlo de verdad? ¿Y puedes ver que lo han hecho? Una tienda que puede responder sí a las cuatro está en mejor forma que otra con una puntuación perfecta.
Así que elige tus URL de muestra, reserva el tiempo y empieza por la etapa 1. La primera pasada es la más lenta. Después de eso, el trabajo consiste sobre todo en asegurarte de que lo que has corregido sigue corregido.
