Empieza por las páginas previstas y evidencia reutilizable
Lista las páginas públicas que quieres que los buscadores encuentren: productos clave, artículos, categorías y URLs movidas. Para cada una, registra la URL preferida, la respuesta esperada, la indexabilidad, la plantilla, el responsable y la prioridad. Mantén las exclusiones legítimas por separado.
Captura una respuesta no autenticada, cabeceras, la ruta de redirecciones, el código fuente, la vista renderizada, el estado de enlaces internos y el estado en el sitemap para URLs representativas. Muestra cada plantilla y patrón de URL. La evidencia tiene fecha: una configuración de CDN, un despliegue, la capa de consentimiento o la personalización pueden cambiarla después.
Un homepage que pasa las pruebas no demuestra que los listados, variantes de producto o rutas localizadas funcionen.
Conserva cabeceras fechadas y evidencia renderizada para comparar correcciones y regresiones posteriores.
Haz de la indexabilidad una decisión deliberada
Indexabilidad significa que una página puede ser incluida en un índice de búsqueda; no es lo mismo que rastreo o posicionamiento. Comprueba las directivas meta robots en HTML y los encabezados de respuesta X-Robots-Tag. La directiva noindex indica a los motores que no muestren una página; X-Robots-Tag también se aplica a archivos no HTML, como PDFs.
Revisa robots.txt por separado. Un rastreador debe acceder a una página para encontrar su directiva noindex, así que bloquear esa URL puede impedir que la directiva sea vista. Verifica la respuesta pública desplegada porque las configuraciones del CMS y las banderas de entorno pueden añadir reglas. Noindex no es control de acceso: protege material sensible con autenticación y la revisión de seguridad adecuada.
Marca noindex, respuestas de inicio de sesión, referencias a entornos de staging y activos esenciales bloqueados en páginas que deberían indexarse.
Un encabezado HTTP puede llevar una directiva incluso cuando no existe una etiqueta head en HTML.
Mantén una URL preferida consistente
La canonicalización identifica la URL preferida entre versiones duplicadas o muy similares, como HTTP y HTTPS, hosts, parámetros de seguimiento, filtros o páginas de impresión. Compara el elemento canonical, los enlaces internos, la URL en el sitemap y el destino de la redirección. Para una página indexable, normalmente deberían identificar la misma URL preferida absoluta.
Usa una redirección permanente del lado del servidor al retirar un duplicado. Google describe las redirecciones permanentes y rel=canonical como señales fuertes, mientras que la inclusión en el sitemap es más débil; señales alineadas refuerzan la preferencia. No uses robots.txt para canonicalizar ni des señales canónicas en conflicto. Un canonical autoreferente ayuda a declarar la versión preferida, pero la selección final por el motor de búsqueda queda fuera de tu control.
Documenta variantes, el objetivo preferido, el control requerido y un responsable.
Prueba los mapeos de antiguo a nuevo antes de una migración y mantén lista una reversión de redirección.
Comprueba códigos de estado y comportamiento de redirecciones
Los códigos de estado indican a navegadores y rastreadores qué sucedió. Las páginas importantes en vivo deben devolver una respuesta 2xx significativa con el contenido previsto. Una página sin reemplazo relevante debería devolver un 404 o 410 genuino; el contenido movido debe llegar a su reemplazo relevante más cercano. Una página 200 que solo muestra un error puede ser tratada como un soft 404.
Registra cada salto de redirección. Google normalmente sigue hasta 10 saltos en rastreo general, pero las cadenas añaden latencia y fragilidad. Google indica que respuestas 5xx y 429 pueden ralentizar temporalmente el rastreo y que errores de servidor persistentes pueden acabar eliminando URLs indexadas. Investiga fallos recurrentes con el responsable de ingeniería a través de las capas de aplicación, CDN, origen, caché, dependencias y despliegue.
Guarda la URL original, los saltos, los códigos, la URL final y el estado esperado.
Elimina reglas solapadas de CMS, CDN, host, localización o barras en lugar de añadir otro salto.
Valida el renderizado JavaScript y las rutas
Inspecciona tanto el HTML inicial como una vista renderizada para plantillas clave. Confirma que el contenido principal, encabezados, enlaces, canonical, directivas robots y estado existen después del renderizado. Google describe fases separadas de rastreo, renderizado e indexación y dice que el contenido no visible en el HTML renderizado no puede indexarse.
Usa elementos anchor con valores href para la navegación. Rutas basadas solo en fragmentos que cargan contenido distinto no son fiables para la descubribilidad. Solicita directamente productos inexistentes, artículos y URLs filtradas. Las aplicaciones cliente necesitan un estado de error real; Google documenta enrutar a un 404 de servidor o añadir noindex para evitar soft 404s. El renderizado en servidor o prerendering puede ayudar, pero verifica la respuesta desplegada.
Comprueba el HTML de respuesta, el HTML renderizado y la vista humana en el navegador buscando diferencias materiales.
Prefiere el HTML de origen; si JavaScript lo establece, asegúrate de que exista un canonical no conflictivo.
Mantén sitemaps y enlaces internos limpios
Un sitemap es un mapa de descubrimiento, no una orden de indexación. Incluye URLs canónicas preferidas que funcionen; excluye redirecciones, errores, páginas noindex, duplicados por parámetros y URLs protegidas. Google recomienda URLs absolutas totalmente calificadas y considera la inclusión en el sitemap como una pista canónica, no una garantía.
Valida el sitemap y compáralo con la lista de intención de indexación y la navegación. Google documenta codificación UTF-8 y un límite de 50 MB sin comprimir o 50.000 URLs por sitemap. Para sitios grandes, divídelos en grupos útiles y usa un índice. Actualiza lastmod solo para cambios significativos y verificables en la página.
Investiga diferencias significativas entre URLs previstas, entradas del sitemap y enlaces internos.
Comprueba el sitemap generado y una muestra de URLs listadas después de cambios en el enrutamiento o el CMS.
Mide rendimiento e institucionaliza la auditoría
Usa datos de campo cuando estén disponibles y pruebas de laboratorio controladas para investigar Core Web Vitals: Largest Contentful Paint (LCP) para carga, Interaction to Next Paint (INP) para capacidad de respuesta y Cumulative Layout Shift (CLS) para estabilidad visual. Segmenta por tipo de página y dispositivo porque los promedios pueden ocultar una plantilla de alto valor rota.
Rastrea entregas lentas o inestables a través de imágenes, CSS y JavaScript, etiquetas de terceros, fuentes, embeds y caché. Haz un cambio medido y vuelve a comprobar el renderizado y los flujos de usuario. Los datos de campo reflejan usuarios reales; los datos de laboratorio ayudan a reproducir problemas. Ninguno predice todos los futuros rastreadores o visitantes. Repite una comprobación de regresión focalizada después de despliegues de riesgo y una auditoría más completa tras migraciones o cambios de plataforma.
Repara fallos en plantillas críticas para ingresos o muy usadas antes que pequeñas mejoras de puntuación en otros lugares.
Vuelve a comprobar respuesta, canonical, contenido renderizado, estado del sitemap y evidencia de rendimiento relevante antes de cerrar.