Corrigir uma URL canônica apontando para staging

Como o sintoma aparece

Toda página no site ao vivo serve uma canônica nomeando um host diferente:

curl -s https://example.com/pricing | grep -i 'rel="canonical"'
<link rel="canonical" href="https://staging.example.com/pricing">

O Search Console mostra isso como "Duplicada, o Google escolheu uma canônica diferente da do usuário", ou como páginas saindo com uma canônica declarada pelo usuário em um host que você nunca verificou. Como o host de staging normalmente é inacessível, protegido por senha ou com noindex, não há um destino para a consolidação chegar, então as páginas ao vivo simplesmente param de ranquear um rastreamento de cada vez. Nada devolve 500 e nenhuma verificação de uptime percebe, o que é o que torna isso caro.

De onde vem a URL base errada

• Um banco de dados restaurado de staging. No WordPress, as linhas de opção siteurl e home carregam o nome de host de staging para a produção, e toda URL gerada as segue.
• Uma variável de ambiente no build implantado. Uma URL de site fixada no momento do build, então a saída compilada carrega o valor de staging não importa o que o ambiente de execução diga.
• Um host padrão de framework configurado por ambiente, onde a configuração de produção nunca foi atualizada depois de a de staging ter sido.
• Uma URL absoluta fixa em um layout compartilhado ou configuração de plugin de SEO, escrita durante uma migração e nunca revisitada.
• Uma página em cache construída no host errado. Uma CDN ou cache de página completa populado por um build de staging serve HTML desatualizado com a canônica de staging muito depois de a configuração ter sido corrigida.

Corrija o valor, depois elimine a classe de bug

1. Corrija a URL base armazenada para produção, em qualquer um dos lugares acima que se aplique. No WordPress, isso é as duas linhas de opção mais qualquer URL absoluta escrita no conteúdo de posts pela cópia de staging.
2. Reconstrua e reimplante se o valor está compilado. Mudar uma variável de ambiente sem um rebuild deixa o valor antigo no pacote entregue.
3. Limpe todo cache no caminho, aplicação, CDN e borda igualmente. Uma origem corrigida atrás de um cache cheio de HTML de staging parece não corrigida enquanto o cache existir.
4. Prefira derivar a canônica a partir do host da requisição em vez de ler uma constante armazenada. Uma canônica construída a partir do host que serviu a requisição não pode estar errada no ambiente em que foi servida, o que elimina a classe inteira de falha em vez de só essa instância dela.
5. Mantenha o staging fora do índice por outros meios. Autenticação HTTP ou uma lista de permissões de IP no host de staging é o que deveria protegê-lo, não uma canônica, e não um noindex que pode viajar junto com um arquivo de configuração.

Verifique a correção em produção

Leia a resposta, não o template, porque plugins, edge workers e caches todos injetam canônicas que não aparecem no seu repositório:

curl -s https://example.com/pricing | grep -i 'rel="canonical"'
curl -sI https://example.com/pricing | grep -i '^link:'

Depois verifique mais de uma página. A canônica é gerada por um template, então acertar a página inicial não prova nada sobre páginas de produto, listagens paginadas ou qualquer coisa renderizada por um layout diferente. No Search Console, a Inspeção de URL mostra a canônica declarada pelo usuário ao lado da que o Google selecionou, e as duas concordando depois de um recrawl é a confirmação que importa. Esse recrawl leva dias, então uma canônica corrigida não restaura o tráfego na mesma tarde.

Evite que isso volte a acontecer

Duas salvaguardas custam quase nada. A primeira é uma verificação no momento da implantação: depois de um release, busque um punhado de URLs de produção e falhe a implantação se qualquer canônica nomear um host diferente do de produção. A segunda é continuar observando depois, porque a falha tem a mesma chance de chegar junto com uma restauração de banco de dados ou uma configuração de plugin quanto com uma implantação de código. As verificações HTTP da HostTracker podem fazer asserções contra o corpo e os cabeçalhos da resposta, então uma verificação agendada pode ser configurada para falhar quando a tag canônica de uma página não é o que você espera, e essa falha alerta como qualquer outra.

Verifique todo template, não uma página

Comece com uma URL afetada na verificação gratuita de canônica: ela resolve a canônica e sinaliza a que aponta para outro host, que é exatamente a cara de uma canônica de staging. Depois veja se o problema é de uma página ou de um template inteiro olhando para todas de uma vez. A ferramenta gratuita de rastreamento de site percorre o site e reporta um status de canônica por URL, junto com as flags de noindex e os corpos duplicados que geralmente acompanham um deploy ruim. Para pegar a próxima no dia em que ela for publicada, ative a opção Indexability em um monitor HTTP para suas páginas-chave: ela lê a canônica a cada verificação e envia um aviso quando ela muda. O monitoramento de SEO explica como isso funciona.