SEO técnico y experiencia de usuario: cómo convertir tu web en un activo comercial

Tabla de contenidos

• Tres preguntas, tres capas
• Rastreo e indexación: lo que debe estar bien antes de cualquier otra cosa
• Canónicos y duplicados: guiar a Google, no ordenarle
• Datos estructurados: describir lo que ya está en la página
• Core Web Vitals: los umbrales vigentes
• Cómo comprobar tu situación sin ser técnico
• Accesibilidad: el estándar es WCAG 2.2
• Del SEO técnico a la conversión: qué evidencia hay
• Cómo priorizar: impacto en negocio por esfuerzo
• El siguiente paso

El SEO técnico y la experiencia de usuario se tratan a menudo como proyectos distintos, con equipos y presupuestos separados. Es un error de organización, no de concepto. Los dos responden a la misma pregunta: ¿puede la persona correcta encontrar tu web y hacer en ella lo que necesita? El SEO técnico asegura que los buscadores puedan rastrear, entender e indexar tus páginas. La experiencia de usuario asegura que, al llegar, la página cargue, responda, no estorbe y sea utilizable por cualquiera.

Nuestra tesis: una web es un activo comercial cuando cumple las dos condiciones a la vez, y se mide por lo que produce para el negocio, no por una puntuación. Una web rápida que Google no puede indexar no vende. Una web perfectamente indexada que se bloquea en el móvil o que una persona con discapacidad no puede usar, tampoco.

Dos advertencias de partida, porque el mercado vende este tema con más certeza de la que existe. Primero, Google afirma que los Core Web Vitals son utilizados por sus sistemas de ranking, pero que unas buenas puntuaciones no garantizan posicionarse arriba. Segundo, la evidencia pública sobre cómo la velocidad afecta a la conversión procede de casos de empresas concretas: sirve para orientar, no para predecir tu resultado. Este artículo trabaja con lo que está documentado y marca dónde acaba.

El diseño de la estructura de contenidos del sitio (jerarquía de temas, enlazado interno, clústeres) lo tratamos en arquitectura de contenidos para la visibilidad y no lo repetimos aquí. Este artículo se ocupa de la base técnica y de usabilidad sobre la que esa arquitectura funciona.

Tres preguntas, tres capas

Rastreo e indexación: lo que debe estar bien antes de cualquier otra cosa

Los enlaces deben ser enlaces. La documentación de Google sobre JavaScript explica que Google rastrea, renderiza e indexa en fases, y que solo puede descubrir enlaces que sean elementos <a> con atributo href. Los menús o botones que navegan mediante eventos de JavaScript sin un href real pueden dejar páginas sin descubrir. Para aplicaciones de una sola página, Google recomienda usar la History API en lugar de fragmentos en la URL.

Robots.txt controla el acceso, no la indexación. Según Google, robots.txt se usa principalmente para no sobrecargar el sitio con solicitudes y no es un mecanismo para mantener una página fuera de Google; para eso, se usa noindex o protección por contraseña. El error clásico es doble: bloquear con robots.txt lo que se quería excluir (la página puede seguir apareciendo si otros sitios la enlazan) y dejar un noindex olvidado de la fase de desarrollo en páginas que sí deben indexarse.

La versión móvil es la que cuenta. Google usa la versión móvil del contenido, rastreada con su agente de smartphone, para indexar y clasificar. Si tu versión móvil tiene menos contenido que la de escritorio, ese contenido puede no contar. Los títulos, las metadescripciones y los datos estructurados deben coincidir en ambas versiones. Google considera el diseño adaptable (responsive) el patrón más sencillo de implementar y mantener.

Errores que cuestan clientes:

• Páginas de servicio con noindex heredado de una plantilla de pruebas.
• Menús que dependen de JavaScript sin enlaces reales, que ocultan secciones enteras al rastreo.
• Contenido clave solo en la versión de escritorio.
• Una migración o rediseño que cambia URLs sin redirecciones, y que borra de golpe el historial que esas URLs habían acumulado.

Canónicos y duplicados: guiar a Google, no ordenarle

Cuando varias URLs muestran el mismo contenido (con parámetros, con y sin barra final, versiones http y https), Google elige una versión canónica. Su documentación enumera las señales por orden de fuerza: las redirecciones son una señal fuerte, rel="canonical" también es una señal fuerte, y la inclusión en el sitemap es una señal débil. Pueden combinarse. Importa un matiz: ninguna es obligatoria, y Google puede decidir por su cuenta.

La consecuencia práctica es coherencia. Un canónico que apunta a una URL distinta de la que enlazas y declaras en el sitemap envía señales contradictorias. La regla es que el enlace interno, el sitemap, el canónico y la redirección apunten todos a la misma URL preferida.

Datos estructurados: describir lo que ya está en la página

Los datos estructurados ayudan a Google a entender el contenido y pueden habilitar funciones de aspecto en los resultados. Las directrices de Google fijan límites claros:

• Solo contenido visible. No se marca lo que el lector no ve en la página.
• JSON-LD es el formato preferido de Google.
• Sin garantías. Google no garantiza que los datos estructurados se muestren en los resultados, aunque el marcado sea correcto.
• Riesgo de acción manual. Un marcado engañoso puede suponer una acción manual que elimina la elegibilidad para resultados enriquecidos, sin afectar al ranking normal.

El criterio de uso en un sitio de negocio: marca lo que existe (organización, datos de contacto, migas de pan, productos reales) y valida el resultado antes de publicar. No marques opiniones que no están en la página ni inventes valoraciones. Para negocios con presencia local, la guía de marketing para negocios locales trata los datos LocalBusiness.

Core Web Vitals: los umbrales vigentes

Los Core Web Vitals miden tres aspectos de la experiencia real. Estos son los umbrales que publica web.dev, evaluados en el percentil 75 de las cargas de página y segmentados por móvil y escritorio.

Cuatro puntos para usarlos bien.

Datos de campo frente a datos de laboratorio. Los datos de laboratorio se obtienen cargando la página en un entorno controlado; los de campo vienen de usuarios reales. web.dev señala que los datos de campo, que las herramientas de Chrome obtienen del Chrome User Experience Report (CrUX) a lo largo de 28 días, son los que conviene usar para priorizar y los que sirven en la evaluación de Core Web Vitals. Una puntuación perfecta de laboratorio con malos datos de campo es un problema real.

Qué relación tienen con el ranking. Google dice que los Core Web Vitals son utilizados por sus sistemas de ranking, y a la vez que “busca mostrar el contenido más relevante, incluso si la experiencia de página no es óptima”. Es decir: no son un atajo para superar a un competidor con mejor contenido, pero una mala experiencia es una desventaja que no compensa gratis.

Se miden por plantilla, no por sitio. Una web tiene familias de páginas (inicio, servicio, artículo, ficha, formulario). Prioriza las que concentran las visitas y las acciones comerciales, no la media del dominio.

Las causas típicas son conocidas. Imágenes pesadas o mal dimensionadas en el elemento principal (LCP), scripts de terceros y tareas largas de JavaScript (INP), imágenes, anuncios o banners sin espacio reservado (CLS). El diagnóstico por página con datos de campo evita optimizar a ciegas.

Cómo comprobar tu situación sin ser técnico

Tres herramientas gratuitas de Google responden a las preguntas básicas, con límites que conviene conocer.

• Informe de indexación de páginas (Search Console). Muestra cuántas páginas están indexadas y por qué otras no lo están (noindex, bloqueo por robots.txt, duplicadas, errores del servidor). Google aclara que no hay que esperar que todas las URL estén indexadas, solo las canónicas: lo que importa es que lo estén tus páginas comerciales.
• Informe de Core Web Vitals (Search Console). Usa datos de campo del Chrome User Experience Report, separados por móvil y escritorio y agrupados por URL. Solo incluye URL indexadas y omite las que no tienen un mínimo de datos, así que un sitio con poco tráfico puede no aparecer.
• PageSpeed Insights. Combina datos de campo (los de los 28 días anteriores) con datos de laboratorio de Lighthouse. Según Google, los de laboratorio sirven para depurar, pero pueden no reflejar los cuellos de botella reales.

Accesibilidad: el estándar es WCAG 2.2

La accesibilidad no es un añadido para un público marginal: determina si todas las personas, incluidas las que usan lector de pantalla, teclado, ampliación o tienen limitaciones motrices, pueden leer tu web y completar una acción. Y muchos de sus requisitos coinciden con lo que mejora la conversión para todos.

El estándar de referencia es WCAG 2.2, publicado como Recomendación del W3C el 12 de diciembre de 2024, con niveles de conformidad A, AA y AAA. WCAG 2.2 añade nueve criterios de éxito, entre ellos algunos con impacto directo en sitios comerciales:

• Tamaño del objetivo (mínimo), 2.5.8, nivel AA: los elementos táctiles no deben ser tan pequeños que sea difícil pulsarlos.
• Foco no oculto (mínimo), 2.4.11, nivel AA: el elemento enfocado con el teclado no debe quedar tapado, por ejemplo, por un banner fijo.
• Movimientos de arrastre, 2.5.7, nivel AA: debe existir una alternativa a arrastrar.
• Autenticación accesible (mínimo), 3.3.8, nivel AA: no obligar a recordar o transcribir para iniciar sesión.
• Entrada redundante, 3.3.7, nivel A: no pedir dos veces la misma información en un mismo proceso.
• Ayuda coherente, 3.2.6, nivel A: la ayuda aparece en el mismo lugar en cada página.

WCAG 2.2 también elimina el criterio 4.1.1 (Análisis sintáctico), que quedó obsoleto. El W3C señala que el contenido que cumple WCAG 2.2 cumple también WCAG 2.0 y 2.1, y recomienda aplicar la 2.2 aunque la normativa de tu país cite una versión anterior.

Cómo está la web real. El informe WebAIM Million 2026, que analizó automáticamente en febrero de 2026 las páginas de inicio de un millón de sitios, detectó fallos de WCAG 2 en el 95,9% de ellas, con un promedio de 56,1 errores por página. Los más frecuentes fueron texto con contraste bajo (83,9%), imágenes sin texto alternativo (53,1%) y campos de formulario sin etiqueta (51%). El promedio de 2025 había sido de 51 errores por página (un aumento del 10,1%). Las páginas con atributos ARIA tuvieron más errores de media (59,1) que las que no los usaban (42): es una asociación, no prueba que ARIA cause errores. WebAIM subraya que la detección automática no demuestra que una página sea accesible: la conformidad real es probablemente menor. Lo útil para un negocio es que varios de los fallos más comunes (contraste, formularios sin etiquetas, enlaces y botones vacíos) afectan justo a los botones, formularios y llamadas a la acción que producen clientes.

El caso de negocio, con cautela. El W3C recoge en su caso de negocio beneficios como ampliar el alcance de mercado, mejorar la marca y reducir el riesgo legal, con enlaces a estudios y a casos judiciales. Es un argumento razonable, pero no una promesa de conversión. En cuanto a obligaciones legales, varían por país y sector: consulta con asesoría legal qué normativa se aplica a tu actividad.

Del SEO técnico a la conversión: qué evidencia hay

Aquí la prudencia importa más que en cualquier otra sección. Dos estudios publicados por web.dev, ambos de grandes empresas:

• Vodafone, 2021. En una prueba A/B sobre una página de destino que repartió a partes iguales el tráfico de pago entre una versión optimizada y otra de referencia, sin otras diferencias visuales o funcionales, la versión optimizada tuvo un LCP un 31% mejor en datos de campo y generó un 8% más de ventas, un 15% de mejora en la tasa de visita a lead y un 11% en la de carrito a visita.
• Renault. Un análisis de correlación (no una prueba A/B) con más de 10 millones de visitas a páginas de destino en 33 países, entre diciembre de 2020 y marzo de 2021, estimó mediante regresiones lineales que una mejora de 1 segundo en el LCP puede asociarse a 14 puntos porcentuales menos de rebote (en páginas con LCP inferior a 1,6 s; unos 5 puntos por encima de ese valor) y a un 13% más de conversiones, entendidas como formularios de contacto completados.

Cómo leerlos. El de Vodafone es un experimento controlado, la prueba más sólida de las dos, pero es un único caso de una empresa grande, con una página concreta y un tráfico concreto. El de Renault es una correlación: las páginas rápidas pueden diferir de las lentas en otros aspectos. Ninguno demuestra que tu web recibirá ese efecto. Lo que sí respaldan es una hipótesis razonable: en páginas con mucho tráfico y mala experiencia, mejorarla puede aumentar la conversión.

Cómo comprobarlo en tu caso. Compara la conversión de tus páginas de mayor tráfico con su rendimiento en datos de campo. Si las páginas con LCP o INP deficientes convierten claramente peor para un mismo tipo de tráfico, hay una hipótesis que merece una prueba. Si no hay diferencia, el cuello de botella está en otra parte, y el diagnóstico de por qué tu web recibe visitas pero no genera clientes te ayuda a encontrarlo. Para estructurar el análisis de conversión en un sitio B2B, consulta CRO: qué es y cómo aplicarlo.

Cómo priorizar: impacto en negocio por esfuerzo

La lista de mejoras técnicas posibles es casi infinita; el presupuesto no. Un orden que recomendamos en Maccam Network:

1. Bloqueos de acceso a páginas comerciales. noindex por error, robots.txt mal configurado, enlaces no rastreables, canónicos erróneos. Es lo más barato de corregir y lo que más puede costar.
2. Funcionamiento de las vías de contacto. Formularios que envían, teléfonos que se pueden pulsar, mensajes que llegan. Se comprueba con pruebas reales, no con herramientas.
3. Experiencia en las plantillas clave. Core Web Vitals en las familias de página que concentran visitas y acciones, con datos de campo.
4. Accesibilidad en los puntos de conversión. Contraste, etiquetas, tamaño de objetivos y foco en formularios, botones y menús.
5. Datos estructurados y mejoras de detalle. Útiles y de bajo riesgo, pero rara vez la primera palanca.
6. Gobierno continuo. Un sitio se degrada con cada cambio de contenido, plugin o script de terceros. Un responsable que revise regularmente los indicadores evita descubrir los problemas por la caída de resultados.

Qué no hacer. Perseguir el 100 de una herramienta en lugar de las métricas de campo; optimizar una página de poco tráfico mientras la de contacto falla; añadir scripts de terceros sin medir su coste; o esperar que un cambio técnico compense un mensaje o una oferta débiles, que son otra capa distinta.

El siguiente paso

Una auditoría técnica útil no entrega una lista de cien avisos, sino un orden de trabajo vinculado a páginas y resultados de negocio. En Maccam Network la integramos en nuestro trabajo de desarrollo web y de SEO, y puedes conocer el enfoque en la metodología de SEO. Si quieres hablar de tu sitio, escríbenos.

Fuentes verificadas a 9 de octubre de 2026. No hemos verificado obligaciones legales de accesibilidad (varían por país y sector) ni las cifras de casos de terceros distintos de los dos de web.dev citados.

Fuentes

• web.dev (Google), “Web Vitals”: web.dev/…/vitals
• web.dev, “Largest Contentful Paint (LCP)”: web.dev/…/lcp
• web.dev, “Interaction to Next Paint (INP)”: web.dev/…/inp
• web.dev, “Cumulative Layout Shift (CLS)”: web.dev/…/cls
• web.dev, “Lab and field data differences”: web.dev/…/lab-and-field-data-differences
• Ayuda de Search Console, “Informe de Core Web Vitals”: support.google.com/…/9205520
• Ayuda de Search Console, “Informe de indexación de páginas”: support.google.com/…/7440203
• Google, “About PageSpeed Insights”: developers.google.com/…/about
• Google Search Central, “Understanding page experience in Google Search” (actualizado el 22 de septiembre de 2026): developers.google.com/…/page-experience
• Google Search Central, “What is canonicalization / Consolidate duplicate URLs” (actualizado el 10 de julio de 2026): developers.google.com/…/consolidate-duplicate-urls
• Google Search Central, “Introduction to robots.txt” (actualizado el 10 de diciembre de 2025): developers.google.com/…/intro
• Google Search Central, “JavaScript SEO basics” (actualizado el 4 de marzo de 2026): developers.google.com/…/javascript-seo-basics
• Google Search Central, “Mobile-first indexing best practices”: developers.google.com/…/mobile-sites-mobile-first-in…
• Google Search Central, “General structured data guidelines”: developers.google.com/…/sd-policies
• W3C, “Web Content Accessibility Guidelines (WCAG) 2.2” (Recomendación del W3C, 12 de diciembre de 2024): w3.org/…/WCAG22
• W3C WAI, “The Business Case for Digital Accessibility”: w3.org/…/business-case
• WebAIM, “The WebAIM Million” (informe 2026): webaim.org/…/million
• web.dev, “Vodafone: A 31% improvement in LCP increased sales by 8%” (17 de marzo de 2021): web.dev/…/vodafone
• web.dev, “How Renault improved its bounce and conversion rates by measuring and optimizing Largest Contentful Paint”: web.dev/…/renault