SEO técnico: la guía definitiva para que Google entienda tu web

02 noviembre, 2026

El SEO técnico es el conjunto de ajustes que permiten a Google rastrear, renderizar, entender e indexar tu web sin obstáculos: robots.txt, sitemap, canonicals, redirecciones, velocidad, versión móvil, HTTPS, datos estructurados y arquitectura. No te hace ganar posiciones por sí solo, pero si falla, el mejor contenido se queda fuera de los resultados.

 

Llevo desde 2010 auditando webs y tiendas online, y casi siempre empiezo por aquí, porque es donde se esconden los problemas que nadie ve. En esta guía te explico qué revisar, con qué herramientas y en qué orden.

 

Qué es el SEO técnico y por qué va antes que todo lo demás

 

Si el SEO on-page trata de lo que dices en cada página y el linkbuilding de quién habla de ti, el SEO técnico trata de algo más básico: que Google pueda llegar a tus páginas, leerlas bien y decidir que merecen estar en su índice. Cualquier buscador sigue cuatro pasos:

 

1. Descubrimiento: encuentra tus URLs a través de enlaces y del sitemap.
2. Rastreo: Googlebot descarga la página, salvo que algo se lo impida (robots.txt, errores de servidor, lentitud).
3. Renderizado: ejecuta el JavaScript y monta la página como la vería un usuario.
4. Indexación: analiza el contenido, elige la URL canónica entre posibles duplicados y decide si la guarda.

 

Solo después entra en juego el posicionamiento. Por eso el SEO técnico es condición necesaria, pero no suficiente.

 

Rastreo e indexación: lo primero que reviso

 

La pregunta con la que abro cualquier auditoría es sencilla: ¿las páginas que importan están indexadas y las que no importan están fuera? En la mayoría de pymes y tiendas que reviso, la respuesta es "no del todo". Suele haber páginas útiles sin indexar y, a la vez, cientos de URLs basura (filtros, parámetros, búsquedas internas) ocupando al rastreador.

 

El informe de indexación de páginas de Search Console

 

Es la herramienta de diagnóstico más importante y es gratuita. Te dice cuántas URLs están indexadas y, sobre todo, por qué las demás no. Los motivos que más encuentro: "Descubierta: actualmente sin indexar", "Rastreada: actualmente sin indexar", "Duplicada: Google ha elegido una canónica diferente", "Excluida por la etiqueta noindex", "Bloqueada por robots.txt" y "Soft 404". No todos son errores: que una URL con canonical hacia otra no se indexe es justo lo que quieres.

 

Presupuesto de rastreo: cuándo debe preocuparte

 

Google aclara que su guía sobre presupuesto de rastreo está pensada para casos avanzados: webs con más de un millón de páginas que cambian cada semana, con más de 10.000 páginas que cambian a diario o con muchas URLs en "Descubierta: actualmente sin indexar". En una tienda con unos cientos de productos, el problema casi nunca es el presupuesto, sino la duplicidad y la calidad.

 

noindex: la forma correcta de sacar páginas del índice

 

Para que una página no aparezca en Google se usa la meta robots con noindex en el <head> o la cabecera HTTP X-Robots-Tag (útil para PDFs). El error que más veo: bloquear esa misma página en robots.txt. Si Googlebot no puede rastrearla, no lee el noindex, y la URL puede seguir apareciendo si otras páginas la enlazan.

 

Robots.txt: qué hace y qué no hace

 

El robots.txt es un archivo en la raíz del dominio (tudominio.com/robots.txt) que indica a los rastreadores a qué URLs pueden acceder. Según la documentación oficial de Google sobre robots.txt, sirve para gestionar el tráfico de rastreo y no sobrecargar el servidor, pero no para ocultar páginas: una URL bloqueada puede indexarse igualmente, sin descripción, si recibe enlaces.

 

En una tienda online lo normal es bloquear carrito, checkout, cuenta de cliente, búsquedas internas y ciertas combinaciones de filtros, con líneas como "Disallow: /cart" o "Disallow: /search", y añadir al final la línea "Sitemap:" con la URL completa del sitemap. Tres advertencias:

 

• No bloquees CSS ni JavaScript necesarios. Google indica que, si sin ellos le cuesta entender la página, no podrá analizarla bien.
• No uses robots.txt para resolver duplicados. Para eso está el canonical.
• Vigila el "Disallow: /" heredado del entorno de pruebas. Es la causa clásica de una web nueva que no aparece en Google semanas después de publicarse.

 

En Shopify, la plataforma genera un robots.txt por defecto que funciona en la mayoría de casos. Se puede personalizar con la plantilla robots.txt.liquid, pero Shopify recomienda guardar antes una copia del archivo actual y usar sus objetos Liquid en lugar de reescribirlo entero. Lo desarrollo en la guía de SEO en Shopify.

 

Sitemap XML: el mapa que le das a Google

 

El sitemap es un archivo XML con las URLs que quieres que Google conozca. No garantiza que las rastree ni las indexe, pero ayuda a descubrirlas, sobre todo en webs grandes, nuevas o con enlazado interno débil. Los datos clave, según la guía de Google para crear y enviar un sitemap:

 

• Cada sitemap admite como máximo 50.000 URLs o 50 MB sin comprimir. Si tienes más, se divide y se agrupa en un índice de sitemaps.
• Google ignora las etiquetas priority y changefreq.
• lastmod sí se usa, pero solo si las fechas son coherentes y verificables, y debe reflejar cambios significativos, no la actualización del año del pie de página.
• Se envía desde el informe de sitemaps de Search Console o con la línea "Sitemap:" del robots.txt.

 

Mi regla: en el sitemap solo van URLs canónicas, indexables y que devuelven 200. Incluir URLs con noindex, redirigidas o canonicalizadas hacia otra página es mandar señales contradictorias, algo muy habitual con plugins que generan el sitemap sin filtrar.

 

Canonical y contenido duplicado

 

El contenido duplicado técnico es el problema que más encuentro en tiendas online. No hablo de copiar textos, sino de la misma página accesible desde varias URLs: con y sin barra final, con parámetros de seguimiento o de ordenación, en http y https, con y sin www, o un producto que cuelga de varias colecciones. Google acaba eligiendo una como canónica, y no siempre la que tú querrías.

 

Google describe tres métodos para indicar la URL preferida, de más a menos fuerza:

 

1. Redirecciones permanentes: señal fuerte, para URLs duplicadas que ya no deben existir.
2. rel="canonical": señal fuerte, en el <head> o como cabecera HTTP. Elige una de las dos vías.
3. Inclusión en el sitemap: señal débil, pero suma.

 

Las buenas prácticas oficiales: canonical autorreferente en cada página canónica, URLs absolutas, enlazado interno siempre hacia la versión canónica, no usar noindex para elegir canónica dentro del sitio y no canonicalizar con robots.txt. Y un matiz clave: el canonical es una preferencia, no una orden. Si tus enlaces internos, sitemap y redirecciones apuntan en otra dirección, Google puede elegir otra URL. La coherencia entre señales es lo que hace que te haga caso.

 

Redirecciones 301 y 302, errores 404 y soft 404

 

Permanentes frente a temporales

 

Google trata como permanentes los códigos 301 y 308 (y el meta refresh instantáneo), y como temporales los 302, 303 y 307. Con una permanente interpreta que el destino debe ser la URL canónica; con una temporal, la URL original suele mantenerse en resultados. La documentación de Google sobre redirecciones recomienda redirecciones permanentes del lado del servidor siempre que sea posible, y dejar las de JavaScript como último recurso, porque si el renderizado falla Google puede no verlas.

 

La 301 es para cambios definitivos: rediseños, cambios de URL, fusión de productos o migración de dominio. La 302, para situaciones de verdad temporales. Dos errores frecuentes: usar 302 por defecto en cambios definitivos (muchos CMS y apps lo hacen) y encadenar redirecciones. Googlebot sigue hasta 10 saltos, pero cada salto es tiempo de carga y un punto más donde algo se rompe. Si A va a B y B a C, haz que A vaya directa a C y actualiza los enlaces internos al destino final.

 

Errores 404, soft 404 y 5xx

 

Un 404 es la respuesta correcta cuando una página no existe y no tiene sustituta razonable. Google no indexa URLs con 4xx y retira las que ya lo estaban. El problema real son las páginas que tenían tráfico o enlaces externos y ahora dan 404 sin redirección, y los enlaces internos rotos. Ahí hay que redirigir a la alternativa más cercana (producto sustituto, categoría madre), nunca todo a la home de forma masiva.

 

Un soft 404 es una página que muestra un error o está casi vacía, pero devuelve código 200: categorías sin productos o fichas agotadas convertidas en páginas en blanco. Search Console las señala; la solución es devolver un 404 real, redirigir o darle contenido útil. Y ojo con los errores 5xx: Google explica que estos y el código 429 hacen que reduzca temporalmente el rastreo. Un hosting que se cae en picos de tráfico es un problema de infraestructura que el SEO sufre directamente.

 

Core Web Vitals: LCP, INP y CLS con sus umbrales oficiales

 

Las Core Web Vitals son las tres métricas con las que Google mide la experiencia real de carga, respuesta y estabilidad visual. Desde el 12 de marzo de 2024, INP (Interaction to Next Paint) sustituyó a FID como métrica de interactividad. Si alguien te sigue hablando de FID, su información está desfasada.

 

Métrica	Qué mide	Bueno	Necesita mejorar	Deficiente
LCP (Largest Contentful Paint)	Carga: cuándo se pinta el elemento principal visible	Hasta 2,5 s	2,5 - 4 s	Más de 4 s
INP (Interaction to Next Paint)	Respuesta a clics, toques y teclado	Hasta 200 ms	200 - 500 ms	Más de 500 ms
CLS (Cumulative Layout Shift)	Estabilidad visual: cuánto "salta" el contenido al cargar	Hasta 0,1	0,1 - 0,25	Más de 0,25

 

Umbrales según la documentación oficial de PageSpeed Insights. Un matiz que pocos explican: se evalúan en el percentil 75 de las visitas reales. Para aprobar, al menos tres de cada cuatro cargas deben estar en "bueno"; no basta con que vaya rápida en tu ordenador con fibra.

 

Cuánto pesan en el posicionamiento

 

Google confirma en su guía sobre Core Web Vitals que sus sistemas de clasificación las usan, pero también que unas buenas puntuaciones no garantizan las primeras posiciones y que la relevancia pesa más. Mi lectura: no obsesionarse con el 100 en PageSpeed, pero sí salir del rojo, porque donde más se nota una web lenta es en la conversión.

 

Lo que más suele estropear cada métrica

 

• LCP: imagen principal pesada o cargada en diferido, servidor lento, fuentes y CSS que bloquean el renderizado.
• INP: exceso de JavaScript, sobre todo de terceros (chats, pop-ups, píxeles, widgets de reseñas).
• CLS: imágenes sin dimensiones, banners que empujan el contenido, fuentes que cambian el tamaño del texto al cargar.

 

En tiendas online el patrón más común es la acumulación de apps: cada una añade su JavaScript y, con los años, la tienda arrastra scripts de herramientas que ya ni se usan. Limpiar eso suele dar más mejora que cualquier ajuste fino, y es parte del trabajo continuo del servicio de optimización constante de eCommerce, donde velocidad, conversión y SEO van juntos.

 

Mobile-first: Google ve primero tu versión móvil

 

Google indexa y clasifica usando la versión móvil del contenido, rastreada con su agente de smartphone. Consecuencia práctica: si algo no está en tu versión móvil, para Google es como si no existiera. Sus recomendaciones se resumen en:

 

• Diseño responsive (mismo HTML en la misma URL para todos los dispositivos), la opción que Google recomienda.
• Mismo contenido principal, encabezados, datos estructurados, meta robots, títulos y meta descripciones en móvil y escritorio. Puedes usar pestañas o acordeones, pero no eliminar contenido.
• No cargar en diferido contenido principal que dependa de una interacción del usuario.
• Evitar anuncios e intersticiales que tapen el contenido.

 

El fallo más común que encuentro: plantillas que en móvil ocultan textos de categoría o enlaces del menú para "limpiar" la vista. Se gana estética y se pierde contenido indexable.

 

HTTPS: imprescindible, no opcional

 

Google anunció en agosto de 2014 que usaba HTTPS como señal de posicionamiento, y hoy sigue dentro de lo que evalúa como experiencia de página, con un informe propio en Search Console. Y el navegador marca como "no seguro" cualquier web en http. No basta con tener certificado:

 

• Todas las versiones (http, https, con y sin www) deben redirigir con 301 a una única versión.
• Sin contenido mixto: nada de imágenes o scripts por http dentro de páginas https.
• Canonicals, sitemap y enlaces internos apuntando a https.
• Certificado válido y con renovación automática.

 

Datos estructurados: decirle a Google qué es cada cosa

 

Los datos estructurados describen de forma explícita el contenido: esto es un producto, con este precio y esta disponibilidad; esto es un artículo, con este autor y esta fecha. Google admite JSON-LD, Microdata y RDFa, y recomienda JSON-LD siempre que tu sistema lo permita. Los tipos que más aplico son Product (con Offer y valoraciones reales si las hay), BreadcrumbList, Organization o LocalBusiness, Article y VideoObject. Dos reglas básicas:

 

• Google no garantiza los resultados enriquecidos, aunque el marcado sea válido. Cumplir los requisitos te hace elegible, nada más.
• No marques contenido que el usuario no ve. Si el marcado dice que hay valoraciones, deben estar visibles.

 

Valídalo con la prueba de resultados enriquecidos y vigila los informes de mejoras de Search Console: un cambio de plantilla puede romper el marcado sin que nadie lo note. Además, ayuda a que los sistemas de IA de los buscadores interpreten bien tu información, algo que trato en la guía de SEO e inteligencia artificial.

 

Arquitectura web y estructura de URLs

 

Una buena arquitectura deja las páginas importantes a pocos clics de la home y hace evidente la jerarquía del sitio. Mis criterios básicos: estructura plana (home, categorías, subcategorías, productos o artículos), migas de pan con su marcado, enlazado interno contextual entre páginas relacionadas y ninguna página importante huérfana.

 

Sobre las URLs, las recomendaciones de Google son sencillas: palabras descriptivas en lugar de identificadores numéricos, guiones en lugar de guiones bajos, eliminar parámetros que no cambian el contenido, mayúsculas y minúsculas coherentes (para Google /Zapatos y /zapatos son URLs distintas) y no usar fragmentos con almohadilla para cambiar el contenido.

 

La navegación facetada de las tiendas (talla, color, precio, marca) merece atención especial: con unos pocos filtros salen miles de combinaciones. Hay que decidir cuáles tienen búsquedas reales y merecen ser página indexable con contenido propio, y cuáles quedan fuera mediante canonical, noindex o bloqueo de rastreo. Lo detallo en la guía de SEO para eCommerce.

 

JavaScript y SEO: lo que Google ve y lo que no

 

Google procesa las páginas con JavaScript en tres fases: rastreo, renderizado e indexación. Las páginas con código 200 pasan a una cola de renderizado, un Chromium sin interfaz ejecuta el JavaScript y Google indexa el HTML resultante. Lo esencial según la guía de Google:

 

• Los enlaces deben ser elementos <a> con href. Botones o divs con eventos de clic no sirven para descubrir URLs.
• El renderizado en servidor o el prerenderizado siguen siendo recomendables: más velocidad y no todos los bots ejecutan JavaScript.
• Canonical en el HTML original y, si el JavaScript lo toca, que coincida.
• Nada de noindex en el código inicial si quieres indexar: Google puede saltarse el renderizado al verlo, así que quitarlo luego con JavaScript puede no funcionar.
• API History, no almohadillas, para la navegación en aplicaciones de una sola página.

 

Mi prueba rápida: desactivar JavaScript en el navegador y ver qué queda. Si desaparecen el texto principal, los productos o la navegación, compruebo con la inspección de URLs de Search Console qué HTML renderizado está viendo Google.

 

Hreflang: webs en varios idiomas o países

 

Si tu web tiene versiones para distintos idiomas o países, hreflang indica a Google cuál mostrar a cada usuario. Es de las implementaciones que más veo mal hechas. Las reglas de la documentación de Google sobre versiones localizadas:

 

• Se implementa con etiquetas link en el HTML, cabeceras HTTP o en el sitemap. Las tres valen igual; elige una.
• Cada versión debe enlazarse a sí misma y a todas las demás. Sin enlaces de vuelta, Google ignora las anotaciones.
• URLs completas, con protocolo y dominio.
• Idioma en ISO 639-1 y, opcionalmente, región en ISO 3166-1 Alfa-2: "es-ES", "es-MX", "en-GB". Un código de país solo no es válido, y para Reino Unido es "GB", no "UK".
• Una versión x-default como opción por defecto para idiomas no cubiertos.

 

Y el canonical de cada versión debe apuntar a una página del mismo idioma; si todas canonicalizan hacia la española, anulas el hreflang.

 

Cómo hacer una auditoría de SEO técnico paso a paso

 

Para una primera auditoría seria bastan tres herramientas. Este es el orden que sigo:

 

1. Google Search Console: lo que Google ve de verdad

 

Son datos del propio Google, no estimaciones. Reviso el informe de indexación de páginas, el de sitemaps, el de Core Web Vitals (qué grupos de URLs están en rojo con datos reales), el de HTTPS, los de mejoras de datos estructurados y la inspección de URLs para páginas concretas: si están indexadas, qué canonical ha elegido Google y cómo ve el HTML renderizado.

 

2. Screaming Frog: rastrear la web como lo haría Google

 

Screaming Frog SEO Spider recorre tu web siguiendo enlaces y te devuelve cada URL con su código de estado, título, meta descripción, canonical, directivas robots, profundidad y enlaces entrantes. La versión gratuita rastrea hasta 500 URLs, suficiente para muchas webs de pymes; para tiendas grandes hace falta la licencia anual. Con un rastreo detecto en minutos:

 

• Enlaces internos rotos y redirecciones encadenadas o en bucle.
• Canonicals ausentes o que apuntan a URLs que redirigen o dan error.
• Títulos y meta descripciones duplicados o vacíos.
• noindex donde no debería haberlo, y al revés.
• Páginas demasiado profundas y diferencias entre sitemap y rastreo real.

 

3. PageSpeed Insights: datos reales y de laboratorio

 

Conviene no confundir sus dos tipos de datos. Los datos de campo vienen del Chrome User Experience Report: usuarios reales de los últimos 28 días, evaluados en el percentil 75. Son los que cuentan para las Core Web Vitals. Los datos de laboratorio vienen de Lighthouse, una simulación de una sola carga, y sirven para diagnosticar. El laboratorio te dice dónde mirar; el campo, cómo lo vive tu cliente. Analizo siempre en móvil la home, una categoría, una ficha de producto y un artículo, porque lo que arreglas en una plantilla se arregla en cientos de páginas.

 

4. Cruzar datos y priorizar

 

Cualquier herramienta genera una lista de errores; el valor está en decidir qué arreglar primero. Yo cruzo qué páginas importan por tráfico o negocio, qué les impide rendir y cuánto cuesta arreglarlo. Si quieres que haga ese trabajo con tu web, es el punto de partida del proyecto SEO a medida: auditoría técnica, plan priorizado y ejecución.

 

Checklist de SEO técnico priorizada

 

La tabla que uso como guion. La prioridad no es universal, pero refleja lo que más impacto suele tener en pymes y tiendas online.

 

Prioridad	Qué revisar	Cómo comprobarlo	Señal de alarma
Crítica	La web no bloquea el rastreo por error	robots.txt e informe de indexación	"Disallow: /" o secciones clave bloqueadas
Crítica	Páginas importantes indexadas	Search Console: indexación e inspección de URLs	Categorías o productos clave sin indexar
Crítica	noindex solo donde toca	Screaming Frog: directivas robots	noindex en plantillas de producto o categoría
Crítica	HTTPS y una sola versión del dominio	Probar http, https, www y sin www	Varias versiones accesibles sin 301
Alta	Canonicals coherentes	Screaming Frog e inspección de URLs	Google elige una canónica distinta a la tuya
Alta	Redirecciones correctas	Screaming Frog: códigos 3xx	302 en cambios definitivos o cadenas
Alta	Enlaces rotos y soft 404	Screaming Frog e informe de indexación	Enlaces a 404 o páginas vacías con 200
Alta	Contenido completo en móvil	Comparar versiones e inspección de URLs	Textos o enlaces ocultos en móvil
Alta	Core Web Vitals en verde	Search Console y PageSpeed Insights (campo)	LCP > 2,5 s, INP > 200 ms o CLS > 0,1
Media	Sitemap limpio y enviado	Informe de sitemaps y cruce con rastreo	URLs redirigidas, con noindex o con error
Media	Datos estructurados válidos	Prueba de resultados enriquecidos	Errores en Product o marcado no visible
Media	Arquitectura y profundidad	Screaming Frog: profundidad y enlaces entrantes	Páginas clave a más de 3-4 clics o huérfanas
Media	Filtros y parámetros controlados	Rastreo y búsquedas site:	Miles de URLs de filtros indexadas
Media	Contenido visible sin JavaScript	Desactivar JS e inspección de URLs	Texto o enlaces que solo aparecen con JS
Según caso	Hreflang en webs multidioma	Screaming Frog: pestaña hreflang	Sin enlaces de vuelta o códigos inválidos

 

No intentes resolverlo todo a la vez: ataca las filas críticas, mide en Search Console unas semanas y sigue bajando. Y repítelo: cada app nueva o cambio de tema puede romper algo que funcionaba.

 

Preguntas frecuentes sobre SEO técnico

 

¿Cada cuánto debería hacer una auditoría de SEO técnico?

 

Una completa al menos una vez al año y siempre antes y después de cambios importantes: rediseño, cambio de plantilla o migración. Entre medias, revisar Search Console cada mes basta para detectar caídas de indexación o errores nuevos.

 

¿El SEO técnico por sí solo me hará subir posiciones?

 

Normalmente no. Quita frenos. Si había problemas graves de indexación, al resolverlos puedes notar mejoras claras porque páginas que no existían para Google empiezan a contar. Pero para posicionar hace falta además contenido que responda a lo que se busca y autoridad.

 

¿Qué diferencia hay entre bloquear en robots.txt y usar noindex?

 

Robots.txt impide rastrear la página, pero no garantiza que no se indexe. Noindex le dice a Google que no la muestre, pero para leerlo tiene que poder rastrearla. Para sacar una página de Google, usa noindex y no la bloquees.

 

¿Shopify ya resuelve el SEO técnico?

 

Resuelve parte de la base: genera sitemap y robots.txt, sirve la tienda en HTTPS y los temas suelen ser responsive. Pero no te libra de los duplicados por colecciones y filtros, del exceso de apps que ralentizan, de los datos estructurados incompletos ni de las redirecciones al cambiar URLs.

 

¿Las Core Web Vitals se miden igual en móvil y en escritorio?

 

Se miden por separado, y PageSpeed Insights y Search Console muestran ambos. Como Google indexa con la versión móvil y la mayor parte del tráfico de pymes y tiendas suele llegar desde el móvil, es la versión a la que yo doy prioridad.

 

Siguiente paso: saber cómo está tu web hoy

 

El SEO técnico no se nota cuando funciona, solo cuando falla. Si tu web o tu tienda no aparece como debería, lo más probable es que haya algo de esta guía detrás.

 

Si quieres salir de dudas, reviso tu web y te digo qué la está frenando y por dónde empezaría. Solicita una auditoría inicial sin coste y, si tiene sentido seguir, lo trabajamos dentro de un proyecto SEO a medida o con optimización continua de tu eCommerce.

Dejar un comentario

Los comentarios se aprobarán antes de mostrarse.

Nombre *

Correo electrónico *

Comentario *

---

OTROS ARTÍCULOS