Introdução

Este é a PARTE 2 de um conjunto de artigos que resolvi escrever sobre atividades de UX/UI, SEO e de Analytics que devemos ter em consideração antes de lançar ou relançar um website. Podem consultar a PARTE 1 – Checklist de Atividades de UX/UI para (Re)Lançamento de um Website – 12 Atividades a Considerar.

Neste artigo as atividades descritas dizem respeito ao novo website. Mas devemos ter em conta que há um trabalho prévio a fazer ainda no website antigo, se estivermos a falar de um redesign. Por exemplo, fazer um crawl a todo o website para se perceber se existem questões a resolver por exemplo com redirecionamentos de páginas; verificar a tag da ferramenta de Analytics e verificar problemas no Google Search Console – GSC.

Depois existem atividades a fazer no novo site, mas no seu ambiente de desenvolvimento que serão uma salvaguarda que devemos ter antes do novo website ser lançado. Mas vamos então ver em mais detalhe cada uma dessas atividades.

1.Crawl do Website

  • O que é: Rastrear todos os URLs de um website, através de uma ferramenta específica para o efeito, como a Screaming Frog ou a SEMRush.
  • Para que serve: O rastreamento do website serve para percebermos se existem problemas nalguma página e, é a atividade base ao mapeamento dos URLs para conseguirmos fazer os seus redirecionamentos.
  • Quais são os seus componentes: Como componentes principais a analisar num crawl a um website temos: as Metadatas, os broken links, os links to follow e os atributos HTML ALT tag imagens
  • Quem deve estar envolvido: Equipas de SEO e se necessário equipas de desenvolvimento.
  • Ambientes onde se implementa: Website antigo, staging do website novo e após o website ser lançado convêm fazer novo crawl para despistar quaisquer problemas.
  • Entregáveis: Documento com os principais findings de problemas de SEO Técnico encontrados e respetivas recomendações. E também deve ser produzido um Excel com os URLs do website antigo para se poderem mapear os novos URLs.

 

2. Instalação da Ferramenta de Analytics

  • O que é: Em regra, é um snippet code em JS que se instala no código fonte, logo depois do <header>.
  • Para que serve: OA ferramenta de analytics irá servir para medir aquilo que os utilizadores fazem no website, via dispositivos fixos ou mobile.
  • Quais são os seus componentes: nd. No entanto, é preciso relembrar que se estivermos a configurar esta tag no website em produção, já com o site lançado, é boa prática:
    • Conectar o website ao Google Search Console
    • Conectar o Google Signals no GA4
  • Quem deve estar envolvido: Equipas de SEO e se necessário equipas de desenvolvimento.
  • Ambientes onde se implementa: Website antigo e staging do website novo.
  • Entregáveis: Sendo uma atividade de configuração de uma ferramenta, pode haver um entregável da equipa de SEO para as equipas técnicas que será o seu Guia de Implementação. Por exemplo Guia de Implementação do Google Tag Manager no website e respetiva tag do GA4.

 

3. Mapeamento dos URLs e Redirecionamentos das Páginas

  • O que é: Os redirecionamentos das páginas significam que vamos ter que apontar os novos endereços URL do website antigo para os correspondentes no website novo ou redesenhado, se os houver.
  • Para que serve: Os Se não houver um mapeamento dos URLs do website antigo e do website novo, corremos o risco de termos páginas com erro 404 no novo website o que, para além de provocar uma péssima experiência para o utilizador, provocará graves problemas de indexação e ranking dessa ou dessas páginas..
  • Quais são os seus componentes: Não existem componentes, mas devo fazer a ressalva de não esquecer de fazer o redirecionamento da página com “www.” Para a página sem o “www”, bem como o redirecionamento do scheme protocolo “http://“ que o servidor deve ler, para as páginas com o scheme protocolo de segurança “https://“ que o servidor deve ler.
  • Quem deve estar envolvido: Equipas de SEO e se necessário developers front-end ou hack-end.
  • Ambientes onde se implementa: Os mapeamentos devem ser feitos no website antigo e os redirecionamentos devem ser implementados no ambiente de Staging do website novo e confirmados no ambiente de produção após lançamento do website.
  • Entregáveis: Mapa em Excel com os URLs do website antigo e respetiva correspondência no website novo, bem como a expressão regular (ou não) para que essa implementação possa ser feita ao nível do servidor

 

4. Testar a Velocidade do Website e a sua Responsividade

  • O que é: Os testes de velocidade são testes feitos à velocidade de carregamento dos conteúdos das páginas do website. Os testes de responsividade são testes de adaptação desses mesmos conteúdos a cada dispositivo em que esse mesmo website pode ser carregado, visto pelo utilizador. Por norma e maioritariamente fazem-se testes de responsividade para desktop, mobile e tablet..
  • Para que serve: Os testes de velocidade ao website devem ser feitos por forma a minimizar impactos na experiência do utilizador e no ranking (Core Web Vitals) do website novo.
  • Quais são os seus componentes: nd.
  • Quem deve estar envolvido: Equipas de SEO com auxílio das equipas de desenvolvimento no caso de querermos interpretar os valores dos testes e perceber como corrigir os problemas.
  • Ambientes onde se implementa: Primeiros testes em ambiente de staging e confirmação no ambiente de produção após lançamento do website.
  • Entregáveis: Documento com os principais findings de problemas de velocidade e de responsividade – SEO Técnico encontrados e respetivas recomendações.

 

5. Desenho e Implementação da Página de Erro 404 e 500

  • O que é: As páginas de erro 404 e 500 são páginas informativas que o website apresenta quando algo se passa ao nível do carregamento das páginas ou ao nível do servidor e que não permite aos utilizadores visualizarem ou acederem ao website.
  • Para que serve: Se pensarmos bem, as páginas de erro de um website, sejam elas erros 404 ou erro 500 não deveriam existir. Não faz sentido haverem erros e os mesmos serem apresentados ao utilizador. Mas havendo erros, por algum motivo que até podemos não controlar ao início, devemos apresentar aos utilizadores uma página de erro com informação esclarecedora sobre o erro, o porquê do erro estar a acontecer e sugestões de páginas no website que podem visitar enquanto o erro não se resolve. E, por último, acrescentaria os contactos da Empresa.
  • Quais são os seus componentes: nd.
  • Quem deve estar envolvido: Equipas de UX/UI, equipas de desenvolvimento e auxílio/acompanhamento das equipas de SEO.
  • Ambientes onde se implementa: Deve-se começar a desenhar esta página para o ambiente staging do website e confirmar no ambiente de produção após lançamento do website se a mesma ficou implementada, criando e testando um erro, por exemplo no servidor.
  • Entregáveis: O Protótipo e versão final das páginas de erro 404 e 500.

 

6. Implementação da tag HTML Href Lang*

  • O que é: A tag Href Lang é uma tag HTML que se coloca no código fonte do website dentro das tags <head></head>.
  • Para que serve: A tag Href Lang informa o Google que diferentes idiomas ou versões de países da mesma página estão relacionados, para que ele possa fornecer o conteúdo certo aos utilizadores.
  • Quais são os seus componentes: Não existem. Mas uma tag Href Lang tem esta configuração: <link rel=”alternate” hreflang=”es” href=”http://es.xpto.pt/” />
  • Quem deve estar envolvido: Equipas de desenvolvimento com acompanhamento das equipas de SEO.
  • Ambientes onde se implementa: Esta tag deve ser implementada no ambiente de staging do website novo e confirmada no ambiente de produção após lançamento do website.
  • Entregáveis: nd.

 

7. Configuração e Implementação do Open Graph*

  • O que é: O Open Graph é um protocolo de internet que foi originalmente criado pelo Facebook para padronizar a utilização de metadados numa página de um qualquer website para representar o seu conteúdo.
  • Para que serve: Como visto acima, o Open Graph permite padronizar a utilização de metadados numa página de um qualquer website para representar o seu conteúdo.
  • Quais são os seus componentes: Podemos ter o Open Graph que irá ser lido pelo Google e para diferentes redes sociais, como o Facebook, Twitter, Linkedin, por exemplo. Eis na prática uma tag sobre o Open Graph para um website: <!– xpto.com !–> <meta property=“og:type” content=“profile”/>
  • Quem deve estar envolvido: Equipas de desenvolvimento com acompanhamento das equipas de SEO.
  • Ambientes onde se implementa: Esta tag deve ser implementada no ambiente de staging do website novo e confirmada no ambiente de produção após lançamento do website.
  • Entregáveis: nd.

 

8. Fazer Testes de Cross Browser

  • O que é: Os testes de cross browser são testes feitos ao website em ferramentas que simulam o ambiente de renderização específico de cada browser (Chrome, Sfari, IE…).
  • Para que serve: Os browsers interpretam e renderizam o html dos websites de formas diferentes e isso faz com que o layout das páginas e o seu conteúdo possa ser bem renderizado e, consequentemente, bem visto pelo utilizador que utiliza o Chrome, mas tal pode já não acontecer num Opera. Então, estes testes servem para verificar discrepâncias na renderização das páginas e dos seus conteúdos por parte dos diferentes browsers.
  • Quais são os seus componentes: nd.
  • Quem deve estar envolvido: Equipas de SEO com acompanhamento (para implementação de correções) das equipas de desenvolvimento.
  • Ambientes onde se implementa: Os testes de Cross browser devem ser feitos no ambiente staging do website e, posteriormente e após o lançamento do website, confirmar em produção que não existem erros/desformatações do website nalgum browser, por exemplo numa qualquer versão do IE ou do Edge.
  • Entregáveis: Documento com os principais findings de problemas de cross-browser – SEO Técnico – encontrados e respetivas recomendações.

 

9. Especificações de Headings das Páginas para SEO

  • O que é: São os principais componentes do conteúdo das diferentes páginas do website, no que ao copy diz respeito. Para cada uma dessas páginas do website funcionam como os títulos principais e secundários (headings) de um índice de um documento.
  • Para que serve: À semelhança daquilo que acontece com a Arquitetura de Informação, a definição dos Headings de páginas para SEO serve para os utilizadores e os motores de pesquisa entenderem a arquitetura/hierarquia de informação das diferentes páginas, através deste processo específico de organização e rotularem de elementos – títulos, sub-títulos e parágrafos de texto. Também serve, em termos de acessibilidade, para os utilizadores poderem ler, com os screen readers, e perceber como está construída a página.
  • Quem deve estar envolvido: Equipas de UX e equipas de SEO
  • Quais são os seus componentes: Considero que os componentes dos Headings para SEO podem ir desde o atributo HTML <H1> até ao <H6> e para textos poderemos estar a falar de atributos HTML <p>. Mas por norma, uma página de um website, em princípio, não terá mais do que 2 ou 3 atributos destes, ou seja terá um atributo H1 e depois tudo atributos H2 ou uma mescla entre atributos H2 e atributos H3.
  • Ambientes onde se implementa: Os headings devem ser definidos logo na fase de design das páginas do website. E devem ser feitos no ambiente staging do website e, posteriormente e após o lançamento do website, confirmar em produção que não existem erros.
  • Entregáveis: O entregável desta atividade pode ser o protótipo onde em cada titulo de página e/ou subtítulo devem estar especificados que tipo de Headings devem ser considerados no desenvolvimento dessa página pelos front-end developers. Pode também ser construído de raíz um documento de especificações, em que deverá ter uma secção que contemple as especificações de headings de SEO para os diferentes títulos, sub-títulos e textos das diferentes páginas do novo website Documento composto pelas diferentes páginas do novo website.

 

10. Implementação do Favicon

  • O que é: É a imagem ícone que se encontra no separador de cada um dos browsers e antes do Page Title, na história de websites pesquisados e que o browser guarda ou nos bookmarks. É uma imagem de 16×16 pixels.
  • Para que serve: O objetivo do favicon, para mim, é o de auxiliar o utilizador a “descobrir” o nosso website no meio de várias tabs abertas no browser.
  • Quais são os seus componentes: nd
  • Quem deve estar envolvido: Equipas de UX, de UI e de desenvolvimento e/ou SEO para implementação
  • Ambientes onde se implementa: Deve ser implementado no ambiente staging do website e, posteriormente e após o lançamento do website, confirmar em produção que está OK, sem alterações.
  • Entregáveis: Ficheiro png do Favicon

 

11. Verificação e Implementação de Políticas de Privacidade e Consentimentos

  • O que é: As Políticas de Cookies, tal como as Políticas de Privacidade são guidelines de como a Empresa irá armazenar (e utilizar) a informação e outros dados dos seus utilizadores e devem estar em concordância, se estivermos a falar de um website europeu, com o Regulamento Geral de Proteção de Dados – RGPD. Relativamente aos Consentimentos, são opções dadas aos utilizadores para eles aceitarem ou não; concordarem ou não com as Políticas e/ou com a configuração por default dos cookies gerados no website
  • Para que serve: Existem 2 grandes objetivos na redação destas Políticas: 1 – Proteger os utilizadores; 2 – Cumprir com os regulamentos legais em vigor nos diferentes países em que o website tem utilizadores. Sobre os consentimentos, por norma servem para salvaguardar qualquer tipo de tratamento de dados que a empresa faça, por exemplo, quando um utilizador preenche e submete um formulário.
  • Quais são os seus componentes: nd. No entanto é importante perceber que existem 5 tipos de cookies:
    • First-parte cookies – São cookies “gerados” pelo próprio website quando o utilizador o visita
    • Third-party cookies – São cookies “gerados” por terceiros. Ou seja, são “gerados” por domínios que não são visitados diretamente pelos utilizadores
    • Cookies de Sessão – São cookies que expiram imediatamente ou alguns segundos depois dos utilizadores saírem do browser.
    • Cookies Persistentes – São cookies que ao contrário dos cookies anteriores permanece no browser durante um determinado período de tempo
    • Cookies de Segurança – São cookies “gerados” apenas por websites que utilizam o protocolo de segurança https://

Todos estes cookies devem ser mencionados na Política de Cookies e que devem, também, ser bloqueados de alguma forma, caso os utilizadores não aceitem os mesmos no pop-up de consentimento que deve estar disponível logo que um utilizador abra um website.

  • Quem deve estar envolvido: Equipas DPO, Conteúdos e de SEO
  • Ambientes onde se implementa: As Políticas e Consentimento devem ser implementadas no ambiente staging do website e, posteriormente e após o lançamento do website, testadas em produção, nomeadamente no pop-up de consentimento e no envio de formulários, para que não existam erros.
  • Entregáveis: Documentos escritos e preparados para colocar nas respetivas páginas do website sobre Política de Privacidade e Política de Cookies.

 

12. Criação do Sitemap

  • O que é: O sitemap é um ficheiro xml ou xmls que contêm toda a estrutura de URLs, sejam de categorias de páginas, páginas, ficheiros e afins de todo o website.
  • Para que serve: ÀA grande vantagem de um website ter um sitemap é para os motores de pesquisa terem mais facilidade em ler, indexar e encontrar as diferentes páginas desse mesmo website. Por norma, é muito mais importante que um website com muitas páginas tenha um sitemap, do que um que tenha 10, 20 ou 30 páginas.
  • Quem deve estar envolvido: Equipas SEO e de desenvolvimento
  • Quais são os seus componentes: nd.
  • Ambientes onde se implementa: Ambiente de produção e upload no Google Search Console para uma indexação mais rápida.
  • Entregáveis: Sitemap

 

13 . Criação do ficheiro Robots.txt

  • O que é: O robots.txt é um arquivo de texto com instruções para os robot dos motores de pesquisa sobre quais páginas eles podem e não podem rastrear.
  • Para que serve: Este ficheiro serve para “facilitar” a vida aos motores de pesquisa e para pouparmos “crawl budget”.
  • Quem deve estar envolvido: Equipas de SEO em conjunto com as equipas de desenvolvimento.
  • Quais são os seus componentes: As instruções são especificadas por “allow” (permitir) ou “disallow” (não permitir) o comportamento de determinas (ou todos) bots.
  • Ambientes onde se implementa: Ambiente de produção.
  • Entregáveis: Ficheiro Robots.txt e colocá-lo na raíz do website

 

Conclusão

Tal como visto na PARTE 1 deste conjunto de artigos, lançar um website ou relançar um website dá muito trabalho. Implica muito tempo e muitas atividades. E no que respeita a atividades de SEO ou relacionadas, acredito que a lista acima é um excelente ponto de partida. Contudo, queria deixar mais umas pistas:

Podemos sempre e testar e implementar 1 – o Schema Markup, de forma a tornar mais robusto o website no que respeita à “searchability” e indexação pelos motores de pesquisa e prepará-lo de alguma forma para as pesquisas por voz; 2 – Fazer o teste de indexação do website diretamente nos motores de pesquisa.

A próxima parte do artigo que será vista em 2023, será sobre as atividades a considerar no (re)lançamento de um website. Fiquem atentos!

 

Want to read this article in English? Please click here

uncode-placeholder