seo

Introdução

Finalmente chegámos à PARTE 3 dos artigos sobre o tema de atividades a ter em consideração no (re) lançamento de um website. Na PARTE 1 – Checklist de Atividades de UX e de UI para (Re)Lançamento de um Website – 12 Atividades a Considerar, vimos as atividades na área de UX/UI que deveríamos considerar ao (re) lançarmos um website. E na PARTE 2 – Checklist de Atividades de SEO para (Re)Lançamento de um Website – 13 Atividades a Considerar, vimos as atividades na área de SEO que deveríamos considerar ao (re)lançarmos esse mesmo website.

Nesta PARTE 3, o objetivo é elencar, de forma não exaustiva, as atividades de analytics, foco no Google Analytics, que é necessário não esquecer quando estamos a (re) lançar um website.

Obviamente que à partida estou a considerar que os Objetivos de Medição estão estipulados e assimilados pelas áreas, bem como já existe um conhecimento daquilo que são os KPIs a monitorar e, consequentemente, existe um Plano de Medição na sua versão mais básica, uma vez que tudo o que irei descrever depois deverá ser pormenorizado no novo Plano de Medição.

1. Tags GTM – Google Tag Manager

• O que é: É um container JavaScript que nos permite implementar e incorporar diversas tags de medição daquilo que acontece no website.
• Para que serve: Recorrendo à implementação de tags via GTM vai-nos permitir não ter a necessidade recorrente de pedir a um developer para o fazer diretamente no código fonte do website e, portanto, também não vamos sobrecarregar o website com código javascript diminuindo a sua velocidade de carregamento de páginas.
• Quais são os seus componentes: nd. Ainda assim, quando estamos a criar as diferentes tags de medição, como por exemplo a tag de Google Analytics, é preciso ter em consideração que a tag em si, exige sempre a criação de um trigger que indica quando e onde se pretende despontar essa tag. Em tags mais complexas, pode ser necessário criar também algumas variáveis.
• Quem deve estar envolvido: Equipas de Analytics e se necessário equipas de desenvolvimento.
• Ambientes onde se implementa: WNovo website em ambientes de qualidade e de produção.
• Entregáveis: Documento com indicação de todos os elementos/eventos que se pretendem implementar no website; a descrição desses eventos; a prioridade que esse evento tem em relação aos restantes; se existe a necessidade de implementação de um pixel; e se existe a necessidade de recurso a um developer.

2. Reimplementação dos eventos GTM em GA3 para GA4 e reinterpretação dos goals em UA GA para conversões em GA4

• O que é: Os eventos desempenham um papel crucial no UA e no GA4. Mas a maneira como eles se denominam no UA é completamente diferente no GA4. Por esse motivo, não podemos simplesmente recriar os mesmos eventos na nova versão.

Os eventos no UA tinham uma estrutura hierárquica composta por category – action – label. No GA4, os eventos são diferenciados pelos nomes e podem ter vários parâmetros adstritos. É necessário fazer o mapeamento e traduzir a estrutura antiga para a nova estrutura de forma a garantir que os reports futuros sejam significativos.

Ainda dentro desta secção, podemos ter que reinterpretar os goals do GA3 para conversões no GA4. Uma grande mudança no GA4 é que todas as conversões são medidas por meio de eventos. No UA-GA, as conversões mais importantes provavelmente seriam baseadas em exibições de página. Isso significa que as metas que configurámos no UA-GA precisam ser reconfiguradas.

Mais uma vez, e em conjunto com os developers precisamos garantir que as conversões sejam rastreadas corretamente e seguir todas as alterações identificadas no plano de medição.

• Para que serve: Ao fazermos estes passos, vamos garantir que não perdemos tudo ou a grande maioria da informação que recolhemos no UA-GA

• Quais são os seus componentes: Devemos ter em atenção aos eventos, conversões, estruturas de e-commerce e audiências
• Quem deve estar envolvido: Equipas de Analytics e equipas de desenvolvimento.
• Ambientes onde se implementa: Novo website em ambientes de qualidade e de produção.
• Entregáveis: Documento com o mapeamento do que eram os eventos no UA-GA, e qual o seu nome agora no GA4; com as conversões no UA-GA e quais serão as mesmas no atual GA4.

3. Definição dos Eventos Recomendados e dos Custom Events

• O que é: No atual GA4 os tipos de eventos que existem são o seguintes:

Automatic Events – eventos coletados por defeito quando o GA4 é configurado no website. Por exemplo: file_download; first_visit; scroll…

Enhanced Events – eventos coletados quando o GA4 é configurada no website e os enhanced events são ativados. Por exemplo: pageviews; scrolls, site search; outbound links…

Depois temos uma grande segunda categoria de eventos que são os eventos que o Google Analytics 4 sugere que implementemos:

Eventos recomendados – eventos que implementamos, mas que possuem nomes e parâmetros predefinidos. Esses eventos desbloqueiam recursos de geração de relatórios existentes e futuros. Por exemplo: sign_up; login; purchase; refund…

Eventos personalizados – eventos que definimos e que são “personalizados” aquilo que é o negócio da Empresa. Por exemplo: adicionar_matrícula

• Para que serve: Se não tivermos os eventos recomendados e customizados definidos e implementados, ficará mais difícil fazer análises mais granulares.
• Quais são os seus componentes: nd.
• Quem deve estar envolvido: Equipas de Analytics e equipas de desenvolvimento.
• Ambientes onde se implementa: Novo website em ambientes de qualidade e de produção.
• Entregáveis: Documento com indicação da tipologia de eventos, o nome dos eventos, o local onde queremos implementar os eventos, os parâmetros adicionais a incorporar nos eventos, nomeadamente nos eventos customizados e notas/observações sobre a implementação.

4. Definição do Product Group Name

• O que é: As conversões nada mais são que os eventos que são despontados no website e que a Empresa/Área de Negócio considera ser os mais importantes, ou dito de uma outra forma, são aqueles eventos que geram receita. Obviamente, que podem haver eventos considerados importantes e que não geram receita, por exemplo o envio de um formulário, mas por norma e considerando, por exemplo, a navegação de um utilizador num funil fechado, o evento mais importante será, por exemplo a compra que envolve receita.
• Para que serve: Ao configurar as conversões, podemos:
  • Ver as ações mais importantes para o negócio utilizando os relatórios de Aquisição, Engagement e Publicidade.
  • Importar as conversões para o Google Ads para alimentar decisões manuais ou de lances inteligentes para ajudar a otimizar as campanhas.
  • Combinar dados de negócio com dados de outros canais de publicidade para entender os pontos de contato ao longo da jornada do cliente até a conversão.
  • Utilizar os dados de conversão para criar públicos que não converteram e importar esses públicos para o Google Ads para ações de remarketing.
• Quais são os seus componentes: nd.
• Quem deve estar envolvido: Equipas de Analytics e equipas de desenvolvimento.
• Ambientes onde se implementa: Novo website em ambientes de qualidade e de produção.
• Entregáveis: No documento com indicação de todos os elementos/eventos que se pretendem implementar no website deve existir também uma coluna a identificar quais daqueles eventos devem ser considerados conversões.

5. Definição dos Customer Segments

• O que é: Os customer segments são variáveis que devem ser implementadas na data layer do website se o mesmo servir ou contiver informação para diferentes públicos. Por exemplo, podemos ter websites para Crianças e para Adultos. Podemos ter websites para Consumidores finais e para Empresas. E Podemos até ter websites que tem conteúdo para todo o tipo de público, mas tem uma secção referente ao Grupo.
• Para que serve: A implementação dos Customer Segments, via data layer preferencialmente, deve acontecer para quando temos um website possui diferentes grupos de conteúdo/informação, conteúdo esse que se destina a públicos diferentes. Ou seja, imaginando que temos um website de uma Empresa de produção de pasta de papel, onde existe uma secção relativa ao Grupo, outra grande secção relativa a Empresas e uma outra para Investidores e uma outra para Media. Podemos implementar 3 Customer Segments: Grupo, Media e Investidores e assim conseguiremos “segmentar” por estas variáveis no GA4 e fazer análises mais granulares.
• Quais são os seus componentes: nd.
• Quem deve estar envolvido: Equipas de Analytics e equipas de desenvolvimento.
• Ambientes onde se implementa: Novo website em ambientes de qualidade e de produção.
• Entregáveis: Documento com indicação de todos os customer segments que pretendemos implementar no website e se fizer sentido, em que páginas os mesmos devem ser implementados.

6. Definição dos Host Owners

• O que é: O Host Owner é a identificação do domínio do website ou de cada parte/aplicativo de um website. s conversões nada mais são que os eventos que são despontados no website e que a Empresa/Área de Negócio considera ser os mais importantes, ou dito de uma outra forma, são aqueles eventos que geram receita. Obviamente, que podem haver eventos considerados importantes e que não geram receita, por exemplo o envio de um formulário, mas por norma e considerando, por exemplo, a navegação de um utilizador num funil fechado, o evento mais importante será, por exemplo a compra que envolve receita.
• Para que serve: A implementação de um host owner, via data layer preferencialmente, deve acontecer para quando temos um website que não é composto apenas e só por aplicativos da Empresa que é dona do website. Ou seja, imaginando que temos um website de e-commerce de roupa de homem feita por medida e nele existe uma secção/aplicativo que é de um fornecedor de camisas de homem que permite que os mesmos definiam as medidas exatas do comprimento das mangas da camisa, do comprimento da camisa, do raio do colarinho,…..Para se conseguir fazer análises por exemplo sobre a utilização desse aplicativo, se tivermos o host owner implementado, conseguiremos “segmentar” por essa variável no GA4.
• Quais são os seus componentes: nd.
• Quem deve estar envolvido: Equipas de Analytics e equipas de desenvolvimento.
• Ambientes onde se implementa: Novo website em ambientes de qualidade e de produção.
• Entregáveis: Documento com indicação de todas as secções/aplicativos do website que são geridos por parceiros.

7. Definição dos PageTypes / Content Grouping

• O que é: As PageTypes ou Content Grouping são grupos de páginas que possuem o mesmo tipo de template e que por isso podem ser classificadas, em termos de conteúdo, como sendo idênticas e únicas entre si. Por exemplo, se estivermos a falar de um website de e-commerce, haverá um template de página específico para aquilo que são as páginas de categoria de produtos, outro template para as páginas de produto e ainda outro template para as páginas relativas ao carrinho de compras.
• Para que serve: O Content Grouping permite-nos visualizar e comparar métricas agregadas por tipo de conteúdo, além de poder detalhar o URL individual, título da página ou screen name. Por exemplo, podemos ver o número agregado de visualizações de página para todas as páginas classificadas como Mulheres/Calças e, em seguida, detalhar para ver cada URL ou título de página. Analytics avalia as regras em ordem.
• Quais são os seus componentes: nd.
• Quem deve estar envolvido: Equipas de Analytics e equipas de desenvolvimento.
• Ambientes onde se implementa: Novo website em ambientes de qualidade e de produção.
• Entregáveis: Documento discriminativo de todos os page types / content groupings criados.

8. Definição das Virtual Pages Views – Eventos

• O que é: As conversões nada mais são que os eventos que são despontados no website e que a Empresa/Área de Negócio considera ser os mais importantes, ou dito de uma outra forma, são aqueles eventos que geram receita. Obviamente, que podem haver eventos considerados importantes e que não geram receita, por exemplo o envio de um formulário, mas por norma e considerando, por exemplo, a navegação de um utilizador num funil fechado, o evento mais importante será, por exemplo a compra que envolve receita.
• Para que serve: As virtual page views servem para ultrapassar o “problema” que algumas páginas, e até mesmo websites inteiros, têm que é o facto de apresentarem o mesmo URL, independentemente do utilizador ir avançando no website/aplicativo. São chamados o Single Page Applications e por norma envolvem o desenvolvimento em Ajax ou linguagens de programação semelhantes. Por exemplo e mais uma vez imaginando um website de e-commerce que desde a entrada no checkout (begin_checkout) até à compra (purchase), o URL do website não muda, mas o screen altera. Com a implementação das virtual page views vamos conseguir perceber as diferentes páginas pelas quais o utilizador navegou e com isso implementar um funil no Explorer do GA4 e fazer as análises necessárias.
• Quais são os seus componentes: nd.
• Quem deve estar envolvido: Equipas de Analytics e equipas de desenvolvimento.
• Ambientes onde se implementa: Novo website em ambientes de qualidade e de produção.
• Entregáveis: Documento com o mapeamento de todos os fluxos do utilizador pelos aplicativos/website que têm o mesmo URL, indicação desse mesmo URL e indicação da proposta de nome para o “novo” URL que servirá de virtual page view.

9. Definição da Estrutura Mercadológica de Produtos (se não existir)

• O que é: A estrutura mercadológica é a identificação e/ou agrupamento dos diferentes tipos de produtos pela sua família. De certa forma, as estruturas mercadológicas de produtos estão relacionadas com aquilo que é a arquitetura de informação de um website. Por exemplo e imaginando um website de uma insígnia de hipermercados. Se estivermos a pensar num queijo flamengo Terra Nostra, o mesmo pode ser classificado na seguinte estrutura mercadológica:
  • Lacticínios (1)
    • Queijos (2)
      • Queijos Sólidos/Pasta (3)
        • Queijos Portugueses (4)
          • Queijos Flamengos (5)
• Para que serve: A principal vantagem de ter uma estrutura mercadológica de produto implementada na data layer de um website é o poder fazer análises mais granulares ao nível do produto, utilizando para isso, por exemplos, o Explorer do GA4.
• Quais são os seus componentes: nd.
• Quem deve estar envolvido: Equipas de Analytics e equipas de desenvolvimento.
• Ambientes onde se implementa: Novo website em ambientes de qualidade e de produção.
• Entregáveis: Documento com o mapeamento para cada um dos produtos do website de toda a sua estrutura mercadológica até 5 grupos.

10. Definição das Conversões

• O que é: As conversões nada mais são que os eventos que são despontados no website e que a Empresa/Área de Negócio considera ser os mais importantes, ou dito de uma outra forma, são aqueles eventos que geram receita. Obviamente, que podem haver eventos considerados importantes e que não geram receita, por exemplo o envio de um formulário, mas por norma e considerando, por exemplo, a navegação de um utilizador num funil fechado, o evento mais importante será, por exemplo a compra que envolve receita.
• Para que serve: Ao configurar as conversões, podemos:
  • Ver as ações mais importantes para o negócio utilizando os relatórios de Aquisição, Engagement e Publicidade.
  • Importar as conversões para o Google Ads para alimentar decisões manuais ou de lances inteligentes para ajudar a otimizar as campanhas.
  • Combinar dados de negócio com dados de outros canais de publicidade para entender os pontos de contato ao longo da jornada do cliente até a conversão.
  • Utilizar os dados de conversão para criar públicos que não converteram e importar esses públicos para o Google Ads para ações de remarketing.
• Quais são os seus componentes: nd.
• Quem deve estar envolvido: Equipas de Analytics e se necessário equipas de desenvolvimento.
• Ambientes onde se implementa: Novo website em ambientes de qualidade e de produção.
• Entregáveis: No documento com indicação de todos os elementos/eventos que se pretendem implementar no website deve existir também uma coluna a identificar quais daqueles eventos devem ser considerados conversões.

11. Definição e Implementação do Measurement Protocol

• O que é: O measurement protocol é um protocolo que nos vai permitir aferir com maior rigor se as transações que foram feitas, por exemplo, offline efetivamente se efectivaram.
• Para que serve: Por exemplo, pode-se dar o caso do utilizador ter pago algo com o cartão de crédito, mas mais tarde fez a devolução do produto. Com a implementação do measurement protocol conseguiremos medir esses comportamento de alguma forma.
• Quais são os seus componentes: nd.
• Quem deve estar envolvido: Equipas de Analytics e equipas de desenvolvimento.
• Ambientes onde se implementa: Novo website em ambientes de qualidade e de produção.
• Entregáveis:  Documento com indicação de todos os eventos que exigem implementação do measurement protocol e qual as situações/regras para o mesmo ser despoletado.

Conclusão

Lançar um website não é algo fácil e que se faça de um dia para o outro. Exige imensos cuidados, imenso trabalho e envolvimento de diversas equipas em vários momentos distintos. Para que tudo corra bem é preciso ter em consideração, mas não só, todas estas questões que mencionei nesta “coletânea” de 3 artigos

Espero que os artigos tenham sido úteis e venham a ser consultados sempre que tenham que fazer o lançamento ou relançamento de um website.

Want to read this article in English? Please click here

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