Un informe de auditoría GEO útil permite decidir qué cambiar, quién lo hará y cómo se comprobará la entrega. La portada puede ser estupenda; lo que necesita desarrollo es una URL, una observación y una prueba concreta. Si el informe termina en «mejorar autoridad» o «optimizar para la IA», todavía falta traducir el diagnóstico a trabajo que alguien pueda presupuestar.
Esta plantilla de informe GEO para 2027 organiza ese paso. Incluye un registro de evidencias, prioridades, tres tickets ficticios y una muestra real de HTML público tomada en octubre de 2026. El año identifica la edición de planificación. Para acordar el encargo, consulta nuestro servicio de auditoría e implementación de GEO técnico (EN).
Empieza por las páginas y decisiones que importan
Delimita el mercado, los idiomas y las páginas prioritarias. Una empresa puede querer explicar una especialidad, entrar en una comparación de proveedores o corregir información corporativa. Cada objetivo necesita fuentes y observaciones diferentes. Escribe qué decisión comercial debería poder tomar el lector de cada página.
Indica sistemas incluidos, acceso disponible y fecha de la muestra. Un examen del HTML público no equivale a revisar registros del servidor, Search Console o respuestas de varios motores. Esa delimitación permite entender qué compra el cliente y qué parte necesitará un acceso o una fase adicional.
El resumen ejecutivo puede ocupar una página: objetivo, tres hallazgos respaldados, decisiones requeridas y siguiente entrega. Si la muestra no descubre tres problemas, dilo. Completar una lista por estética produce tareas de relleno y pone al desarrollador a resolver problemas que el informe todavía no ha demostrado.
Separa observación, interpretación y cambio propuesto
Una observación describe algo recibido o comprobado: respuesta HTTP, canonical declarado, texto encontrado, enlace o captura de una respuesta identificada. La interpretación explica por qué merece atención. El cambio propuesto es una hipótesis de intervención que debe contrastarse con la arquitectura y el objetivo de la página.
Por ejemplo, encontrar un canonical hacia otra URL no demuestra por sí solo un error. Puede ser una decisión deliberada para contenido equivalente. El ticket debe pedir revisar esa intención y documentar el destino previsto antes de cambiarlo. Una recomendación puede quedar pendiente de decisión y seguir siendo útil.
La documentación de Google sobre canonicals describe señales de preferencia. El HTML declarado y la selección que hace Google son observaciones distintas. El informe debe identificar cuál ha revisado, sin convertir una etiqueta encontrada en prueba de indexación.
Usa un registro de evidencias que se pueda reconstruir
Asigna un identificador a cada prueba y enlázalo desde los hallazgos. Guarda la URL exacta, fecha, método, condiciones y resultado. Conserva el archivo o extracto necesario para que otra persona compruebe la observación. Una huella ayuda a reconocer un archivo; no acredita por sí sola que el método fuera adecuado.
| Campo | Contenido esperado | Uso en el informe |
|---|---|---|
| Referencia | Identificador, URL, idioma y tipo de página | Relacionar hallazgo y fuente |
| Captura | Hora, método, sesión y entorno | Delimitar qué se observó |
| Resultado | Valor recibido, archivo o extracto y huella si procede | Permitir una revisión independiente |
| Límite | Accesos, estados o sistemas que no se comprobaron | Evitar conclusiones más amplias que la prueba |
| Relación | Hallazgo, ticket, responsable y siguiente comprobación | Convertir evidencia en trabajo |
Minimiza los datos del archivo compartido. Un registro de red o una captura puede contener identificadores, información personal o contenido de una cuenta. Acuerda quién necesita el original, qué extracto puede circular y dónde se guarda. El informe ejecutivo normalmente necesita la conclusión y su referencia, no una sesión completa.
Muestra real: tres respuestas públicas en octubre de 2026
El 25 de octubre de 2026, a las 03:17 UTC, solicitamos una vez tres páginas públicas en inglés de The GEO Company. Utilizamos peticiones HTTP ordinarias sin autenticación ni ejecución de JavaScript. Guardamos el HTML y su huella. La muestra describe esas respuestas; no inspeccionó robots.txt, un rastreador autenticado, el índice de Google ni una respuesta de IA.
| Referencia y página | HTTP y canonical | Encabezado y noindex observado |
|---|---|---|
| O01 · Servicio técnico (EN) | 200; canonical a la URL solicitada | Un H1; sin noindex en las etiquetas o cabecera examinadas |
| O02 · Coste de auditoría (EN) | 200; canonical a la URL solicitada | Un H1; sin noindex en las etiquetas o cabecera examinadas |
| O03 · Checklist técnica (EN) | 200; canonical a la URL solicitada | Un H1; sin noindex en las etiquetas o cabecera examinadas |
Esos controles acotados no detectaron un desvío respecto al estado previsto. El siguiente resultado del informe es conservar la referencia y definir las comprobaciones que faltan. No hemos convertido tres respuestas correctas en un porcentaje de «preparación para IA». Tampoco acreditan que Google haya indexado o citado esas páginas.
Para repetir la muestra, utiliza las mismas URL, método y campos y conserva la nueva hora. Si cambia el HTML, revisa qué diferencia es relevante. Una fecha, un menú o un recurso dinámico pueden alterar la huella sin afectar al contenido que se quería comprobar.
Prioriza por consecuencia, alcance y dependencia
Relaciona cada hallazgo con una tarea del comprador y una población de páginas comprobada. Un bloqueo accidental de un servicio prioritario puede requerir atención inmediata; un ajuste editorial menor puede entrar en la siguiente entrega. No asignes valor económico a partir de la longitud de una lista de avisos.
Explica las dependencias. Una corrección de datos requiere que alguien apruebe el dato; un cambio de plantilla puede necesitar desarrollo y publicación coordinada. Agrupa por causa compartida cuando haya evidencia: seis URL afectadas por la misma regla pueden formar un ticket con seis comprobaciones.
Usa estados comprensibles: pendiente de confirmación, listo para desarrollo, bloqueado por acceso, aplicado y pendiente de verificación, o cerrado. «Aplicado» conserva una diferencia importante respecto a «verificado». La prioridad debe ayudar a ordenar esas decisiones, no disimular la incertidumbre con un decimal.
Convierte cada hallazgo aprobado en un ticket ejecutable
Incluye síntoma, evidencia, comportamiento previsto, componente responsable, alcance del cambio y prueba de aceptación. Define qué debe conservarse: idiomas, permisos, contenido aprobado o reglas deliberadas de exclusión. Añade un responsable de la revisión y una condición de reapertura.
Estos tres tickets son ficticios. Ejecutamos nueve comprobaciones locales sobre fragmentos HTML: estado previo, propuesta correcta y propuesta incorrecta para cada ticket. El ejercicio demuestra el funcionamiento de esas comprobaciones de texto y enlaces. No modifica una web ni prueba indexación, diseño renderizado, hreflang completo o citas.
| Ticket | Encargo acotado | Comprobación local |
|---|---|---|
| F01 · Canonical | Usar el destino aprobado para un servicio de ejemplo | El parser exige exactamente el canonical inglés acordado; rechaza el destino español |
| F02 · Texto | Publicar una capacidad ficticia aprobada como texto | Encuentra “Batch traceability reports”; rechaza otro texto o una imagen sin ese pasaje |
| F03 · Idioma | Enlazar la página catalana equivalente de ejemplo | Exige su URL exacta; rechaza la página española y el inicio catalán |
En los nueve controles, el estado previo y la propuesta incorrecta incumplieron el criterio definido, y la propuesta correcta lo cumplió. Ese resultado permite enseñar una prueba de cierre pequeña. La aceptación real debe ampliar el método cuando intervengan respuestas de servidor, relaciones recíprocas, contenido visible o decisiones del buscador.
Revisa idiomas y decisiones editoriales por separado
Un ticket con traducciones necesita especificar los equivalentes publicados. Una página de inicio no sustituye automáticamente a un servicio ausente. La referencia de Google para versiones localizadas explica las relaciones entre alternativas; el enlace F03 del ejemplo comprueba únicamente un destino.
Define además quién adapta el contenido. Si una capacidad, precio o cobertura cambia por mercado, conservar la misma frase puede introducir un error. Desarrollo puede resolver la relación de páginas y el equipo responsable del negocio debe aprobar los hechos. Cierra ambos trabajos con evidencias adecuadas a su función.
Separa entrega técnica y evolución de visibilidad
La entrega técnica se comprueba después de publicar el cambio. La visibilidad necesita sus propias observaciones posteriores: páginas, consultas, preguntas, idiomas, periodo y método estables. Anota otros cambios relevantes. Una respuesta que menciona la marca es una muestra; no acredita por sí sola el efecto de un ticket.
La guía oficial de Google sobre funciones de IA mantiene los fundamentos SEO y no garantiza inclusión por cumplir requisitos. Evita prometer una cita como criterio de aceptación de una corrección HTML. Para estudiar respuestas y fuentes, utiliza la guía de auditoría de visibilidad LLM.
Una ficha desarrollada: del canonical observado al cambio aprobado
Amplía F01 como ejercicio de encargo. La ficha identifica un servicio ficticio en inglés y conserva el fragmento anterior con un canonical hacia una página antigua. El responsable de contenido confirma que ambas páginas tienen finalidades distintas y aprueba la URL propia del servicio. Esa decisión es la dependencia que permite preparar el cambio.
Desarrollo identifica dónde se genera la etiqueta: configuración editorial, plantilla o una regla compartida. El ticket solicita corregir aquella fuente e inspeccionar páginas representativas de su alcance. Editar únicamente el HTML descargado superaría la comprobación del ejemplo, pero no cambiaría lo que publica el sitio. La implementación real debe actuar sobre el componente responsable.
La aceptación del encargo comprueba la respuesta publicada, el canonical esperado y los controles que debían conservarse. Si hay caché, incluye una comprobación después de su actualización. El revisor adjunta evidencia nueva a la misma ficha y deja la selección posterior de Google como seguimiento independiente. Un resultado técnico correcto puede cerrarse sin inventar un cambio de posición.
La reversión también necesita un límite. Volver a una plantilla anterior puede afectar a otras páginas; restaurar una base de datos puede sobrescribir contenido reciente. Identifica quién autoriza cada opción y qué material se conserva. El informe puede recomendar esa preparación sin afirmar que ya existe una copia restaurable.
Preguntas que conviene resolver antes de aceptar el informe
¿Una muestra de tres URL representa toda la web?
Representa esas observaciones bajo las condiciones registradas. Para ampliar el alcance, define grupos de plantillas, idiomas, tipos de contenido y excepciones. Explica cómo se seleccionan las URL y qué conclusiones pueden generalizarse con la evidencia disponible. No conviertas la muestra de este artículo en una auditoría completa de The GEO Company.
¿Quién decide si una recomendación entra en desarrollo?
El responsable asignado revisa evidencia, intención editorial, dependencias y coste previsto. Puede aprobar, pedir una prueba adicional, posponer o rechazar con motivo documentado. Una lista de recomendaciones no autoriza automáticamente cambios en producción. Guarda la decisión junto al hallazgo para que la siguiente persona entienda por qué se actuó.
¿Qué recibimos si la implementación queda fuera del presupuesto?
Un inventario delimitado, evidencias accesibles, hallazgos priorizados y tickets que permitan estimar la fase siguiente. Aclara si se incluye una reunión con desarrollo o revisión de propuestas posteriores. Esos entregables tienen valor propio cuando otro proveedor puede utilizarlos sin repetir desde cero toda la investigación.
Contrata una entrega que tu equipo pueda utilizar
Al comparar propuestas, pide el inventario incluido, una muestra de hallazgo, el formato de tickets y las pruebas previstas. Pregunta qué parte es diagnóstico, cuál incluye implementación y quién valida el cierre. El coste de una auditoría GEO técnica en 2027 desarrolla esas diferencias de alcance.
Conserva la checklist de GEO técnico como referencia de controles y utiliza este informe para gestionar la entrega. Para solicitar una evaluación técnica (EN), comparte dominio, tres páginas prioritarias, mercado, idiomas y próximo cambio previsto. El mejor informe es el que deja al equipo con una decisión clara y trabajo que sabe cómo terminar.