Propiedad de dominio o prefijo de URL en Search Console

Si quieres una respuesta directa: crea una propiedad de dominio siempre que puedas modificar los registros DNS del dominio, y añade propiedades de prefijo de URL solo para los casos concretos en los que necesitas un recorte más pequeño o no tienes acceso al DNS. La propiedad de dominio agrupa en una sola vista todas las variantes del sitio, mientras que la de prefijo de URL solo ve lo que empieza exactamente por la dirección que registraste.

La diferencia parece técnica, pero cambia las cifras que ves. Mucha gente abre Search Console, registra `https://www.tusitio.com/`, y después descubre que los clics no coinciden con los de un compañero que registró otra variante. Nadie se equivocó con los datos: cada propiedad mide un territorio distinto. Este artículo explica qué incluye cada tipo, cómo se verifica, por qué aparecen datos en una y no en la otra, y cómo decidir sin arrepentirte después.

Qué ve cada tipo de propiedad

Una propiedad de dominio se identifica solo por el nombre del dominio, por ejemplo `tusitio.com`, sin protocolo ni ruta. Incluye todas las URL de ese dominio: las versiones `http` y `https`, con y sin `www`, y cualquier subdominio como `blog.tusitio.com`, `tienda.tusitio.com` o `m.tusitio.com`, incluidos los que crees en el futuro. No tienes que hacer nada cuando aparece un subdominio nuevo: sus datos entran solos.

Una propiedad de prefijo de URL se define con una dirección completa, como `https://www.tusitio.com/`. Solo recoge las URL que empiezan exactamente por ese prefijo. Eso significa que `http://www.tusitio.com/`, `https://tusitio.com/` y `https://blog.tusitio.com/` quedan fuera, cada una es otra propiedad distinta a ojos de Search Console. También puedes registrar un prefijo con ruta, como `https://www.tusitio.com/blog/`, y entonces solo verás esa carpeta.

Piensa en la propiedad de dominio como un paraguas y en la de prefijo como una ventana. El paraguas es cómodo cuando quieres la foto completa; la ventana es útil cuando quieres enfocar una parte, o cuando solo te dejan mirar por ahí.

Por qué una propiedad de dominio muestra datos que un prefijo no

La causa más habitual de que dos propiedades del mismo sitio den cifras distintas es el reparto de variantes. Google indexa y muestra en resultados una dirección canónica, pero durante meses o años pueden haber circulado enlaces, campañas y resultados con otras variantes. Si tu prefijo es la versión `https://www`, los clics que llegaron por una URL `http` o sin `www` se contabilizan en otra propiedad que quizá nunca registraste, y por tanto nunca viste.

Esto se nota sobre todo en tres situaciones. La primera es una migración a HTTPS mal cerrada: si quedan páginas indexadas con `http`, ese tráfico no aparece en el prefijo `https`. La segunda es un cambio de `www` a dominio sin `www` (o al revés): durante la transición, parte del rendimiento vive en cada variante. La tercera son los subdominios olvidados: un antiguo `blog.` o un `m.` que todavía recibe impresiones y que un prefijo de la raíz jamás refleja.

Hay un matiz importante. La propiedad de dominio no inventa tráfico ni mejora tu posición; simplemente agrega lo que ya ocurría en todas las variantes. Si de pronto ves muchos más clics al crearla, no es un aumento de rendimiento, es que por fin estás midiendo todo. Conviene anotarlo, porque al comparar periodos puedes interpretar como crecimiento lo que es un cambio de alcance de la medición.

También existen informes que dependen del tipo de propiedad. El informe de estadísticas de rastreo, por ejemplo, solo está disponible en propiedades de dominio y en propiedades de prefijo situadas en la raíz de un host. Si intentas abrirlo desde un prefijo con ruta, como `/blog/`, no lo encontrarás. Es un detalle que solo descubres cuando diagnosticas problemas de rastreo y necesitas ver qué protocolos, hosts y tipos de respuesta recibe Googlebot.

Cómo se verifica una propiedad de dominio: DNS

La propiedad de dominio solo admite verificación por DNS. La lógica es coherente: como abarca todo el dominio y todos sus subdominios, Google necesita una prueba que también abarque todo el dominio, y el registro DNS es lo único que lo demuestra. Subir un archivo a una carpeta de un servidor no probaría nada sobre los demás subdominios.

El proceso es breve. Al crear la propiedad, Search Console te muestra un registro `TXT` con un valor único. Lo copias y lo añades en la zona DNS de tu dominio, en el panel de tu registrador o de tu proveedor de DNS, con el host en blanco o `@`, según el panel. Después vuelves a Search Console y pulsas verificar. Para algunos proveedores Google ofrece alternativamente un registro `CNAME`; el efecto es el mismo.

Si la verificación falla justo después de añadir el registro, casi siempre es propagación. Los cambios de DNS pueden tardar desde minutos hasta horas en ser visibles, sobre todo si el registro anterior tenía un TTL largo. Antes de sospechar de un error, comprueba con una consulta DNS externa que el `TXT` ya se resuelve públicamente, y vuelve a intentarlo más tarde.

Tres errores frecuentes merecen mención:

• Añadir el registro en un proveedor de DNS que no es el autoritativo: si los servidores de nombres apuntan a otro servicio (por ejemplo, un CDN), el registro debe crearse allí, no en el registrador.
• Pegar el valor con comillas dobles o espacios extra que el panel no espera, o sobrescribir un `TXT` existente en lugar de añadir uno nuevo. Un dominio puede tener varios `TXT`; no borres los de correo (SPF, DKIM) al añadir el de verificación.
• Eliminar el registro después de verificar. Mientras quieras conservar la propiedad, el registro debe seguir ahí; si desaparece, la verificación se pierde en una comprobación posterior y la propiedad queda sin acceso.

Cómo se verifica un prefijo de URL: HTML y otras opciones

El prefijo de URL es más flexible porque admite varios métodos. Los más usados son la subida de un archivo HTML, la metaetiqueta en la cabecera, el código de Google Analytics, el contenedor de Google Tag Manager y también el propio DNS. Esta flexibilidad es la razón principal por la que los prefijos siguen siendo útiles.

El archivo HTML consiste en descargar un pequeño archivo que te proporciona Search Console y subirlo a la raíz del sitio, de modo que sea accesible en una dirección como `https://www.tusitio.com/google1234abcd.html`. Es rápido si tienes acceso FTP o al gestor de archivos del hosting. El inconveniente es que debe conservarse en el servidor; si una migración o un despliegue lo borra, pierdes la verificación sin darte cuenta.

La metaetiqueta se pega dentro del `head` de la página de inicio. Es cómoda en sistemas de gestión de contenidos donde puedes editar la plantilla o usar un complemento, pero depende de que la plantilla no se reemplace. Una actualización de tema que elimine la línea rompe la verificación.

Analytics y Tag Manager reutilizan un código que ya tienes instalado. Solo funcionan si la cuenta desde la que verificas tiene permisos suficientes sobre esa propiedad de Analytics o ese contenedor. Son buena opción cuando no controlas el hosting pero sí las etiquetas del sitio, por ejemplo en una agencia que gestiona el marketing del cliente.

Un consejo práctico: verifica con un método que no dependa del código de la web que otros equipos pueden tocar. Si varias personas despliegan cambios, el DNS o un archivo protegido en la raíz suelen sobrevivir mejor que una etiqueta en una plantilla.

Cómo decidir: un árbol de decisión sencillo

Empieza por una pregunta: ¿puedes editar el DNS del dominio, tú o alguien a quien se lo puedas pedir en un correo? Si la respuesta es sí, crea la propiedad de dominio. Es la opción que más información te da con menos mantenimiento, y te protege de los olvidos de variantes y subdominios.

Si la respuesta es no, por ejemplo porque el dominio lo gestiona un departamento de TI que tarda semanas, o porque es un cliente que no sabe dónde está su DNS, empieza por un prefijo de URL de la variante canónica y verifícalo por HTML o metaetiqueta. No esperes semanas por una propiedad perfecta cuando puedes empezar a diagnosticar ya. Más adelante, cuando consigas el DNS, añade la propiedad de dominio sin quitar la anterior.

Estos son los escenarios típicos y qué suele convenir:

• Sitio pequeño con un solo host: una propiedad de dominio; si quieres, un prefijo de la versión canónica como comodín.
• Sitio con blog o tienda en subdominios: propiedad de dominio para el total, más prefijos por subdominio si cada equipo necesita su propio acceso.
• Sitio grande con secciones gestionadas por equipos distintos: propiedad de dominio para SEO central y prefijos por carpeta (`/es/`, `/blog/`, `/productos/`) para repartir permisos y leer cada sección sin ruido.
• Sin acceso al DNS: prefijo de URL con HTML o etiqueta, y propiedad de dominio cuando sea posible.
• Migración de dominio o de protocolo: ambas, antes de empezar, para tener el historial de las variantes implicadas.

Usar ambas a la vez: permisos, límites y buenas prácticas

No es una elección excluyente. Registrar la propiedad de dominio y, además, uno o varios prefijos es una práctica común y no genera conflicto ni datos duplicados en el sentido problemático: cada propiedad mide por su cuenta y puedes consultar la que prefieras. Lo único que debes evitar es sumar cifras de dos propiedades que se solapan, porque contarías dos veces el mismo clic. El total correcto sale de la propiedad más amplia, no de añadir las más pequeñas.

Los permisos también funcionan por propiedad. El propietario verificado puede añadir usuarios completos o restringidos. Una ventaja de los prefijos por carpeta es que puedes dar a un redactor o a un equipo regional acceso solo a los datos de su sección sin mostrarle el resto del sitio. La propiedad de dominio, en cambio, da visión global, así que reserva ese acceso para quien lo necesite.

Algunas prácticas que evitan problemas futuros:

• Documenta quién verificó cada propiedad y con qué método. Cuando alguien abandona la empresa y su cuenta desaparece, una verificación que dependía de ese usuario puede perderse.
• Añade al menos dos propietarios verificados, preferiblemente con cuentas corporativas y no personales.
• Verifica con dos métodos distintos en un prefijo, por ejemplo HTML y metaetiqueta, para que un despliegue que rompa uno no te deje sin acceso.
• Conserva el registro `TXT` del DNS aunque ya hayas verificado por otra vía; es el que menos se toca por accidente.
• Al cambiar de dominio, no elimines las propiedades antiguas: necesitas seguir viendo cómo se transfieren las señales y si quedan URL antiguas recibiendo impresiones.

Errores habituales al elegir y leer las propiedades

El primero es comparar cifras entre una propiedad de dominio y un prefijo sin recordar que miden alcances distintos. Si un informe mensual usa un prefijo y el siguiente usa el dominio, el salto que verás no es real. Elige una propiedad de referencia para tus informes y mantenla.

El segundo es crear solo un prefijo `http` por inercia de hace años. Hoy la mayoría de sitios funcionan en HTTPS, pero hay propiedades antiguas que siguen con la variante equivocada y muestran datos casi vacíos. Si una propiedad parece muerta, antes de concluir que el sitio no recibe tráfico revisa que el prefijo coincida con la variante que realmente se indexa.

El tercero es olvidar que la verificación puede caducar. Si tu propiedad deja de mostrar datos o pierdes acceso de repente, revisa el estado de verificación: un archivo borrado, una etiqueta eliminada o un registro DNS retirado son las causas más comunes.

El cuarto es esperar que la propiedad de dominio arregle problemas de indexación. No lo hace. Es una herramienta de medición y diagnóstico; que veas más datos no cambia cómo Google rastrea o posiciona tus páginas. Su valor está en darte una visión fiel, sin huecos, para decidir con datos completos.

Por último, conviene recordar que hay datos que Search Console no conserva de forma indefinida. Si el historial de rendimiento es importante para ti, exporta los datos periódicamente o conéctalos a una hoja de cálculo o almacén propio. Crear la propiedad de dominio cuanto antes te permite revisar y exportar los datos de todas las variantes antes de que caduquen.