Cómo configurar Google Search Console desde cero

Search Console no tiene datos históricos. Empieza a recogerlos el día que verificas la propiedad y no hay forma de pedirle lo anterior: si el sitio lleva dos años publicando y lo verificas hoy, esos dos años no existen. No hay copia de seguridad, no hay importación y no lo avisa nadie. Por eso la configuración no es un trámite que se deja para cuando haya tiempo. Es la única tarea de este oficio cuyo coste crece cada día que pasa sin hacerla.

¿Cómo se configura Google Search Console?

Verificando la propiedad y eligiendo entre dominio o prefijo de URL, que es la decisión que condiciona todo lo demás. Un sitio nuevo debe darla de alta antes de necesitarla, porque los datos empiezan el día de la verificación; uno de autoridad media suele necesitar las dos formas; uno consolidado, además, permisos por persona.

Respuesta rápida

• La decisión que más pesa es el tipo de propiedad. Dominio cubre todo; prefijo de URL cubre solo esa dirección exacta.
• Los datos empiezan el día de la verificación. Lo anterior no se recupera de ninguna manera.
• La verificación por DNS es la que menos se rompe. Los archivos y las etiquetas desaparecen en cualquier rediseño.
• Verificar solo www o solo https es el error clásico, y deja la mitad del sitio sin medir.

Qué tipo de decisión es esta

El modelo mental habitual trata la configuración como papeleo: pegar un código, ver la marca verde y pasar a lo interesante. Bajo ese modelo, la elección entre tipos de propiedad parece un detalle técnico sin consecuencias.

Lo que decide en realidad es qué parte de tu sitio vas a poder ver durante los próximos años. Una propiedad de prefijo de URL verificada sobre https://www.ejemplo.com/ no muestra nada de https://ejemplo.com/ sin www, ni de http://, ni de blog.ejemplo.com. Si el sitio sirve por varias de esas direcciones, estás mirando una parte y creyendo que es el total.

Y como los datos no se recuperan, el error no se arregla el día que se descubre. Se arregla a partir de ese día, con un hueco permanente detrás.

Paso 1: elegir el tipo de propiedad

La de dominio es la que conviene por defecto. Agrupa todos los subdominios y los dos protocolos bajo una sola vista, así que no hay forma de dejarse una variante fuera. Su única exigencia es la verificación por DNS, que requiere acceso al panel donde está registrado el dominio.

La de prefijo de URL tiene un uso legítimo y estrecho: medir una sección por separado. Un blog dentro de un sitio corporativo, o una tienda que quiere sus informes aparte, se benefician de una propiedad acotada a esa ruta.

Nada impide tener las dos. La de dominio para la visión completa y una de prefijo para la sección que se está trabajando es una combinación razonable.

Detalle que importa al automatizar. Si vas a leer los datos por API, el identificador de la propiedad tiene que escribirse exactamente como aparece en la interfaz. Una propiedad de prefijo se identifica con la URL completa, con protocolo, con www si lo lleva y con barra final; una de dominio se identifica con el prefijo sc-domain:. Un identificador mal escrito no da un error claro: devuelve una lista vacía, que es mucho más difícil de diagnosticar.

Paso 2: verificar

Cinco métodos, y no valen lo mismo.

Registro DNS (TXT). El más robusto y el único disponible para propiedades de dominio. Sobrevive a rediseños, migraciones de plantilla y cambios de gestor de contenidos, porque vive fuera del sitio.

Archivo HTML subido a la raíz. Funciona y es frágil. Un despliegue que limpia la carpeta se lo lleva por delante, y la verificación se pierde sin avisar.

Etiqueta HTML en la cabecera. Igual de frágil: desaparece con cualquier cambio de plantilla.

Google Analytics o Tag Manager. Cómodos si ya están instalados, y dependen de que sigan estándolo con la misma cuenta.

La recomendación que se deduce de esa lista: DNS siempre que se pueda, aunque implique pedirle el acceso a quien gestione el dominio. Los otros métodos funcionan el primer día y fallan el día que menos conviene.

Paso 3: enviar el sitemap

En Sitemaps, se envía la ruta del archivo, normalmente /sitemap.xml. Sirve para declarar qué URL existen y para que el informe muestre cuántas de las declaradas están indexadas, que es una comparación útil.

Conviene tener claro qué no hace: declarar una URL en el sitemap no la hace importante. Eso lo hace el enlazado interno. En una auditoría propia había 35 páginas huérfanas declaradas todas en el sitemap, con unas 180.000 impresiones al trimestre a las que la estructura interna no llegaba.

Paso 4: dar acceso a quien lo necesite

En Configuración, dentro de Usuarios y permisos. Hay tres niveles y la diferencia importa:

• Propietario: puede todo, incluido quitar a otros.
• Completo: ve todo y puede actuar, pero no gestiona usuarios.
• Restringido: solo lectura de la mayoría de informes.

Para un consultor externo o para una herramienta que solo lee datos, Restringido es suficiente y es lo que conviene conceder. Dar propiedad a un tercero es una decisión difícil de deshacer si la relación termina mal.

Cuándo NO hace falta tocar nada más

Cuando la propiedad ya está verificada, es de dominio y el sitemap está enviado. A partir de ahí, Search Console no requiere mantenimiento: requiere lectura. Y leerlo mal es más fácil de lo que parece, con tres errores de método que se detallan en cómo leer Search Console sin sacar conclusiones falsas.

Lo que el informe junta y no deja separar

Conviene saberlo antes de abrir el primer informe, porque evita toda una categoría de conclusión equivocada.

Google documenta que el tráfico de sus funciones de IA, incluidos los AI Overviews y el Modo IA, sí se incluye en el informe de rendimiento, dentro del tipo de búsqueda web. Un clic desde un resumen hacia una página externa cuenta como clic, y las páginas que aparecen cuentan como impresiones.

Lo que no existe es ningún filtro para separarlo. Llega mezclado con el resto y no hay forma publicada de aislarlo. Las dos conclusiones equivocadas son simétricas: ni falta, ni se puede partir.

Y un detalle que cambia cómo se leen las posiciones: un AI Overview ocupa una única posición, y todos los enlaces que contiene reciben esa misma. No hay un primero ni un tercero dentro del resumen, y por eso la posición media es mala señal para detectarlo.

Qué mirar la primera semana, y en qué orden

Dar de alta la herramienta no sirve de nada si después se abre el informe equivocado. El orden que rinde es este.

El informe de páginas, que dice cuántas están indexadas y por qué no lo está el resto. Es la única pregunta que importa el primer mes, y su recorrido de diagnóstico está en por qué Google no indexa mi página.

El sitemap, para comprobar que se está declarando lo que uno cree: sitemap XML, con lo que puede estar bloqueando el rastreo en robots.txt.

Las acciones manuales, que son dos minutos y cierran media conversación sobre caídas: penalización de Google.

Y el informe de rendimiento, que es el que más se mira y el que peor se lee, con los tres errores de método en Google Search Console y el caso de las páginas con impresiones y sin clics en estás primero y no recibes clics.

Cuando hay una página concreta que corregir y reenviar, el procedimiento está en pedir indexación.

Errores que se repiten

• Dejarlo para más adelante. Cada día sin verificar es un día de datos que no existirá nunca.
• Verificar solo www o solo https. Deja fuera las demás variantes sin avisar.
• Verificar por archivo HTML. El primer despliegue que limpie la raíz se lo lleva.
• Confundir sitemap con importancia. Declara que la URL existe, no que valga algo.
• Dar permiso de propietario a un externo. Cómodo hoy, incómodo al terminar la relación.
• Escribir mal el identificador al usar la API. No da error: devuelve una lista vacía.

Datos y transparencia

Que el tráfico de las funciones de IA se incluye en el informe de rendimiento dentro del tipo de búsqueda web, que los clics desde AI Overviews y el Modo IA cuentan como clics, y que un AI Overview ocupa una única posición con todos sus enlaces en ella, procede de la documentación pública de Google sobre funciones de IA y sobre el informe de rendimiento, comprobada el 12 de agosto de 2026. No hay documentado ningún filtro para separar ese tráfico.

Los tipos de propiedad, los métodos de verificación y los tres niveles de permiso corresponden a la documentación pública y a la interfaz de Google Search Console vigentes a agosto de 2026. El detalle sobre el formato exacto del identificador de propiedad al consultar la API procede de trabajo propio con una credencial de solo lectura sobre ocho propiedades reales, todas de tipo prefijo de URL. El caso de las 35 páginas huérfanas con unas 180.000 impresiones al trimestre procede de una auditoría propia sobre un recetario de 312 páginas; es trabajo de cliente y el sitio no se nombra. No se cita ningún plazo de aparición de los primeros datos tras verificar: varía y Google no lo publica. Verificado a agosto de 2026.

Lo que esto cambia

Casi todas las tareas de este oficio se pueden posponer sin coste. Esta no.

Un artículo que no se escribe hoy se escribe en octubre y rinde igual. Una auditoría que se retrasa un trimestre encuentra los mismos defectos. Pero un mes sin Search Console verificado es un mes que no vas a poder mirar nunca, ni tú ni quien te contrate dentro de dos años para averiguar qué pasó. La configuración no es la parte aburrida que hay que superar antes de lo interesante: es la única decisión de la lista que tiene fecha de caducidad.

Preguntas frecuentes