Correspondência de perfis em sameAs

O que esta verificação faz

Faz parse ao array sameAs do teu JSON-LD Organization (ou Person, LocalBusiness) e, para cada URL:

Emite um HEAD e depois um GET e confirma uma resposta 2xx (seguindo um redirecionamento).
Procura na HTML de destino o nome da tua marca (o name ou alternateName do mesmo JSON-LD).

A verificação falha se algum URL devolver 404, redirecionar para um domínio não relacionado, ou resolver para uma página cujo conteúdo visível não menciona a marca. Esta é uma verificação separada de sameAs nos perfis sociais, que apenas confirma que o array existe.

Porque é importante

O ponto principal do sameAs é dizer à Google “estes URLs referem-se todos à mesma entidade real do mundo que este site.” Quando um desses URLs está partido, a fusão de entidade falha — a Google não consegue ligar com confiança “Acme Inc no LinkedIn” ao teu site se o URL do LinkedIn devolve 404, e não consegue ligar “Acme Industries Ltd” à tua página “Acme Inc” se o slug do LinkedIn foi renomeado e agora pertence a outra empresa.

O custo de um sameAs partido é silencioso. Os teus dados estruturados ainda validam. O Rich Results Test ainda mostra verde. Mas o Knowledge Graph recusa silenciosamente atribuir o perfil — e os Knowledge Panels, carrosséis de marca e proveniência de citações de agentes de IA todos se apoiam nessa atribuição.

As quebras mais comuns, por ordem aproximadamente decrescente de frequência:

Migração de URL Twitter → X. Os perfis ainda resolvem em twitter.com (o Twitter redireciona), mas alguns arrays sameAs apontam para sub-caminhos que partiram. Usa sempre https://x.com/handle.
Renomes de slug /company/ no LinkedIn. Quando uma empresa muda de marca, o slug antigo dá 404. O redirecionamento por ID numérico /company/ é mais estável mas feio.
Perfis defuntos deixados no array. Entradas do Google+ de 2018. Vine. Periscope. Audita-e-poda.
Redirecionamentos de domínio vanity que deixam cair o caminho. acme.co/twitter → https://x.com/ (sem handle). Liga sempre o URL canónico do perfil diretamente.
Drift de capitalização. Algumas plataformas devolvem 404 em capitalização incorreta no slug. Testa o que colas.

Como corrigir

1. Audita o array — ciclo curl:

curl -s https://oteudominio.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

Qualquer coisa que devolva 4xx ou 5xx está morto. Qualquer coisa que faça 3xx-redirect para um hostname diferente é suspeita — abre no navegador e confirma que o destino ainda representa a tua marca.

2. Audita o array — script de navegador. Cola na consola DevTools da tua 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 vai tornar muitas respostas opacas, mas falhas de rede (DNS, 5xx) ainda aparecem como erros. Para um código de estado limpo, corre o ciclo curl acima.

3. Validador Schema.org. Cola o teu URL em validator.schema.org — expõe erros de parse JSON-LD e mostra o array sameAs resolvido. Útil quando o teu CMS está a estropiar o JSON.

4. Mantém um handle canónico estável por plataforma. Escolhe um URL por perfil e usa-o em todo o lado — em sameAs, no rodapé, na assinatura de email, em comunicados de imprensa. As formas canónicas que envelhecem bem:

LinkedIn: https://www.linkedin.com/company/<slug> (não /in/, não o ID numérico, não um redirecionamento localizado /de.linkedin.com).
X / Twitter: https://x.com/<handle> (a forma twitter.com ainda redireciona, mas x.com é o canónico agora).
YouTube: https://www.youtube.com/@<handle> (a forma moderna de handle, não /channel/UCxxxx e não /user/xxxx).
GitHub: https://github.com/<org> (sem barra final).
Wikipedia: o URL inglês en.wikipedia.org mesmo que tenhas variantes de idioma — URLs específicos de idioma não são a entidade canónica.
Mastodon: https://<instance>/@<handle> (o URL federado, não um ID hashado).

5. Depois de corrigir, valida duas vezes. Corre o Schema Markup Validator para sintaxe, depois o Google Rich Results Test para confirmar que a Google consegue ir buscar e fazer parse ao JSON-LD. O Rich Results Test corre a partir do IP da Google — se um alvo sameAs bloqueia o user-agent do Googlebot ou o país, falhará lá mesmo que o teu curl tenha tido sucesso.

Vê também: organization sameAs, sameAs nos perfis sociais, ligações para perfis sociais.

Perguntas frequentes

Com que frequência devo auditar o meu array sameAs?

Duas vezes por ano chega para a maioria dos sites. As plataformas renomeiam slugs (LinkedIn especialmente) e perfis são abandonados. Adiciona o ciclo curl acima à tua checklist de release ou a um job de monitorização agendado — é uma verificação de 30 segundos.

O meu URL do LinkedIn redireciona para uma página “empresa não encontrada” mas devolve 200. A verificação passa?

Depende. A verificação faz o passo da correspondência do nome da marca exatamente para apanhar este caso — o LinkedIn devolve 200 com um corpo genérico “esta página não existe”, pelo que o scan do nome da marca falha e a regra dispara. Atualiza o URL para o /company/<slug> atual ou remove-o.

Evita-os. Se o Googlebot não consegue ir buscar a página anonimamente, não consegue confirmar a entidade. A maioria das plataformas sociais grandes renderiza um shell público do perfil sem auth — se a tua não o faz, esse perfil não é útil como alvo sameAs.