Prioriza las observaciones y verifica los cambios de forma segura

Resultado

Podrás elegir el siguiente paso a partir de pruebas reproducibles y probarlo sin hacer cambios no autorizados en producción.

Explicación

Separa hecho, interpretación y acción. Para este breve ejercicio de formación, utiliza tres niveles:

• P0 — bloqueo: una página pública importante no está disponible, está bloqueada accidentalmente para el rastreo/la indexación o genera un error crítico visible para el usuario; primero confirma el efecto en la URL exacta.
• P1 — discrepancia importante: una página importante tiene una vía de descubrimiento o se abre, pero su contenido, idioma, canonical/enlaces o formulario dificultan su comprensión o uso. La afirmación «el sistema de búsqueda descubrió esta página» requiere confirmación independiente en un panel o registro verificado.
• P2 — mejora: el problema no bloquea el acceso ni induce al usuario a error; anótalo y prográmalo después de los bloqueos.

Esta es una escala de trabajo para el curso, no un estándar de los motores de búsqueda. Si la urgencia es similar, da prioridad al problema con pruebas reproducibles más sólidas y mayor impacto para el usuario.

Criterios verificables:

• Vía de descubrimiento: un enlace HTML normal desde una página de pruebas comprobada o una URL en el sitemap comprobado. Anota cada fuente; esto muestra cómo podría encontrar la URL un sistema, no que ya la haya encontrado.
• Descubrimiento por el sistema: confírmalo en el informe del sistema de búsqueda pertinente o en registros de rastreo verificados.
• Coherencia de URL y canonical: el enlace lleva a la URL final prevista, la respuesta es correcta, canonical coincide con la versión de destino y el sitemap incluye esa URL canonical. Comprueba por separado la canonical elegida por el sistema en su informe.
• Ninguna de estas comprobaciones confirma por sí sola la indexación.

Ejemplo ficticio

La maqueta de pruebas de formación para /robots presenta estas señales: un enlace del catálogo lleva a una URL http:// que redirige; la canonical del HTML apunta a /robots-v2, mientras que el sitemap contiene /robots. Es una discrepancia P1 si ambas páginas están disponibles y los usuarios pueden acceder al contenido; aumenta la prioridad solo si hay pruebas adicionales de bloqueo o pérdida de acceso. Los cambios de canonical, robots/noindex y WAF pueden afectar el acceso y las señales del sitio, por lo que cualquier cambio real requiere el consentimiento del propietario, una revisión previa y un plan de reversión probado.

Práctica

Trabaja únicamente en pruebas o en una copia local de example.test:

1. Añade al entorno de pruebas de la maqueta un estado contradictorio entre enlace/canonical/sitemap para /robots.
2. Completa la fila del registro con pruebas sin procesar y los límites de la conclusión.
3. Asigna P0/P1/P2 según los criterios anteriores.
4. Propón una corrección y el cambio observable esperado, pero no la apliques en producción.
5. Comprueba la corrección en pruebas utilizando los mismos métodos. Cualquier cambio real en producción de robots.txt, noindex, canonical o WAF requiere primero identificar al propietario, una revisión escrita del impacto y un plan de reversión; la publicación sigue el proceso habitual de lanzamiento. No cambies producción para este ejercicio.

Lista de comprobación

• Se registran la URL, la hora, la herramienta y las pruebas sin procesar.
• La vía de descubrimiento (enlace/sitemap) se distingue del descubrimiento confirmado por el sistema (panel/registro verificado).
• URL, redirección, canonical y sitemap se comprueban por separado.
• La prioridad se explica por el impacto y la fiabilidad de la observación.
• El ejercicio y la corrección se hicieron únicamente en pruebas/example.test.
• Cualquier cambio futuro en producción identifica al propietario, la revisión y la reversión.
• Las comprobaciones antes/después usan la misma URL, herramienta y condiciones.

Error habitual

Cambiar en producción robots.txt, canonical o WAF «para probar» y comprobar después. Ese cambio puede bloquear una sección útil o alterar el acceso. Empieza en un entorno de pruebas, con el propietario, una revisión y un plan de reversión.

Conjunto reutilizable de preguntas y referencia para migraciones

Para realizar comprobaciones repetibles de respuestas de IA, mantén un conjunto pequeño y estable de preguntas reales de clientes. Guarda el texto exacto, el idioma, la región, la superficie del producto, la fecha y las condiciones de cuenta/sesión. Incluye preguntas de descubrimiento, comparación y decisión; no añadas nombres de marca a todas las consultas. Una pregunta de muestra para un sitio ficticio es: «¿Qué debo comprobar antes de trasladar un pequeño sitio de documentación a un dominio nuevo?». Registra la respuesta completa y las URL citadas. Es un protocolo de medición, no una cantidad de consultas recomendada ni una promesa de cita.

Antes de una migración, exporta la lista de URL antiguas y prepara una fila por cada URL importante: URL anterior, destino previsto, estado de redirección, respuesta final, destino canonical, enlaces internos y presencia en el sitemap. Prueba el mapeo en el entorno de pruebas, incluidas las cadenas de consulta y las variantes de barra final que realmente utilice el sitio. Compara una muestra representativa antes del lanzamiento y vuelve a comprobar las mismas URL después. No sustituyas un mapa de redirecciones por una redirección general a la página de inicio; no cambies producción sin una publicación autorizada por el propietario y un plan de reversión.

Para este ejercicio, la columna «Resultado después del lanzamiento» es solo una referencia futura: introduce «no aplicable — no hubo publicación en producción». Complétala únicamente después de una publicación autorizada por el propietario.

El host .test y todas las filas anteriores son ejemplos ficticios.

Fuentes primarias

• Inspección de URL en Search Console
• Inspección de URL en Bing Webmaster Tools
• Cómo especificar una URL canonical
• Solucionar errores de rastreo de la Búsqueda de Google