100 auditorías ecommerce bajo la lupa: SEO técnico, velocidad y qué corregir primero

Investigación original de Shugert | 100 tiendas únicas | 28 de septiembre de 2026 | Actualizado en octubre de 2026 | Equipo de SEO técnico e ingeniería de Shugert

Resumen ejecutivo: qué revelaron realmente las primeras 100 auditorías

Una tienda online puede aprobar muchas comprobaciones automáticas de SEO y, al mismo tiempo, tardar demasiado en mostrar el contenido que el comprador necesita. Esta es la tensión más clara en nuestro análisis de las primeras 100 tiendas únicas del lote de investigación para prospección auditado por Shugert el 28 de septiembre de 2026.

La distinción más importante es metodológica. De las 100 tiendas, 59 disponían de mediciones completas de Lighthouse en móvil y escritorio, 23 contaban con mediciones parciales y 18 solo tenían una inspección básica de respaldo. Las últimas 18 no entran en las tasas de rendimiento que publicamos.

Entre los registros con una medición utilizable para cada indicador, 73 de 81 (90,1 %) mostraron LCP superior a cuatro segundos, 74 de 82 (90,2 %) transfirieron más de 4 MB, 68 de 82 (82,9 %) superaron 5,8 segundos de Speed Index y 56 de 82 (68,3 %) tuvieron un FCP superior a tres segundos. Los denominadores cambian porque algunas auditorías carecen de determinados datos.

Esto no significa que el 90 % de todo el ecommerce falle Core Web Vitals. La muestra no es aleatoria: procede de prospectos identificados para una campaña comercial, se limita a URL concretas y refleja pruebas de laboratorio en una ventana corta. Tampoco permite atribuir pérdidas de ingresos, caídas de rankings o sanciones algorítmicas sin contrastar Search Console, CrUX, analítica y conversiones.

La conclusión útil es otra: el SEO técnico y la ingeniería de rendimiento se tienen que estudiar juntos, pero sin confundir las señales de uno con las pruebas del otro.

Las cifras más importantes del estudio

La mediana fue de aproximadamente 11,7 segundos de LCP (n=81), 7,28 MB de peso de página (n=82) y 8,94 segundos de Speed Index (n=82). Estos valores representan ejecuciones concretas de laboratorio, no visitas reales. Conviene repetir las pruebas antes de usar un resultado para tomar decisiones sobre una tienda individual.

Cómo seleccionamos las tiendas y medimos los resultados

Seleccionamos el registro más antiguo de cada hostname único de los lotes de auditoría interna en inglés identificados como cold_outreach%. Ordenamos esas primeras mediciones cronológicamente y conservamos los primeros 100 dominios. El intervalo observado fue el 28 de septiembre de 2026, entre las 14:49 y las 19:41 UTC, aproximadamente. Excluimos pruebas posteriores del mismo dominio, auditorías realizadas desde el formulario público y otros lotes ajenos a esta muestra.

El flujo consultó Google PageSpeed Insights/Lighthouse para móvil y escritorio siempre que fue posible. Cuando faltaba una de esas respuestas, marcó los resultados como parciales; cuando no disponía de Lighthouse, recurrió a inspección HTTP/HTML básica. La técnica describe la URL evaluada: no sustituye un rastreo completo del catálogo, una prueba real de checkout, un análisis de revenue ni una auditoría de accesibilidad manual.

La cohorte incluye escaparates públicos reconocibles como Dame, Cosabella, CrunchLabs, L'AGENCE, Nivada Grenchen, Paddywax, Plunge, Princess Polly, SPIbelt y The Perfect Jean. Los citamos como ejemplos de la variedad de marcas observadas, no como clientes, patrocinadores ni avales. Tampoco publicamos imputaciones técnicas individuales sin repetir la prueba: el estudio se presenta de forma agregada. La detección de plataforma fue incompleta, de modo que hablamos de tiendas ecommerce, no de 100 tiendas Shopify confirmadas.

Una alerta importante sobre el propio instrumento

En la revisión del código de nuestro auditor encontramos que algunas verificaciones de Lighthouse con puntuación nula o ausente se convertían en un falso cero. Esto podía marcar como fallidas las pruebas de imágenes o recursos que bloquean el renderizado aunque Lighthouse no hubiera emitido una calificación. La ausencia de HTML en una segunda petición también podía generar una alerta errónea de etiqueta viewport.

Esas alertas no forman parte de las tasas de defectos confirmados de este informe. La documentación de Lighthouse explica que score: null puede significar que una prueba es informativa, no aplicable, manual o errónea y, por tanto, debe ignorarse como nota numérica.

La puntuación general que calcula nuestro sistema es un índice propio de semáforo ponderado; no es un score de Google ni una predicción de rankings. Las auditorías de respaldo recibieron a menudo valores artificialmente altos porque carecían de muchos controles de rendimiento. Por eso no mezclamos esos puntajes con los de Lighthouse.

Regla de cálculo: para cada métrica contamos cuántas tiendas tenían ese dato, y calculamos el porcentaje de las que cruzaron un umbral explícito. Una tienda sin LCP no cuenta como aprobada ni como reprobada. No incorporamos GSC, facturación, posiciones históricas, resultados de asistentes IA ni Core Web Vitals de usuarios reales a este benchmark.

Hallazgo 1. El LCP de laboratorio destaca como problema de experiencia inicial

73 de las 81 tiendas evaluables presentaron un LCP superior a cuatro segundos; la mediana del grupo fue 11,7 segundos. En el subconjunto de 59 mediciones completas en móvil y escritorio, la mediana llegó a 12,81 segundos. Se trata de observaciones sintéticas preocupantes, pero no equivalen al LCP del percentil 75 de CrUX, que es el estándar para evaluar Core Web Vitals reales.

LCP representa el momento en el que termina de aparecer el elemento más grande de la zona visible: habitualmente un hero, una fotografía de producto o un bloque editorial. Puede demorarse por un servidor lento, descubrimiento tardío de imágenes, excesivo tamaño de descarga, fuentes, estilos y scripts bloqueantes o interfaces que dependen de JavaScript para generar el contenido principal.

Cómo diagnosticarlo correctamente: localizar el elemento LCP concreto con DevTools, dividir el tiempo entre TTFB, retraso de carga, descarga y render, comparar dispositivos y plantillas, y consultar CrUX cuando haya suficiente tráfico. No conviene precargar todas las imágenes ni eliminar apps a ciegas.

En Shopify recomendamos generar el HTML principal con Liquid, utilizar los filtros image_url e image_tag, servir srcset y sizes, evitar loading="lazy" en la imagen LCP verificada y valorar fetchpriority="high" en ese único recurso crítico. Shopify también advierte que abusar de preload empeora la priorización del navegador. Buenas prácticas oficiales de Shopify · Core Web Vitals de Google.

Ejemplo ilustrativo en Liquid (no aplicarlo indiscriminadamente):

{% if section.settings.hero_image %}
  {{ section.settings.hero_image
    | image_url: width: 1800
    | image_tag: widths: '480, 750, 1100, 1500, 1800',
      sizes: '(max-width: 749px) 100vw, 100vw',
      loading: 'eager',
      fetchpriority: 'high',
      alt: section.settings.hero_image.alt
  }}
{% endif %}

Solo debe utilizarse si la imagen es realmente el elemento LCP de esa plantilla. Si el elemento principal es texto u otra imagen móvil, la solución cambia.

Hallazgo 2. El peso de página concentra una parte importante de la fricción

En 74 de 82 registros el peso transferido superó los 4 MB y la mediana fue de 7,28 MB. Ese límite es una referencia operativa de Shugert, no un umbral oficial de posicionamiento de Google. Importa qué se descarga, cuándo se descubre cada recurso, cuánto trabajo provoca y cómo lo vive el usuario.

Las principales hipótesis que conviene investigar son imágenes de hero sobredimensionadas, vídeos, bibliotecas de terceros, scripts de widgets, fuentes y variantes tipográficas, píxeles de seguimiento, duplicación de librerías y recursos descargados desde páginas que no los necesitan. Estos resultados no demuestran que las imágenes sean siempre la causa: precisamente descartamos el porcentaje de errores de imagen que producía un test con resultados nulos mal interpretados.

Primeras acciones útiles: identificar la cadena crítica desde Chrome Network, ordenar los recursos por bytes transferidos e iniciador, comparar dimensiones físicas y visuales de las imágenes, diferir galerías fuera de pantalla, revisar fuentes y evitar que un mismo script de app se cargue varias veces.

En Shopify conviene mantener la entrega de imágenes en los filtros de la plataforma, que crean srcset, dimensiones estables y variantes del CDN sin componer las URL manualmente. Documentación de Shopify sobre imágenes.

Hallazgo 3. JavaScript y CSS sobrantes: señales muy repetidas, soluciones que requieren pruebas

Las listas de oportunidades derivadas de Lighthouse marcaron JavaScript sin utilizar en 80 de 82 tiendas y CSS sin utilizar en 78 de 82. Son señales muy recurrentes, pero una herramienta que detecta código no ejecutado durante la carga inicial no sabe por sí sola si ese código será imprescindible en el buscador interno, una variante de producto, las suscripciones, el carrito, los métodos de pago o una interacción posterior.

Antes de borrar un script, conviene saber qué app lo inyecta, en qué plantillas se usa, cuál es su contribución comercial, qué eventos de analítica dispara y si debe ejecutarse tras consentimiento. Chrome Coverage es una pista, no autorización para eliminar recursos. Es más seguro aplicar carga por plantilla, inicialización bajo demanda, deduplicación y pruebas de regresión.

Con CSS, el objetivo es priorizar los estilos necesarios para la primera pantalla y evitar transportar hojas completas de secciones que no aparecen en esa URL. También hay que vigilar el coste de Liquid en servidor: bucles anidados, acceso repetido a metafields y bloques innecesarios pueden aumentar el TTFB aunque el JavaScript sea ligero. Buenas prácticas para themes Shopify.

Hallazgo 4. Primer render lento pese a tener etiquetas SEO correctas

56 de 82 tiendas evaluables superaron los tres segundos de FCP y 68 de 82 superaron 5,8 segundos de Speed Index. Ambos son indicadores útiles del contenido visible, aunque no son Core Web Vitals ni factores individuales directos de ranking.

Un FCP alto apunta a investigar respuesta del servidor, estilos críticos, fuentes y scripts del <head>. Un Speed Index alto sugiere que la primera pantalla tarda en volverse visualmente útil. Tener <title>, descripción y H1 no compensa una experiencia donde el producto se muestra demasiado tarde.

Además, 33 de 81 registros mostraron Total Blocking Time superior a 600 ms. TBT mide bloqueos del hilo principal durante una prueba de laboratorio. No debe confundirse con INP, que requiere observar interacciones reales durante la navegación. Para hablar de experiencia real, contrastamos CrUX, Search Console y medición RUM. Definición oficial de Core Web Vitals.

Hallazgo 5. El SEO de la home aprueba más tests, pero no representa todo el sitio

El score SEO de Lighthouse quedó por debajo de 90/100 en 21 de 82 registros evaluables. El sistema señaló ausencia de meta description en 4 de 83 y un problema de canonical en 1 de 83. Estas proporciones no permiten concluir que toda la arquitectura de esos dominios esté bien: se verificó una URL y algunos controles ausentes se trataron por defecto como aprobados.

Un SEO técnico de verdad necesita auditar:

1. Rastreo e indexación: robots.txt, sitemaps, estados HTTP, reglas noindex, enlaces internos HTML, profundidad de rastreo, errores 404 y URL huérfanas.
2. Canonicals y filtros: variantes, URLs por facetas, ordenación, paginación, parámetros, duplicados y aterrizajes comerciales con intención de búsqueda legítima.
3. Metadatos y estructura editorial: títulos y descripciones por plantilla, H1 visible, jerarquía semántica, enlazado contextual y Open Graph para compartidos sociales.
4. Mercados internacionales: rutas por país e idioma, precios regionales, canonical propio, hreflang recíproco únicamente entre páginas equivalentes y enlaces correctos de retorno.
5. Datos estructurados de producto: Product, Offer, disponibilidad, precio, variantes, políticas de envío/devolución, reseñas cuando proceda y correspondencia exacta con el contenido visible.
6. Migraciones y redirecciones: mapeo 301, enlaces antiguos, canonical/hreflang tras cambiar plataforma, manejo de parámetros y seguimiento de Search Console después del cutover.

Google explica cómo resolver estos temas en sus guías de fundamentos técnicos, canonicalización, navegación por facetas y datos estructurados para fichas de comerciantes.

Por qué no publicamos un porcentaje de errores de viewport

Nuestro sistema clasificó muchas URL como si no tuvieran la metaetiqueta viewport; la revisión del código mostró que ese indicador puede dispararse cuando Lighthouse no asigna nota y la petición HTML independiente no trae contenido. Un dato no disponible no significa que falte una etiqueta. Hasta repetir esas comprobaciones en el navegador, el número queda excluido del estudio.

El mismo problema afecta a las alertas de recursos bloqueantes e imágenes: ciertos tests no puntuados se transformaron en notas cero. Presentarlos como errores demostrados de casi todas las marcas sería incorrecto. Su existencia es un hallazgo QA del instrumento de Shugert, no una acusación a las tiendas.

Hallazgo 6. Accesibilidad y estabilidad visual muestran patrones distintos

39 de 82 evaluaciones dieron un score automático de accesibilidad inferior a 90. Es un motivo para revisar semántica, labels, foco visible, navegación por teclado, alternativas textuales, botones, formularios, contraste y tamaños táctiles. Un número de Lighthouse no establece por sí solo cumplimiento o incumplimiento de WCAG; hacen falta pruebas manuales, lectores de pantalla y validación con usuarios.

Por otro lado, 74 de 82 registros aprobaron el rango CLS empleado por la herramienta, mientras que 5 de 82 quedaron en su banda de fallo. No todos los problemas se presentan juntos: puede haber un LCP muy lento y, sin embargo, una composición visual relativamente estable. La prioridad debe seguir a la evidencia, no al color de una hoja de resultados.

Hallazgo 7. GEO, AEO y visibilidad en respuestas de IA: la siguiente investigación

El SEO para sistemas de respuestas generativas también depende de arquitectura técnica, pero ninguna de las primeras 100 auditorías guardadas contenía score AEO, conteos de citas en asistentes, métricas de referrals de IA ni pruebas de presencia en respuestas. Detectar un bloque JSON-LD en la home no significa que las fichas de producto cumplan los requisitos de Google Shopping y tampoco garantiza que ChatGPT u otro asistente cite la marca.

La extensión GEO/AEO que recomendamos sí debería medir HTML renderizado y accesible, identidad de marca, entidades y producto, enlaces rastreables, vigencia de precio y stock, marcado Product/Offer/Organization, descripciones verificables y consistencia de mercados. Después hay que construir un conjunto repetible de preguntas comerciales y no comerciales, registrar respuestas, fechas y URLs citadas, y analizar los referrals cuando sea posible.

De estos primeros datos no se puede afirmar que “el 68 % de las tiendas son invisibles para la IA”. Eso sería inventar una medición. Google sigue explicando el SEO con JavaScript como un flujo distinto de rastreo, renderizado e indexación. Guía oficial de Google sobre JavaScript SEO.

Plan práctico de 90 días: de las mediciones a los cambios

Días 1–15: comprobar los problemas verdaderos

Recopilar en Search Console cobertura, indexación y consultas; descargar CrUX de Core Web Vitals si hay suficiente tráfico; elegir plantillas representativas de home, colección, producto y blog; repetir pruebas móvil/desktop; documentar apps, sitemaps, robots, estados HTTP y HTML que recibe el crawler. Un test sin puntuación debe clasificarse como desconocido, nunca como cero.

Criterio de salida: lista priorizada de plantillas y mercados, medición reproducible, responsable, aceptación y plan de reversión.

Días 16–45: corregir causas, no síntomas

Resolver el cuello de botella dominante del LCP, ajustar descubrimiento y dimensionado de imágenes, distribuir JavaScript y CSS por plantillas, arreglar defectos demostrados de indexación/canonical y validar datos estructurados. Desplegar cambios pequeños con pruebas de carrito, checkout, analítica y accesibilidad.

Criterio de salida: comparativas antes/después sobre los mismos dispositivos/URLs, recorridos de compra correctos, schema validado y sin regresiones SEO.

Días 46–90: demostrar el efecto en campo

Observar percentiles 75 de CrUX y RUM, indexación e impresiones de GSC, páginas de entrada orgánica, conversiones y cambios externos. Mantener lo que funciona y revertir lo que perjudique la compra, el SEO o la accesibilidad.

Criterio de salida: mejora repetible con tamaño de muestra suficiente o una conclusión explícita de “todavía no hay evidencia” en lugar de atribuir ventas ficticias.

Cómo citar correctamente estos datos

Cita válida: «En una muestra de 100 tiendas ecommerce únicas auditadas por Shugert en septiembre de 2026, 73 de los 81 registros con LCP sintético utilizable superaron los cuatro segundos; 18 de las 100 auditorías disponían únicamente de datos de respaldo y no formaron parte de esa proporción».

No respaldado: «El 90 % de Shopify falla Core Web Vitals», «las tiendas pierden 30 % de ventas por su lentitud», «estas marcas tienen schema defectuoso en todo el catálogo» o «la mayoría es invisible a la IA». Serían conclusiones que necesitan otra muestra, más mediciones y validación independiente.

Preguntas frecuentes

¿Basta con tener 100/100 en Lighthouse SEO? No. Es una comprobación inicial, no una auditoría completa de arquitectura, URLs, render, productos, idiomas y SEO internacional.

¿Un LCP lento hace caer posiciones automáticamente? No se puede inferir una penalización directa ni estimar pérdida de tráfico desde una prueba sintética. Los Core Web Vitals forman parte de sistemas de ranking más amplios y requieren datos reales.

¿Son todas tiendas Shopify? No lo podemos confirmar con la evidencia guardada. Son tiendas ecommerce de una campaña orientada al ecosistema Shopify, pero no todas tienen la plataforma identificada.

¿Dónde queda INP? No estaba disponible en estos registros. El TBT sintético es diferente del INP real de usuarios.

¿Debemos fiarnos del score general de Shugert? De las métricas individuales y su calidad de datos, sí, con cautela. Del score global personalizado, no para comparar estas 100 marcas, hasta corregir el tratamiento de pruebas no puntuadas.

¿Cuándo repetir este benchmark? Trimestralmente puede ser útil, siempre que conservemos el mismo criterio de muestra, URL, dispositivos, fecha y definiciones.

Apéndice: inventario completo de señales y comprobaciones excluidas

Esta tabla evita uno de los errores más frecuentes en auditoría automatizada: ocultar datos que no coinciden con el titular o transformar información ausente en ceros. Son estados registrados por nuestro sistema, no defectos confirmados manualmente.

Pueden coexistir metadatos básicos bien configurados y una experiencia inicial lenta. El SEO técnico no debe equiparar la presencia de etiquetas con buena salud de todo el sitio ni asumir que una prueba sintética lenta prueba una caída de posiciones o ventas.

De la auditoría al cambio desplegado: cómo ayuda Shugert

Una buena auditoría no termina en un inventario de alertas rojas. Debe responder qué se cambia, por qué, dónde, quién valida el resultado, cómo se despliega sin romper checkout y qué condiciones justifican revertirlo.

Shugert es Shopify Partner desde 2015 y combina SEO técnico, ingeniería de rendimiento, CRO y desarrollo. Si tus productos tardan en mostrarse, tus colecciones compiten en Google, o una migración debilitó el tráfico orgánico, podemos plantear un proyecto acotado CRO & Technical SEO Fix, con QA y control de despliegue.

Conoce nuestro servicio de SEO técnico Shopify · Optimización de rendimiento en Shopify · Solicitar un scope

Fuentes principales y transparencia

• Datos propios: registros audit_runs de Shugert, primeros 100 hostnames únicos del lote de prospección en inglés ordenados por fecha de primera auditoría, 28 de septiembre de 2026. Los extractos agregados y la metodología acompañan el paquete editorial; no divulgamos contactos de los prospectos.
• Google: Core Web Vitals y umbrales de campo.
• Shopify: buenas prácticas de rendimiento.
• Lighthouse: interpretación de pruebas con puntuación nula.
• Google: fundamentos técnicos para desarrolladores.
• Google: datos estructurados de comercio electrónico.
• Google: SEO y JavaScript.

Nota editorial: los nombres de marcas aluden exclusivamente a la observación de escaparates públicos; no implican relación comercial ni respaldo. El estudio es puntual, sintético y no representativo del conjunto del mercado. No deben atribuirse problemas individuales a una marca sin nuevas comprobaciones.