Define la pregunta y los límites
Un informe técnico útil permite decidir: qué se observó, por qué contradice el comportamiento deseado, quién lo cambiará y cómo se aceptará. Indica host, entorno, fecha de recogida, origen de URL, método de rastreo/renderizado y límites de acceso. Seis URL no equivalen a toda la web; enumera plantillas, dispositivos y zonas privadas no examinados.
Los ejemplos originales funcionan en tu ordenador. Las rutas anteriores y corregidas coexisten para repetir las pruebas sin modificar producción. Ilustran HTTP, directivas HTML y decisiones de entrega; no simulan Googlebot, renderizado JavaScript, datos de campo ni indexación. Los canonical relativos facilitan el ejercicio local; en producción consulta la documentación.
Registra pruebas reproducibles
Conserva URL exacta, método, cadena de respuestas, cabeceras relevantes y fragmento fuente. Añade hora UTC y referencia a captura o traza en pruebas reales. Si el HTML renderizado difiere del inicial, registra ambos y los ajustes de la herramienta. Separa observación, explicación y recomendación; no comprobado no significa aprobado.
La verificación del kit genera los seis pares de respuestas en JSON. Compáralos con evidence.json del ZIP. Se omiten fechas del servidor y puertos temporales para mantener la traza estable: es un caso reproducible, no una medición fechada de un cliente. Los comandos no rastrean sitios arbitrarios.
Prioriza objetivo, alcance y confianza por separado
Tres prioridades altas contradicen un objetivo explícito de entrega o indexación. Dos medias requieren corregir una plantilla o relación de contenido. El control no cambia. Estas etiquetas pertenecen al ejercicio. En una web real considera alcance, rutas críticas, confianza, riesgo y esfuerzo antes de ordenar tareas. No extrapoles prevalencia desde seis filas.
Asigna una persona responsable y una fecha de revisión. Muchas advertencias no superan automáticamente un fallo probado en una ruta crítica. Confirma el comportamiento deseado antes de cambiar noindex, redirecciones o canonical. No retires exclusiones deliberadas para mejorar una puntuación.
| ID | Observación | Prioridad | Responsable |
|---|---|---|---|
| A01 | La página pública contiene noindex | Alta | Desarrollador web |
| A02 | Robots impide leer la exclusión | Alta | Responsable de plataforma |
| A03 | La redirección permanente termina en error | Alta | Desarrollador de rutas |
| A04 | Canonical apunta a contenido ajeno | Media | Responsable SEO y desarrollador |
| A05 | La página ausente responde con éxito | Media | Desarrollador web |
| A06 | El control correcto no necesita arreglos especulativos | Sin cambios | Revisor de auditoría |
Seis hallazgos para entregar al desarrollador
A01 · La página pública contiene noindex
Observación: GET /launch devuelve 200 y una meta robots noindex. Se pretende una página pública apta para búsqueda.
Por qué importa: La directiva contradice ese objetivo. Su presencia está confirmada; no sabemos si Google la ha visto.
Acción propuesta: Retira la directiva involuntaria de la plantilla pública. Revisa también cabeceras y HTML renderizado.
Responsable: Desarrollador web
Criterio de aceptación: /fixed/launch devuelve 200 sin noindex. Repite la prueba en producción y realiza la Inspección de URLs autorizada por separado.
A02 · Robots impide leer la exclusión
Observación: robots.txt bloquea /blocked/; /blocked/page contiene noindex. Se busca excluir de búsqueda, no restringir acceso.
Por qué importa: Un rastreador que respeta las reglas no puede leer la directiva. Robots no sustituye autenticación.
Acción propuesta: Permite rastrear la página y conserva noindex. Protege contenido privado con autenticación.
Responsable: Responsable de plataforma
Criterio de aceptación: /fixed/blocked/page está fuera del prefijo bloqueado y mantiene noindex. Verifica las reglas reales y observa la indexación aparte.
A03 · La redirección permanente termina en error
Observación: /old-guide devuelve 301 a /missing-guide, que responde 404. Se supone que /guide es un sustituto relevante.
Por qué importa: La ruta no entrega el contenido previsto. Una redirección no demuestra que el destino funcione.
Acción propuesta: Redirige directamente al sustituto relevante y actualiza enlaces internos. No envíes todas las páginas eliminadas a la portada.
Responsable: Desarrollador de rutas
Criterio de aceptación: /fixed/old-guide devuelve un 301 y después /guide con 200 y contenido esperado. Inspecciona toda la cadena tras desplegar.
A04 · Canonical apunta a contenido ajeno
Observación: /variant declara /other-topic como canonical, aunque duplica /guide.
Por qué importa: La preferencia contradice la relación entre contenidos. No revela la URL canónica elegida por Google.
Acción propuesta: Confirma equivalencia y alinea canonical, enlaces internos y sitemap con /guide. Conserva páginas con necesidades distintas.
Responsable: Responsable SEO y desarrollador
Criterio de aceptación: /fixed/variant declara /guide y el destino funciona. Comprueba la elección de Google por separado cuando tengas acceso.
A05 · La página ausente responde con éxito
Observación: /gone devuelve 200 con un encabezado Not found. No hay sustituto adecuado.
Por qué importa: Es una discrepancia entre contenido de error y estado correcto: candidata a soft 404, no clasificación observada de Google.
Acción propuesta: Devuelve el estado de recurso ausente y elimina enlaces internos obsoletos. Mantén una página de error útil.
Responsable: Desarrollador web
Criterio de aceptación: /fixed/gone devuelve 404 con el error. Una observación posterior de Search Console es una prueba independiente.
A06 · El control correcto no necesita arreglos especulativos
Observación: /guide devuelve 200, se declara canonical y estas reglas robots no la bloquean. Esta respuesta no contiene noindex.
Por qué importa: Pasa estos controles locales, pero no prueba calidad, renderizado, descubrimiento, indexación ni posiciones.
Acción propuesta: Registra el control aprobado. Investiga otros indicios solo cuando una pregunta concreta lo justifique.
Responsable: Revisor de auditoría
Criterio de aceptación: Las respuestas anterior y posterior son idénticas. Conserva la prueba correcta sin inventar problemas para aumentar el recuento.
Cierra cada hallazgo con una nueva prueba
Un ticket implementado no demuestra cierre. Repite la petición original en el entorno desplegado, revisa URL equivalentes y registra hora y respuesta nuevas. Conserva las pruebas antiguas. Distingue aceptación técnica de una observación posterior del buscador: corregir una directiva no garantiza indexación ni tráfico.
Utiliza el informe y el registro
Descarga el CSV completado para revisar seis decisiones o el archivo de cabeceras para tu propio registro. Añade URL, entorno, hora UTC, referencias, alcance, confianza, responsable, vencimiento, estado y resultado de repetición. El HTML es independiente y se puede imprimir. Esta página no guarda auditorías en una cuenta ni analiza dominios introducidos.
Abre el resumen con alcance y decisiones necesarias; sigue con prioridades, pruebas, dependencias y plan de cierre. Declara controles aplazados. No presentes el ejercicio como auditoría de cliente ni inventes mediciones. Un análisis más amplio puede requerir renderizado, internacionalización, datos estructurados, accesibilidad y rendimiento.
Separa los controles técnicos del rendimiento
La aptitud técnica y el rendimiento observado responden a preguntas distintas. Usa el informe de posiciones para exportaciones fechadas de consultas/páginas y la auditoría de backlinks para enlaces de origen. Una página funcional puede no estar indexada. Cambios de clics no prueban un fallo canonical ni el efecto de una compra de enlaces.
Informe de posicionamiento SEO: compara visibilidad y entiende los promedios
Cómo hacer una auditoría de backlinks: pruebas, prioridades y plantilla