El SEO técnico es la optimización de la infraestructura de un sitio web (velocidad, rastreo, indexación, arquitectura, seguridad) para que los motores de búsqueda puedan acceder, entender y posicionar tu contenido sin obstáculos.
El SEO técnico es tan importante como tu estrategia de contenidos — de hecho, es la condición para que esa estrategia funcione. Puedes tener el mejor artículo del mundo sobre tu nicho, pero si Google no puede rastrearlo bien, o tu página tarda 8 segundos en cargar, ese artículo nunca va a competir por la página 1. Ninguna keyword bien elegida ni ningún párrafo bien escrito arregla eso.
Cómo funciona por dentro: rastreo, indexación y renderizado
Todo SEO técnico se resume en tres procesos que Google ejecuta en orden, y que conviene entender antes de tocar cualquier configuración.
Rastreo
Es el proceso donde Googlebot descubre tus páginas siguiendo enlaces internos o leyendo tu sitemap. Si una página no tiene ningún enlace apuntándole (una página huérfana) o tu robots.txt la bloquea, Google directamente no la ve.
Indexación
Una vez rastreada, Google analiza el contenido de la página y decide si la guarda en su índice — la base de datos desde donde arma los resultados de búsqueda. Contenido duplicado, etiquetas noindex mal puestas o páginas de bajo valor pueden hacer que una página se rastree pero nunca se indexe.
Renderizado
Es el paso donde Google ejecuta el HTML, CSS y JavaScript de tu página para “verla” como la vería un usuario real. Si tu sitio depende de JavaScript para mostrar contenido importante y ese JavaScript tarda en cargar o falla, Google puede terminar indexando una versión incompleta de tu página.
| Proceso | Qué hace Google | Qué lo puede romper |
|---|---|---|
| Rastreo | Sigue enlaces y lee tu sitemap para descubrir páginas | robots.txt mal configurado, páginas huérfanas |
| Indexación | Analiza el contenido y decide si lo guarda en su índice | Contenido duplicado, noindex mal puesto |
| Renderizado | Ejecuta HTML/CSS/JS para “ver” la página como un usuario | JavaScript que bloquea el contenido principal |
Así se ve el flujo completo, de principio a fin:
Mi checklist real de auditoría técnica
Cuando entro a auditar un sitio — el mío o el de un cliente — no abro diez herramientas distintas. Tengo un punto de partida fijo y una lista corta de errores que reviso primero, porque en la mayoría de los casos ahí está el 80% del problema.
Por qué PageSpeed Insights es mi primera parada
Mi herramienta número uno es PageSpeed Insights, la herramienta oficial de Google que evalúa el performance de la página y los elementos básicos del SEO. La uso porque es la herramienta oficial del buscador y navegador más usado del mundo, así que te da una primera evaluación muy completa sin tener que cruzar datos de varias fuentes.
Los 3 errores que encuentro casi siempre
Casi siempre son los mismos errores básicos, sin importar el tamaño del sitio:
- Imágenes que cargan lento porque son muy pesadas y encima no tienen alt text.
- Metadatos genéricos — títulos y descripciones que no dicen nada específico de la página.
- Bloqueos de JS y CSS que retrasan la primera carga de la página.
Si arreglas solo estos tres puntos antes de meterte en configuraciones más avanzadas, ya vas a notar una mejora real en cómo Google ve tu sitio. No hace falta empezar por lo complicado — hace falta empezar por lo que de verdad está rompiendo la experiencia del usuario.
Velocidad y Core Web Vitals en WordPress
De todo lo que he probado para mejorar la velocidad en WordPress, hay un plugin que se volvió mi favorito: Autoptimize.
Por qué uso Autoptimize (y qué probé antes)
Antes de quedarme con Autoptimize probé varios plugins de velocidad — es algo que recomiendo hacer siempre, porque cada sitio responde distinto según el theme, los plugins instalados y el hosting. Lo que me convenció de Autoptimize es que no se queda en lo básico. Con él puedo:
- Minificar y unir archivos JS y CSS para reducir el número de peticiones.
- Diferir la carga de esos archivos para no bloquear el renderizado.
- Activar lazy-load de imágenes, que mejora bastante FCP y LCP.
- Optimizar la carga de fuentes tipográficas.
- Optimizar la carga de videos embebidos de YouTube.
Es un plugin que te sirve tanto si solo quieres tocar lo básico como si quieres bajar a configuraciones más avanzadas. Si tu carga de imágenes también te está pesando en el LCP, es de las primeras cosas que reviso después de instalarlo.
Rastreo bajo control: robots.txt y sitemaps en WordPress
El robots.txt y el sitemap.xml los tengo configurados a través de Yoast, pero no por la misma razón para ambos.
Por qué el sitemap va por Yoast y el robots.txt lo administro a mano
El sitemap lo dejo en manos de Yoast porque es dinámico: cada vez que publico contenido nuevo, Yoast lo incluye automáticamente y no tengo que preocuparme por estar subiéndolo de nuevo cada vez. Es de esas configuraciones que prefiero automatizadas — entre menos tenga que recordar manualmente, mejor.
El robots.txt, en cambio, sí me parece un archivo que se puede administrar a mano, porque no cambia con frecuencia. Ahí lo que importa no es la automatización, sino asegurarte de que su contenido esté bien hecho desde el principio. Un robots.txt mal escrito puede bloquear páginas que sí quieres que Google vea:
User-agent: *
Disallow: /
Esa sola línea bloquea absolutamente todo tu sitio. Y muchas veces ese error pasa meses sin que nadie lo note.
Lo que nadie optimiza: imágenes y fuentes tipográficas
Estas dos cosas parecen menores, pero en mi experiencia son de las que más impacto tienen en velocidad y en Core Web Vitals, y casi nadie las toca.
Mi flujo de imágenes: redimensionar antes de convertir a WebP
Uso WebP para todas mis imágenes — es uno de los formatos que más recomienda Google, y tiene muy buena relación calidad/peso. Mi flujo es siempre el mismo:
- Reviso las dimensiones originales de la imagen.
- La redimensiono al tamaño real en el que se va a renderizar — muchas veces no necesitas una imagen de 3600x3600px en una web que la va a mostrar en 600x600px.
- La comprimo y convierto a WebP.
- Reviso que la calidad se mantenga aceptable.
- Recién ahí la subo al sitio.
Saltarse el paso 2 es el error más común que veo: convertir a WebP una imagen que sigue siendo gigante en dimensiones apenas ahorra peso comparado con redimensionarla primero.
El título que me costó 1.6 segundos de LCP
Tengo una experiencia reciente que para mí fue reveladora. No podía bajar mi LCP de 3.5 segundos, así que revisé cuál era el elemento más grande en esa primera carga: era un título. Se demoraba en aparecer porque estaba renderizando la fuente tipográfica, y esa fuente la cargaba desde Google Fonts — esa petición externa se sumaba a la carga total.
Lo que hice fue descargar las fuentes y tenerlas directamente en el proyecto, en vez de pedirlas a un servidor externo. Ahí ya mejoró el tiempo de carga. Después optimicé los archivos de las fuentes y llegué a este resultado:
| Momento | LCP |
|---|---|
| Antes (fuente desde Google Fonts) | 3.5s |
| Después (fuente autohospedada + optimizada) | 1.9s |
Un solo H1 mal resuelto te puede costar más de lo que crees. Para mí fue revelador que algo tan chico como la fuente de un título tuviera ese peso en el número final.
JavaScript: async/defer y el peso invisible de los plugins
Con async y defer también he conseguido cifras que sorprenden a cualquiera que no lo haya probado.
De 45-50 a 75-80 en Lighthouse solo por diferir lo que no es crítico
| Momento | Performance móvil (Lighthouse/PageSpeed) |
|---|---|
| Antes | 45-50 |
| Después de aplicar async/defer | 75-80 |
Ese salto lo conseguí solo por dejar de bloquear el renderizado con cosas como animaciones que no necesitan cargarse desde el primer instante. La clave está en identificar qué elementos deben estar disponibles desde el primer clic del usuario, y qué se puede diferir sin dañar la experiencia. La mayoría de plugins de WordPress cargan su JavaScript como si todo fuera crítico, y casi nunca lo es — ahí es donde está la ganancia.
Datos estructurados, HTTPS y mobile — y por qué el crawl budget también te castiga
Lo esencial de HTTPS y mobile en 3-4 líneas
Tu sitio debe estar en HTTPS — es señal de posicionamiento desde hace más de una década, y sin eso ni vale la pena hablar del resto. En mobile, Google indexa principalmente la versión móvil de tu sitio, así que si tu diseño responsive tiene problemas ahí, tu posicionamiento entero se ve afectado, no solo el tráfico móvil.
Por qué casi nadie implementa datos estructurados (y por qué los LLMs y Google lo premian)
Es impresionante ver, en las auditorías que hago, que muchos sitios todavía no tienen datos estructurados implementados. Y cada vez importa más, sobre todo por lo que significan para los LLMs: les permite entender el contenido de tu página más fácil y más rápido. Incluso Googlebot lo agradece — ahí entra el concepto de crawl budget, que Google premia si lo usas bien, y castiga si lo ignoras o lo usas mal.
Si estás empezando desde cero, no hace falta que implementes los veinte tipos de schema que existen. Con estos dos ya cubres la base que la mayoría de sitios ni siquiera tiene:
- Article, en cada post del blog.
- BreadcrumbList, en tu navegación.
Es una de esas mejoras que casi no toma tiempo implementar, comparado con lo que cuesta en visibilidad no tenerla.
Preguntas frecuentes sobre SEO técnico
¿Qué es el SEO técnico?
Es la optimización de la infraestructura de un sitio web (velocidad, rastreo, indexación, arquitectura, seguridad) para que los motores de búsqueda puedan acceder, entender y posicionar tu contenido sin obstáculos. No tiene que ver con qué escribes, sino con qué tan fácil es llegar a eso que escribiste.
¿Cuáles son los elementos básicos del SEO técnico?
Robots.txt y sitemap bien configurados, velocidad de carga y Core Web Vitals, compatibilidad móvil, HTTPS, datos estructurados y ausencia de contenido duplicado. Todos apuntan a lo mismo: que Google pueda rastrear, indexar y renderizar tu sitio sin fricción.
¿Qué herramienta usar para auditar el SEO técnico de un sitio?
PageSpeed Insights es un buen punto de partida: es la herramienta oficial de Google y evalúa performance y elementos básicos de SEO en un solo lugar. De ahí puedes identificar imágenes pesadas, metadatos genéricos y bloqueos de JS/CSS, que son los errores más comunes.
¿Por qué importan los datos estructurados para el SEO técnico?
Porque ayudan a Google y a los LLMs a entender tu contenido más rápido y con menos ambigüedad, y porque el crawl budget de tu sitio mejora cuando lo usas bien. La mayoría de los sitios auditados todavía no los implementa, así que es una ventaja fácil de conseguir.
Si quieres correr tu propia auditoría, empieza igual que yo: entra a PageSpeed Insights, revisa los tres errores que mencioné arriba y déjame tu URL en los comentarios — le doy un vistazo y te digo por dónde empezar.