El SEO técnico revisa si una web puede rastrearse, interpretarse y utilizarse correctamente. Abarca cuestiones como acceso a las páginas, respuestas del servidor, versiones duplicadas, navegación y rendimiento. Su objetivo práctico es que los problemas de funcionamiento no impidan encontrar y aprovechar el contenido.
Una auditoría útil termina con prioridades, responsables y comprobaciones. Un listado de cien avisos sin saber cuáles afectan a las páginas importantes todavía no es un plan de mejora.
Rastrear, indexar y posicionar son cosas distintas
| Etapa | Pregunta que resuelve | Ejemplo de problema |
|---|---|---|
| Descubrimiento y rastreo | ¿El buscador conoce la URL y puede acceder al contenido? | Una guía nueva no tiene enlaces desde ninguna sección accesible. |
| Indexación | ¿El contenido se incorpora al índice y qué versión se selecciona? | La página pública conserva una instrucción noindex de las pruebas. |
| Clasificación | ¿Para qué búsquedas y en qué posición puede mostrarse? | La página funciona, pero no responde bien a la consulta. |
Resolver un problema de acceso no demuestra que se haya logrado la indexación. Y estar indexado no equivale a ocupar los primeros resultados. El trabajo técnico necesita acompañarse de contenido útil y bien organizado.
Auditoría de SEO técnico: por dónde empezar
1. Define qué páginas deberían encontrarse
Haz un inventario de páginas de servicios, categorías, artículos y recursos relevantes. Diferencia las que quieres mostrar en búsquedas de las que tienen otra función, como pruebas o confirmaciones. Así podrás valorar cada aviso según la intención real de la página.
Una URL excluida no es necesariamente un error: puede tratarse de una alternativa duplicada correctamente consolidada. Tampoco interesa convertir cada filtro, búsqueda interna o combinación de parámetros en un resultado independiente.
2. Comprueba acceso y respuestas
Abre una muestra de cada plantilla y las páginas más importantes. Revisa que carguen por HTTPS sin avisos, que no exijan iniciar sesión por accidente y que la respuesta del servidor corresponda a lo mostrado. Una pantalla que dice «no encontrado» no debería presentarse como si fuera una página de contenido válida.
Si cambias una URL, conserva una correspondencia con el destino equivalente. No envíes todos los enlaces antiguos a la portada: el visitante puede buscar un recurso concreto. Evita cadenas y bucles, y actualiza los enlaces internos para que apunten directamente al destino vigente.
3. Distingue robots.txt, noindex y canonical
Robots.txt regula el rastreo; bloquear una URL no garantiza que desaparezca de Google. Noindex indica que no debe indexarse, pero el buscador necesita acceder a la página para leer esa instrucción. Ninguno sustituye un control de acceso para información privada.
La señal canonical comunica una versión preferida entre páginas iguales o muy similares. No obliga a Google a elegirla. Comprueba que canonical, enlaces internos y sitemap sean coherentes; no señales como principal una URL distinta en cada lugar.
| Necesidad | Qué revisar | Error que debes evitar |
|---|---|---|
| Publicar una guía que estaba en pruebas | Acceso, contenido e instrucciones de indexación. | Dejar noindex activado después del lanzamiento. |
| Consolidar dos versiones equivalentes | Versión preferida y señales coherentes. | Usar noindex como sustituto automático de canonical. |
| Proteger documentación privada | Autenticación y permisos. | Confiar en ocultarla del menú o del buscador. |
4. Revisa navegación, sitemap y contenido visible
Una persona debería poder pasar de la categoría al artículo y encontrar recursos relacionados sin adivinar la dirección. Revisa páginas huérfanas, enlaces rotos y menús que solo funcionan con ratón. El sitemap debe representar las URLs que has elegido publicar y mantener sus fechas de modificación de forma veraz.
Si la web depende de JavaScript, verifica que el contenido y los enlaces importantes se renderizan correctamente. Desactivar JavaScript puede ayudar a detectar dependencias, pero no reproduce exactamente lo que hace Google. Su documentación explica el procesamiento y las precauciones de indexación.
5. Prueba el móvil como lo usaría un lector
No te limites a comprobar que la portada cabe en pantalla. Abre el menú, lee un artículo largo, recorre una tabla, amplía el texto y utiliza el formulario. Las columnas deben conservar un ancho legible; si necesitan desplazamiento horizontal, este debe quedar dentro de la tabla y poder utilizarse.
Comprueba también que los botones no se solapan, que los mensajes de error explican qué corregir y que los elementos flotantes no tapan el contenido. Una página puede cargar deprisa y seguir siendo incómoda de leer.
6. Mide rendimiento y prioriza sus causas
Las Core Web Vitals actuales evalúan carga, respuesta a interacciones y estabilidad visual. Sus umbrales de buena experiencia son LCP ≤ 2,5 segundos, INP ≤ 200 milisegundos y CLS ≤ 0,1, evaluados en el percentil 75 y separando móvil y ordenador.
Distingue datos de usuarios reales y pruebas de laboratorio. Estas últimas ayudan a diagnosticar, pero una medición aislada no describe todas las conexiones y dispositivos. Si faltan datos de campo, no lo interpretes como aprobado ni suspenso.
Empieza por causas observables: imágenes sobredimensionadas, recursos innecesarios, tareas que bloquean la interacción o espacios que cambian al cargar. Google recuerda que obtener buenos resultados de experiencia no garantiza primeras posiciones. El objetivo es mejorar el uso de la página, no perseguir una cifra sin valorar su coste.
Ejemplo: ordenar una revisión sin arreglarlo todo a ciegas
Caso ficticio. NexoCursos publica doce fichas de talleres y una biblioteca de artículos. Antes de cambiar de diseño, guarda su inventario y define tres recorridos: encontrar un taller, consultar una comparación y enviar una solicitud.
| Hallazgo del ejercicio | Prioridad razonada | Cómo comprobar la solución |
|---|---|---|
| Dos fichas públicas mantienen noindex. | Alta: impide cumplir su finalidad de aparecer en búsquedas. | Revisar la instrucción publicada y después el estado en Search Console. |
| El menú móvil no abre. | Alta: bloquea uno de los recorridos principales. | Recorrer categorías y fichas desde un teléfono. |
| Una tabla reduce cada palabra a una columna muy estrecha. | Alta en esa plantilla: el contenido resulta ilegible. | Leer todas las columnas con texto ampliado y desplazamiento utilizable. |
| Una imagen decorativa ocupa demasiado. | Depende de dónde aparece y de su efecto medido. | Comparar tamaño, calidad y carga en condiciones equivalentes. |
Tras corregir el menú, no basta con marcar la incidencia como cerrada porque cambió el código: alguien debe completar el recorrido. Tras retirar noindex, el equipo distingue «instrucción corregida» de «página ya indexada». Son estados diferentes.
La revisión registra URL, plantilla, evidencia, alcance, responsable y resultado. Si una causa afecta a todas las fichas, se corrige en la plantilla y se comprueban casos representativos, además de las excepciones conocidas.
Qué comprobar en Search Console
Usa la inspección de URLs para diferenciar la información de la versión indexada y la prueba de la página publicada. Revisa fecha de rastreo, restricciones y canónica elegida cuando estén disponibles. Una prueba en tiempo real válida no garantiza indexación.
El informe de páginas ayuda a detectar patrones; inspecciona ejemplos antes de cambiar una regla general. El sitemap facilita comunicar muchas URLs, pero solicitar rastreo no garantiza inclusión ni repetirlo la acelera.
¿Hay que optimizar el crawl budget en una web pequeña?
No suele ser la primera prioridad. La guía avanzada de Google sobre presupuesto de rastreo se dirige principalmente a sitios grandes, muy cambiantes o con problemas relevantes de descubrimiento. En una web pequeña, empieza por acceso, enlaces, contenido, sitemap e incidencias concretas.
¿Una web a código tiene mejor SEO que WordPress?
La tecnología no garantiza el resultado. Una web estática puede reducir dependencias y facilitar una entrega ligera; una implementación descuidada también puede perder URLs, enlaces o funciones. WordPress puede funcionar correctamente si se configura y mantiene bien.
Valora el resultado publicado: contenido accesible, navegación útil, rendimiento, continuidad de URLs y capacidad de mantenerlo actualizado. La auditoría termina cuando las mejoras se comprueban en la web que recibe el usuario.
