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.
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:
Solo después entra en juego el posicionamiento. Por eso el SEO técnico es condición necesaria, pero no suficiente.
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.
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.
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.
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.
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:
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.
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:
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.
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:
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.
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.
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.
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.
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.
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.
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:
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.
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:
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:
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.
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.
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:
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.
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:
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.
Para una primera auditoría seria bastan tres herramientas. Este es el orden que sigo:
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
Comments will be approved before showing up.
Tutorial paso a paso para leer el informe de rendimiento de Google Search Console: qué significan clics, impresiones, CTR y posición media, y cómo convertirlos en tres listas de trabajo.
Qué dice Google de forma oficial, qué puedes hacer en tu web y qué nadie puede prometerte para aparecer en las respuestas de Gemini, con un plan de 30 días.
Las causas más frecuentes por las que un competidor aparece antes que tú en Google, cómo comprobarlas con datos propios y qué hacer primero, explicado sin promesas ni fórmulas mágicas.
