Coincidencia de perfiles sameAs - Docs de MetricSpot

Qué comprueba esta verificación

Parsea el array sameAs de tu JSON-LD de Organization (o Person, LocalBusiness) y, para cada URL:

Lanza un HEAD y luego un GET y confirma una respuesta 2xx (siguiendo una redirección).
Escanea el HTML de destino buscando el nombre de tu marca (el name o alternateName del mismo JSON-LD).

La comprobación falla si alguna URL devuelve 404, redirige a un dominio no relacionado, o resuelve en una página cuyo contenido visible no menciona la marca. Esta es una comprobación distinta de sameAs de perfiles sociales, que solo verifica que el array exista.

Por qué importa

El sentido completo de sameAs es decirle a Google “estas URLs se refieren todas a la misma entidad del mundo real que este sitio web”. Cuando una de esas URLs está rota, el merge de entidades falla — Google no puede conectar con confianza “Acme Inc en LinkedIn” con tu sitio si la URL de LinkedIn devuelve 404, y no puede conectar “Acme Industries Ltd” con tu página “Acme Inc” si el slug de LinkedIn se renombró y ahora pertenece a otra empresa.

El coste de un sameAs roto es silencioso. Tus datos estructurados siguen validando. Rich Results Test sigue mostrándolo en verde. Pero el Knowledge Graph se niega calladamente a atribuirte el perfil — y los Knowledge Panels, los carouseles de marca y la procedencia de las citas de agentes IA se apoyan en esa atribución.

Las roturas más comunes, en orden aproximadamente decreciente de frecuencia:

Migración Twitter → X. Los perfiles aún resuelven en twitter.com (Twitter redirige), pero algunos arrays sameAs apuntan a sub-rutas que se rompieron. Usa siempre https://x.com/handle.
Renombres de slug /company/ de LinkedIn. Cuando una empresa cambia de marca, el slug viejo 404. La redirección por ID numérico de /company/ es más estable pero fea.
Perfiles muertos olvidados en el array. Entradas de Google+ de 2018. Vine. Periscope. Audita y poda.
Redirecciones de dominio vanity que tiran el path. acme.co/twitter → https://x.com/ (sin handle). Enlaza siempre la URL canónica del perfil directamente.
Desliz en mayúsculas/minúsculas. Algunas plataformas devuelven 404 ante una capitalización incorrecta en el slug. Prueba lo que pegas.

Cómo arreglarlo

1. Audita el array — bucle con curl:

curl -s https://yourdomain.com/ \
  | grep -oE '"sameAs":\s*\[[^]]+\]' \
  | grep -oE 'https?://[^"]+' \
  | while read url; do
      code=$(curl -s -o /dev/null -w '%{http_code}' -L -A 'Mozilla/5.0' "$url")
      echo "$code  $url"
    done

Lo que devuelva 4xx o 5xx está muerto. Lo que haga un 3xx hacia un hostname distinto es sospechoso — ábrelo en el navegador y confirma que el destino aún representa a tu marca.

2. Audita el array — script en navegador. Pégalo en la consola de DevTools en tu home:

const ld = [...document.querySelectorAll('script[type="application/ld+json"]')]
  .map(s => { try { return JSON.parse(s.textContent); } catch { return null; } })
  .filter(Boolean)
  .flatMap(o => Array.isArray(o) ? o : [o]);

const sameAs = ld.flatMap(o => o.sameAs || []);
console.table(sameAs);

await Promise.all(sameAs.map(async url => {
  try {
    const r = await fetch(url, { mode: 'no-cors' });
    console.log(r.type === 'opaque' ? 'opaque' : r.status, url);
  } catch (e) {
    console.error('FAIL', url, e.message);
  }
}));

CORS hará que muchas respuestas sean opacas, pero los fallos de red (DNS, 5xx) siguen apareciendo como errores. Para un código de estado limpio, usa el bucle de curl de arriba.

3. Validador de Schema.org. Pega tu URL en validator.schema.org — saca a la luz errores de parseo de JSON-LD y muestra el array sameAs resuelto. Útil cuando tu CMS está estropeando el JSON.

4. Mantén un handle canónico estable por plataforma. Elige una URL por perfil y úsala en todas partes — en sameAs, en tu footer, en tu firma de email, en notas de prensa. Las formas canónicas que envejecen bien:

LinkedIn: https://www.linkedin.com/company/<slug> (no /in/, no el ID numérico, no una redirección localizada /de.linkedin.com).
X / Twitter: https://x.com/<handle> (la forma twitter.com aún redirige, pero x.com es canónica ahora).
YouTube: https://www.youtube.com/@<handle> (la forma moderna con handle, no /channel/UCxxxx ni /user/xxxx).
GitHub: https://github.com/<org> (sin barra final).
Wikipedia: la URL inglesa en.wikipedia.org aunque tengas variantes de idioma — las URLs por idioma no son la entidad canónica.
Mastodon: https://<instance>/@<handle> (la URL federada, no un ID con hash).

5. Tras arreglarlo, valida dos veces. Ejecuta el Schema Markup Validator para la sintaxis y luego el Google Rich Results Test para confirmar que Google puede traer y parsear el JSON-LD. El Rich Results Test corre desde una IP de Google — si un objetivo sameAs bloquea al user agent de Googlebot o al país, fallará ahí aunque tu curl tuviera éxito.

Ver también: sameAs de Organization, sameAs de perfiles sociales, enlaces a perfiles sociales.

Preguntas frecuentes

¿Cada cuánto debería auditar mi array sameAs?

Dos veces al año es suficiente para la mayoría de sitios. Las plataformas renombran slugs (especialmente LinkedIn) y los perfiles se abandonan. Añade el bucle de curl de arriba a tu checklist de release o a un job de monitorización programado — son 30 segundos.

Mi URL de LinkedIn redirige a una página de “empresa no encontrada” pero devuelve 200. ¿La comprobación pasa?

Depende. El paso de coincidencia del nombre de marca existe precisamente para cubrir este caso — LinkedIn devuelve 200 con un body genérico de “esta página no existe”, así que el scan del nombre falla y la regla salta. Actualiza la URL al /company/<slug> actual o quítala.

Evítalas. Si Googlebot no puede traer la página de forma anónima, no puede confirmar la entidad. La mayoría de plataformas sociales grandes renderizan una shell pública del perfil sin auth — si la tuya no lo hace, ese perfil no sirve como objetivo sameAs.