Desenvolvimento Web para SEO: Outro Quase Vai para o Sul

Última atualização em 14 de setembro de 2018

É por isso que você tem uma empresa de SEO, como Essa! Empresa, para detectar e corrigir o que está errado com o redesenho de um site existente. Como qualquer pessoa que trabalha no setor de marketing na Internet e passou por uma reconstrução de um site funcional sabe, uma infinidade de coisas podem dar errado. Recentemente, um cliente de PPC (pagamento por clique) e SEO (otimização para mecanismos de pesquisa) acabou de reconstruir seu site e o lançou sem permitir a revisão. Esta última reconstrução do site deste cliente deu terrivelmente errado no lançamento, então vou tocar em algumas das coisas esperadas e inesperadas que podem e podem dar errado.

A necessidade

Este cliente comprou uma empresa existente que tinha um site informativo e de comércio eletrônico existente e era líder em seu setor. O desenvolvedor web não veio com a compra. Por algum motivo nunca revelado para mim, o cliente não conseguiu atualizar nenhuma página fora do carrinho de compras. O carrinho de compras não era compatível com dispositivos móveis e pudemos ver a diferença em suas conversões de computador para dispositivos móveis. As conversões em dispositivos móveis eram praticamente inexistentes. A esmagadora maioria de suas vendas on-line estava sendo gerada por pesquisa orgânica de desktop, PPC, visitas diretas e de referência.

Muitos dos elementos necessários para melhorar seu SEO, também não estavam lá. Não há capacidade de alterar metadados, tags h1, tags alt/title, etc. A maioria desses dados estava sendo gerada programaticamente; bem como os menus e a estrutura de navegação. Este novo site também precisaria ser seguro. Em suma, o que eles precisavam era de um novo site e carrinho de compras seguro e amigável para dispositivos móveis com um conector para trabalhar com seu pacote de software de planejamento de recursos empresariais (ERP) existente.

A missão

Esse cliente tinha 3.766 palavras-chave com resultados de classificação nas cem principais SERPs do Google. Quinhentas e trinta e oito (538) palavras-chave com resultados da página 1, com um volume médio de pesquisa mensal de 65.790 e 43 palavras-chave classificadas na primeira posição nas SERPs do Google, que tiveram um volume médio de pesquisa mensal de 6.110. Meu trabalho era orientá-los através dos requisitos que um novo sistema de administração precisaria fornecer para a capacidade de implementar o SEO no futuro. Isso também incluiu proteger seus resultados de classificação existentes da melhor forma possível.

A seleção

O cliente finalmente selecionou um fornecedor offshore que pudesse fornecer a integração entre seu software ERP existente e uma nova solução e site de carrinho de compras seguro e amigável para dispositivos móveis. Não estando familiarizado com esse fornecedor offshore, o cliente me forneceu uma demonstração do produto gravada para confirmar que o sistema de administração forneceria o que precisávamos para implementar o SEO. Após análise da demonstração, concluí que tínhamos os elementos necessários para auxiliar o cliente com melhorias de SEO. Poderíamos criar nossos próprios títulos de página, meta descrições e tags h1. Poderíamos atualizar o código do Google Analytics (GA), do qual eles estavam executando o código GA antigo e desatualizado e nenhuma conta do Search Console. Tivemos acesso às imagens para adicionar texto alt/title devidamente formatado. Como descobrimos mais tarde, e muito tarde, havia até a capacidade de aplicar o redirecionamento 301 diretamente em cada página. Mas isso é apenas parte da história.

O resultado

Como se vê, o desenvolvedor forneceu um modelo, carrinho de compras e integração de ERP. O cliente foi encarregado de mover o conteúdo (copiando o conteúdo antigo do site e colando em uma nova página no sistema de administração), incluindo os metadados existentes. Eles também foram encarregados de inserir os URLs do site antigo nos dados da nova página, página por página. Acontece que isso foi complicado pelo fato de o cliente não poder copiar e colar os URLs do site antigo intactos. O cliente tomou isso como procedimento operacional padrão e não notificou ninguém sobre isso. Originalmente, recomendamos que o desenvolvedor criasse um arquivo de redirecionamento 301 adequado. O cronograma de lançamento não permitiu que o cliente nos deixasse revisar a operação adequada. Eles acabaram de lançar e foi aí que tudo deu errado.

Ao perceber que o site reconstruído havia sido lançado, começamos a testar manualmente os resultados de classificação de palavras-chave originais em relação aos resultados de classificação atuais. Só para ver como era o novo site e que todos os dados foram transferidos. Todos os resultados de classificação nas SERPs do Google que ainda estavam em vigor resultaram em um código de resposta 404, exceto a página inicial. Acontece que as URLs do site antigo foram criadas com extensões .html e as novas URLs não. O sistema de administração simplesmente não permitiu que a URL antiga fosse colada no campo de redirecionamento 301 fornecido, então o cliente colou a URL antiga sem a extensão .html. O cliente tinha assumido que este era um procedimento operacional padrão.

Após muita discussão interna, descobrimos que, se você removesse a extensão .html, as páginas redirecionariam corretamente para a versão segura do novo URL, na maioria dos casos. No entanto, em alguns casos, o URL antigo, sem a extensão .html, redirecionaria para um novo URL, muito pouco amigável para mecanismos de pesquisa, contendo uma string de consulta que nunca tínhamos visto antes. Em um exame mais aprofundado, descobrimos que esse novo URL desconhecido estava sendo gerado pela navegação no menu principal. Assim, tivemos um redirecionamento de um para um, na maioria dos casos, do URL antigo, extensão .html removida, para o novo URL amigável do mecanismo de pesquisa seguro e fomos capazes de navegar para o mesmo conteúdo da navegação principal que gerou o novo não -URL amigável.

Conteúdo duplicado? Bem, a tag canônica rel= foi colocada, você pode perguntar? Corretamente? Não. A tag rel=canonical no URL redirecionado amigável do mecanismo de pesquisa foi definida para apontar para o novo URL não amigável do mecanismo de pesquisa que contém a string de consulta. Ao examinar a tag rel=canonical da página não amigável, descobrimos que essa tag fazia referência a um URL totalmente diferente. Um contendo a categoria e não a string de consulta. Portanto, um conteúdo estava sendo exibido para três URLs diferentes, com tags rel=canonical configuradas incorretamente.

Em seguida, descobrimos que todos os bots não foram permitidos no arquivo robots.txt. Em seguida, verificamos a atividade no GA. O cliente ainda estava recebendo visitas de todas as origens, mas não registrava nenhuma conversão. Além disso, o cliente queria que pudéssemos enviar o rastreamento e a indexação que exigem o Search Console do Google. O problema aqui é que o código GA existente era antigo e nunca houve um código de verificação do Search Console colocado no site. Este é um daqueles itens que o cliente não poderia alterar por motivos nunca divulgados.

Felizmente, o cliente aceitou nossa recomendação de implementar a atualização do código GA para a versão mais recente. Por conta própria, eles também adicionaram o gerenciador de tags do Google. Ops! Possivelmente disparo duplo do código GA? Com o Gerenciador de tags do Google e o código GA assíncrono atualizado, conseguimos criar uma nova conta do Search Console segura (https x http) para o cliente e descobrimos que não havia um sitemap .xml para enviar para um rastreamento solicitado .

Após a notificação, o cliente se comunicou com o desenvolvedor e recebeu dois URLs de mapa do site .xml. Um funcionou. Um não. O de trabalho tinha uma entrada que apontava para o mapa do site .xml que não funcionava. O mapa do site .xml que não funcionava não tinha a formatação adequada quando visualizado em um navegador. Portanto, não enviamos o mapa do site .xml fornecido no momento.

O resultado final

Notificamos o cliente, por meio de e-mails encenados, sobre o que estávamos encontrando. Primeiro, a questão dos redirecionamentos com falha e descobrimos que, se removêssemos a extensão .html, eles redirecionariam corretamente. O cliente notificou o desenvolvedor e o desenvolvedor respondeu que não foi possível colocar a extensão .html na ferramenta de redirecionamento 301 fornecida. Outras descobertas revelaram que o cliente havia descoberto isso e achava que esse era um procedimento operacional padrão.

Por alguma razão, o site original foi excluído (grande oopsy aqui, sempre tenha uma versão funcional pronta para usar) para que não pudéssemos extrair nenhum dos URLs antigos para criar um novo redirecionamento 301 permanente através do arquivo .htaccess. A resolução foi criar uma nova correspondência de um para um, URL antigo x URL novo, planilha, extraindo os dados da página de destino do GA para o ano passado, para que o desenvolvedor criasse um redirecionamento funcionando corretamente substituindo o redirecionamento 301 no sistema de administração que foi encarregado no cliente.

Problema resolvido com custo adicional para o cliente do desenvolvedor. Todos os resultados de classificação antigos existentes com uma extensão .html começaram a ser redirecionados corretamente e, em 14 dias, os resultados de classificação foram substituídos pelos novos URLs seguros e, na maioria das vezes, muito próximos do resultado de classificação pré-existente. O problema da tag rel=canonical foi resolvido em uma reunião online com o agente de vendas do desenvolvedor da Web e resultou em erro de entrada do usuário. Havia vários campos onde os dados podiam ser inseridos ou selecionados a partir de uma escolha existente e a solução exigia redefinir esses campos e limpar o cache.

As duas versões adicionais do URL amigável e seguro desapareceram imediatamente. Em relação ao bot /disallow no robots.txt, após notificação, o desenvolvedor resolveu rapidamente esse problema.

Verificou-se que o problema com os dados de conversão do GA parece ser isolado para o provedor de serviços do comerciante do cliente; que era novo e diferente do antigo provedor. Ninguém pensou em comunicar ao provedor de serviços do comerciante que precisávamos do código GA em sua página de checkout para fornecer os dados de comércio eletrônico necessários que o cliente precisa para tomar decisões de negócios informadas sobre seus esforços de marketing. Não fomos informados da existência de um novo provedor de serviços comerciais.

Por fim, criamos manualmente um arquivo de mapa do site .xml que queríamos que fosse carregado no servidor e solicitamos que o desenvolvedor desative o que quer que estivesse criando o mapa do site .xml que não funcionava. Em uma discussão mais aprofundada com o agente de vendas do desenvolvedor, fomos informados de que não poderíamos fazer upload de outro sitemap .xml para o servidor.

Depois de mostrar os resultados ao agente de vendas do desenvolvedor, ele afirmou que analisaria, no entanto, sugeriu que visualizássemos o código-fonte. Ao visualizar no código-fonte, o documento .xml foi formatado corretamente. Ao ver esse resultado, notificamos o Google, via Search Console, que de fato tínhamos um sitemap .xml funcionando. Finalmente, ao longo de vários dias, o Google finalmente registrou que tínhamos um sitemap .xml funcionando e começou a mostrar URLs sendo indexados. No entanto, como dito anteriormente, o mapa do site .xml formatado corretamente tinha apenas uma entrada apontando para o mapa do site .xml adicional que não seria resolvido em um navegador, mas exibido corretamente no código-fonte.

Bem, esse problema se tornou um problema maior, pois o sitemap .xml adicional gerou um código de resposta 500, portanto, há um problema com o agente do Google acessando essa área do site. E, a partir de hoje, os dois sitemaps .xml estão gerando 500 códigos de resposta. Na semana anterior, havíamos solicitado um rastreamento usando a ferramenta de busca, renderização e envio disponível no Google Search Console, que acreditamos ter causado o rastreamento e a indexação do novo site.

Então, para encerrar, se puder dar errado, dará, ao reconstruir seu site e, com sorte, você poderá evitar alguns desses erros. Bloquear os bots no arquivo robots.txt e redirecionar de forma inadequada pode colocá-lo fora do negócio online ou, pelo menos, em perigo. Se os bots não puderem rastrear seu site, você sairá do índice e, quando sair do índice, a menos que venham de referências, diretas ou outras fontes não orgânicas, a maioria das visitas de pesquisa orgânica se tornará inexistente.

Se os resultados não redirecionarem corretamente, os visitantes orgânicos poderão ver seu site como não confiável. Os clientes existentes que têm seu site salvo como favorito podem ficar frustrados quando seus favoritos não são redirecionados corretamente. Sem mencionar que tivemos que encerrar sua campanha de PPC nesse meio tempo. Clicar em um anúncio pago e obter uma resposta de página 404 não encontrada não é apenas frustrante para seus visitantes, é caro! O clique custa dinheiro e você não obtém retorno do seu investimento. E, é por isso que você nos tem.

– Mark Gray, Gerente Sênior de SEO