SEO técnico: qué es, qué revisar y cómo priorizarlo
Una auditoría que devuelve 180 avisos no es una lista de tareas: es un inventario. El SEO técnico sirve para que Google pueda encontrar, leer e indexar las páginas que te interesan. La mayor parte del trabajo real está en decidir cuáles de esos avisos frenan eso y cuáles solo ensucian el informe. Esta guía explica qué revisa el SEO técnico, en qué orden mirarlo y cómo priorizar las correcciones cuando el equipo y el presupuesto no alcanzan para todo. Es la misma base con la que trabajamos el posicionamiento SEO de nuestros clientes.
Qué es el SEO técnico y en qué se diferencia del on page
El SEO técnico es el conjunto de ajustes de infraestructura que permiten a los buscadores rastrear, renderizar, indexar y entender un sitio web: respuesta del servidor, robots.txt, sitemaps, redirecciones, canonicals, velocidad, versión móvil, datos estructurados e idiomas. No crea demanda ni mejora un texto; elimina los obstáculos que impiden que un buen contenido compita.
La frontera con el resto del SEO es práctica, no teórica:
- SEO técnico: que la página exista para Google (se puede rastrear, devuelve 200, no está bloqueada, carga bien, no compite con un duplicado).
- SEO on page: que la página responda a una búsqueda concreta (intención, títulos, contenido, enlaces internos con sentido).
- SEO off page: que otros sitios la mencionen y enlacen.
Un error de diagnóstico frecuente es tratar como técnico un problema que es de contenido. Si una página se rastrea e indexa sin problemas pero no aparece para su keyword, rara vez la solución está en el servidor.
El recorrido que revisa una auditoría técnica
Google no “ve” una web de una vez. Descubre una URL, la rastrea, ejecuta su JavaScript si lo necesita, decide si la guarda en el índice y recién entonces puede mostrarla. Cada etapa tiene sus propios fallos, y un fallo en una etapa temprana anula todo lo que venga después.
Por eso el orden importa: no tiene sentido optimizar la velocidad de una página que tiene un noindex olvidado desde el lanzamiento.
Qué revisar en una auditoría de SEO técnico
Lo que sigue está agrupado por etapa. En una auditoría real no todo aplica a todos los sitios: un sitio corporativo de 40 URLs y un ecommerce con filtros tienen riesgos muy distintos.
Rastreo: que Google pueda llegar
- robots.txt: que no bloquee secciones que deben posicionar, ni los CSS y JS que la página necesita para mostrarse.
- Códigos de estado: páginas importantes respondiendo 200; nada de errores 5xx intermitentes ni 404 en URLs enlazadas desde el menú.
- Redirecciones: 301 directas, sin cadenas (A → B → C) ni bucles, sobre todo después de una migración o un rediseño.
- Sitemap XML: solo URLs indexables y canónicas, enviado en Search Console.
- Enlaces internos rotos y páginas huérfanas (sin ningún enlace que llegue a ellas).
Sobre el presupuesto de rastreo, conviene no exagerar. La guía de Google sobre el tema está pensada para sitios de más de un millón de páginas que cambian cada semana o de más de 10,000 que cambian a diario (Google Search Central, consultado en noviembre de 2026). En la mayoría de sitios de servicios en Perú o Ecuador, que tienen decenas o cientos de URLs, no es la prioridad.
Indexación: que Google decida guardar la página
Aquí aparece una de las confusiones más comunes: confundir bloquear el rastreo con impedir la indexación. Google documenta que robots.txt sirve para gestionar el tráfico de los rastreadores y no para mantener una página fuera de sus resultados; para eso está la directiva noindex (documentación de robots.txt). Y si bloqueas en robots.txt una página que lleva noindex, Google nunca llega a leer esa directiva, por lo que la URL puede seguir apareciendo si otros sitios la enlazan (documentación de noindex).
La forma más simple de la directiva es esta etiqueta en el <head>:
<meta name="robots" content="noindex">
En esta etapa también se revisa:
- Canonicals: cada página apunta a sí misma o a la versión que debe posicionar. Google la toma como una señal y puede elegir otra; cuando eso pasa, Search Console lo indica en el informe de indexación de páginas.
- Duplicados: versiones con y sin barra final, con y sin www, parámetros de seguimiento, páginas de etiquetas o paginaciones con el mismo contenido.
- Páginas de relleno indexadas: contenido de demostración de la plantilla, entradas de prueba, páginas de “gracias”. Es especialmente común en temas comprados.
- El informe de indexación de páginas de Search Console: no solo cuántas URLs están sin indexar, sino cuáles y por qué motivo.
Renderizado: que Google vea lo mismo que el usuario
Si el contenido principal, los enlaces o las etiquetas meta dependen de JavaScript, hay que comprobar qué recibe Google con la herramienta de inspección de URLs de Search Console. Los constructores visuales y algunos sliders cargan texto o enlaces tarde. Un menú que solo existe después de un clic puede dejar secciones enteras sin enlaces rastreables.
Rendimiento y Core Web Vitals
Las Core Web Vitals miden carga (LCP), respuesta a la interacción (INP) y estabilidad visual (CLS). Según web.dev, una página aprueba cuando, en el percentil 75 de las visitas reales, el LCP es de 2.5 segundos o menos, el INP de 200 milisegundos o menos y el CLS de 0.1 o menos, por separado en móvil y escritorio (umbrales consultados en noviembre de 2026). INP reemplazó a FID como métrica oficial en marzo de 2024.
El detalle que más confusión genera: la nota de PageSpeed Insights es una prueba de laboratorio en una sola carga simulada. La evaluación que usa Google se basa en datos de campo del Chrome UX Report, y un sitio con poco tráfico puede no tener datos de campo todavía. Una nota de 95 no garantiza aprobar, y una de 60 en laboratorio no significa necesariamente que los usuarios reales lo pasen mal.
Arquitectura y enlazado interno
- Páginas comerciales a pocos clics de la portada.
- Enlaces internos con texto descriptivo hacia las páginas que deben posicionar.
- URLs limpias y estables, sin cambios de estructura sin redirección.
Datos estructurados, idiomas y seguridad
- Datos estructurados válidos y coherentes con lo que se ve en la página (Organization o LocalBusiness, Service, BlogPosting, BreadcrumbList).
- hreflang si el sitio tiene versiones por idioma o país, con enlaces recíprocos entre versiones.
- HTTPS en todo el sitio, sin contenido mixto ni certificados vencidos.
Cómo priorizar el SEO técnico: impacto, alcance y esfuerzo
Las herramientas de auditoría ordenan por gravedad técnica, no por impacto en el negocio. Un “error” en 300 URLs de etiquetas que nadie busca pesa menos que un noindex en la página de servicio que genera los contactos. Para ordenar la lista, conviene responder tres preguntas por cada hallazgo:
- ¿Bloquea el rastreo, el renderizado o la indexación de páginas que venden o captan leads? Si la respuesta es sí, va primero, aunque afecte a una sola URL.
- ¿Cuántas URLs afecta y cuáles? No es lo mismo un problema en la plantilla de todas las fichas de producto que en una entrada antigua del blog.
- ¿Quién lo implementa y cuánto cuesta? Un cambio en el plugin SEO lo hace el equipo de marketing en minutos. Uno en el servidor o en el código del tema necesita al desarrollador y tiene riesgo de romper algo.
Con eso, la lista cae en cuatro niveles:
| Nivel | Qué entra | Ejemplos | Cuándo |
|---|---|---|---|
| P0: bloqueante | Impide que páginas de negocio se rastreen o indexen | noindex o bloqueo en robots.txt en servicios, errores 5xx, redirecciones rotas tras una migración | De inmediato |
| P1: alto impacto | Afecta a plantillas o a muchas URLs relevantes | Canonicals mal configurados, duplicados por parámetros, Core Web Vitals en rojo en las plantillas principales | En el primer mes |
| P2: mejora | Suma, pero no destraba nada | Datos estructurados, cadenas de redirección de un salto extra, enlazado interno hacia servicios | Plan de los meses siguientes |
| Backlog | Lo marca la herramienta, rara vez mueve resultados | Ratio texto/HTML, varios H1 en páginas sin tráfico, avisos en URLs que no deben indexarse | Solo si sobra capacidad |
Dos criterios para usar esta tabla. Primero, un P2 barato puede adelantarse a un P1 caro si el P1 depende de un desarrollador que no está disponible; lo que no se adelanta nunca es un P0. Segundo, cada corrección se anota con fecha, para poder leer después los datos de Search Console sin confundir el efecto del cambio con una actualización de Google o con la estacionalidad.
Lo que encontramos al auditar velogigx.com
Aplicamos este mismo orden en nuestra propia web, construida en WordPress sobre una plantilla comercial, porque si vendemos rendimiento y SEO técnico, el sitio tiene que demostrarlo.
Uno de los hallazgos con más peso fue de indexación, no de velocidad: la plantilla traía páginas de demostración publicadas e indexables (testimonios de ejemplo, servicios ficticios, categorías de diseño). Ninguna tenía relación con nuestros servicios y no tenía sentido que Google las indexara. Las marcamos como noindex.
En velocidad, el sospechoso obvio era el slider de la portada. Al medir, el cuello de botella estaba en cómo el plugin de caché generaba el CSS optimizado de cada página (el UCSS de LiteSpeed), que estaba procesando rutas que no lo necesitaban, como las paginaciones. Tras excluir esas rutas y limpiar las colas de generación, la portada en móvil marcó 98 en PageSpeed Insights en noviembre de 2026. Es un dato de laboratorio: con el tráfico actual del sitio, la evaluación de campo todavía depende de acumular visitas reales.
Como P2 quedaron los datos estructurados conectados entre sí (la empresa como ProfessionalService y un Service por cada página de servicio) y la versión en inglés en /en/, con sus propias URLs para no generar duplicados entre idiomas.
La lección no es que el slider sea inocente en todos los sitios, sino que la priorización empieza por medir. Si hubiéramos rehecho la portada para quitarlo, habríamos gastado la mayor parte del esfuerzo en algo que no movía la métrica.
Por dónde empezar
Si solo tienes una tarde, abre el informe de indexación de páginas de Search Console. Verifica que tus páginas de servicio, contacto y producto principales estén indexadas y respondan 200. Si alguna no lo está, ese es tu P0 y lo demás puede esperar. Si todas están bien y aun así el tráfico no crece, el problema probablemente no es técnico. Cuando necesites ese diagnóstico ordenado por impacto y no por número de avisos, es el punto de partida de nuestro servicio de SEO.
Preguntas frecuentes sobre SEO técnico
¿Cada cuánto conviene revisar el SEO técnico?
Search Console avisa de errores nuevos por correo, así que la revisión rápida puede ser mensual. Una auditoría completa tiene sentido cada pocos meses y siempre antes y después de cambios grandes: migración, rediseño, cambio de plantilla o de hosting.
¿Necesito un desarrollador para hacer SEO técnico?
No para todo. En WordPress, buena parte de los P0 y P1 (noindex, canonicals, sitemap, redirecciones simples) se resuelve desde el plugin SEO. El servidor, el código del tema y los problemas de JavaScript sí requieren a alguien que pueda tocar código.
¿En cuánto tiempo se ven resultados?
Depende de cuánto tarde Google en volver a rastrear las URLs corregidas y de qué se corrigió. Destrabar una página bloqueada puede reflejarse rápido; mejorar velocidad en un sitio con poco tráfico puede no notarse en los datos de campo durante semanas. Nadie puede garantizar posiciones ni plazos.
