Práticas recomendadas de gerenciamento de SEO e URL do Adobe Experience Manager as a Cloud Service

A Otimização do mecanismo de pesquisa (SEO) se tornou uma preocupação principal para muitos comerciantes. Como resultado, as preocupações com a SEO precisam ser abordadas em muitos projetos do Adobe Experience Manager (AEM) as a Cloud Service.

Este documento descreve primeiramente algumas práticas recomendadas da SEO e recomendações para atingi-las em uma implementação do AEM as a Cloud Service. Em seguida, ele detalha algumas etapas de implementação mais complexas abordadas na primeira seção.

Práticas recomendadas da SEO

Esta seção descreve algumas práticas recomendadas gerais da SEO.

URLs

Há algumas práticas recomendadas geralmente aceitas quando se trata de URLs.

No projeto do AEM, ao avaliar os URLs, faça o seguinte:

"Se um usuário visse esse URL e nenhum conteúdo na página, ele poderia descrever o que era essa página?"

Se a resposta for sim, então é provável que o URL funcione bem em um mecanismo de pesquisa.

Estas são algumas dicas gerais sobre como criar os URLs para SEO:

  • Use hífenshifens para separar palavras.

    • Nomeie páginas usando hífenshifens (-) como separadores.
    • Evite usar concatenadas, sublinhados e espaços.
  • Evite a utilização de parâmetros de consulta sempre que possível. Quando necessário, limite-os a dois ou menos.

    • Use a estrutura de diretório para indicar a arquitetura de informações, quando disponível.
    • Se uma estrutura de diretório não for uma opção, use seletores Sling no URL em vez de cadeias de caracteres de consulta. Além do valor da SEO que eles fornecem, os seletores sling também tornarão as páginas acessíveis para o dispatcher.
  • Quanto mais legível por humanos for um URL, melhor; ter palavras-chave presentes no URL aumentará o valor.

    • Ao usar seletores em uma página, os seletores que fornecem valor semântico são preferenciais.

    • Se um humano não conseguir ler o URL, um mecanismo de pesquisa também não poderá.

    • Por exemplo:

      mybrand.com/products/product-detail.product-category.product-name.html
      é preferível a
      mybrand.com/products/product-detail.1234.html

  • Evite subdomínios sempre que possível, já que os mecanismos de pesquisa os tratarão como entidades diferentes, fragmentando o valor SEO do site.

    • Em vez disso, use subcaminhos de primeiro nível. Por exemplo, em vez de es.mybrand.com/home.html, use www.mybrand.com/es/home.html.

    • Planeje sua hierarquia de conteúdo para corresponder à forma como o conteúdo será apresentado, de acordo com essa diretriz.

  • A eficácia da palavra-chave em URLs diminui conforme o comprimento do URL e a posição da palavra-chave aumentam. Em outras palavras, menor é melhor.

    • Use técnicas e recursos de redução de URL fornecidos pelo AEM para remover partes desnecessárias do URL.
    • Por exemplo, mybrand.com/en/myPage.html é preferível a mybrand.com/content/my-brand/en/myPage.html.
  • Use URLs canônicos.

    • Quando um URL puder ser distribuído a partir de caminhos diferentes ou com parâmetros ou seletores diferentes, certifique-se de usar uma tag rel=canonical na página.

    • Isso pode ser incluído no código do modelo do AEM.

  • Corresponder URLs a títulos de página sempre que possível.

    • Os autores de conteúdo devem ser encorajados a seguir essa prática.
  • Insensibilidade a maiúsculas e minúsculas em solicitações de URL.

    • Configure o dispatcher para regravar todas as solicitações de entrada como letras minúsculas.
    • Treine autores de conteúdo para criar todas as páginas usando letras minúsculas.
  • Certifique-se de que cada página seja distribuída somente de um protocolo.

    • Às vezes, os sites serão distribuídos pelo http até que um usuário chegue a uma página com, por exemplo, um formulário de check-out ou logon, no qual ele é alternado para https. Ao criar links a partir dessa página, se o usuário puder retornar às páginas http e acessá-las por meio do https, o mecanismo de pesquisa as rastreará como duas páginas separadas.

    • Atualmente, o Google prefere páginas https às http páginas. Por isso, muitas vezes é mais fácil distribuir todo o site por https.

Configuração de servidor

Em termos de configuração do servidor, você pode executar as seguintes etapas para garantir que somente o conteúdo correto esteja sendo rastreado:

  • Use um arquivo robots.txt para bloquear o rastreamento de qualquer conteúdo que não deve ser indexado.

    • Bloquear todos os rastreamentos em ambientes de teste.
  • Ao iniciar um novo site com URLs atualizados, implemente os redirecionamentos 301 para garantir que sua classificação de SEO existente não seja perdida.

  • Inclua um favicon para o site.

  • Implemente um mapa de site XML para facilitar o rastreamento de conteúdo pelos mecanismos de pesquisa. Certifique-se de incluir um mapa de site móvel para sites móveis e/ou responsivos.

Configurações do AEM

Esta seção descreve as etapas de implementação necessárias para configurar o AEM para seguir essas recomendações de SEO.

Uso de seletores Sling

Anteriormente, o uso de parâmetros de consulta era a prática geralmente aceita ao criar um aplicativo Web corporativo.

A tendência nos últimos anos tem sido removê-los em um esforço para tornar os URLs mais legíveis. Em várias plataformas, isso envolve implementar redirecionamentos no servidor da Web ou na Rede deede entrega de conteúdo (CDN), mas o Sling torna isso simples. Os seletores Sling:

  • Melhoram a legibilidade do URL.
  • Permitem o armazenamento das páginas em cache no dispatcher e geralmente melhoram a segurança.
  • Permitem abordar o conteúdo diretamente, em vez de ter um servlet genérico que recupera o conteúdo. Isso concede os benefícios das ACLs que você aplica ao repositório e aos filtros que você aplica ao dispatcher.

Usar seletores para servlets

O AEM nos fornece duas opções ao gravar servlets:

  • Servlets bin
  • Servlets Sling

Os exemplos a seguir ilustram como registrar servlets que seguem ambos os padrões, bem como o benefício ganho com o uso de servlets Sling.

Servlets bin (um nível abaixo)

Os servlets Bin seguem o padrão para o qual muitos desenvolvedores são usados na programação J2EE. O servlet é registrado em um caminho específico, que no caso do AEM normalmente está no /bin, e você extrai os parâmetros de solicitação necessários da cadeia de caracteres de consulta.

A anotação SCR para este tipo de servlet seria algo como isto:

@SlingServlet(paths = "/bin/myApp/myServlet", extensions = "json", methods = "GET")

Em seguida, você extrai os parâmetros da cadeia de caracteres de consulta por meio do objeto SlingHttpServletRequest incluído no método doGet; por exemplo:

String myParam = req.getParameter("myParam");

O URL resultante usado seria semelhante a:

https://www.mydomain.com/bin/myApp/myServlet.json?myParam=myValue

Há alguns pontos a considerar com esta abordagem:

  • O próprio URL perde o valor SEO. Os usuários que acessam o site, incluindo mecanismos de pesquisa, não recebem nenhum valor semântico do URL, pois o URL representa um caminho programático e não a hierarquia de conteúdo.
  • A presença de parâmetros de consulta no URL significa que o dispatcher não poderá armazenar a resposta em cache.
  • Se quiser proteger esse servlet, você precisa implementar sua própria lógica de segurança personalizada no servlet.
  • O dispatcher deve ser configurado (com cuidado) para expor o /bin/myApp/myServlet. Apenas expor o /bin permitiria o acesso a determinados servlets que não deveriam ser abertos a visitantes do site.

Servlets sling (um nível abaixo)

Os servlets sling permitem registrar o servlet da maneira oposta. Em vez de endereçar um servlet e especificar o conteúdo que gostaria que o servlet renderizasse com base nos parâmetros de consulta, você endereçaria o conteúdo desejado e especificaria o servlet que deve renderizar o conteúdo com base nos seletores Sling.

A anotação SCR para este tipo de servlet seria algo como isto:

@SlingServlet(resourceTypes = "myBrand/components/pages/myPageType", selectors = "myRenderer", extensions = "json”, methods=”GET”)

Nesse caso, o recurso que o URL endereça (uma instância do recurso myPageType) é acessível automaticamente no servlet. Para acessá-lo, você chama:

Resource myPage = req.getResource();

O URL resultante usado seria semelhante a:

https://www.mydomain.com/content/my-brand/my-page.myRenderer.json

Os benefícios dessa abordagem são:

  • Você pode fazer o bake do valor SEO, obtido pela semântica presente na hierarquia do site e no nome da página.
  • Como nenhum parâmetro de consulta está presente, o dispatcher pode armazenar a resposta em cache. Além disso, as atualizações feitas na página endereçada invalidarão esse cache quando a página for ativada.
  • Todas as ACLs aplicadas a /content/my-brand/my-page entrarão em vigor quando um usuário tentar acessar esse servlet.
  • O dispatcher já estará configurado para distribuir esse conteúdo como uma função de distribuição do site. Nenhuma configuração adicional é necessária.

Regravação de URL

No AEM, todas as páginas da Web são armazenadas no /content/my-brand/my-content. Embora isso possa ser útil da perspectiva da gestão de dados de repositório, não é necessariamente a forma como você deseja que os clientes vejam o site, e pode entrar em conflito com a orientação da SEO de manter os URLs o mais curtos possível. Além disso, você pode estar distribuindo vários sites da mesma instância do AEM e de nomes de domínio diferentes.

Esta seção analisa as opções disponíveis no AEM para gerenciar esses URLs e apresentá-los aos usuários de maneira mais legível e fácil de usar para SEO.

URLs personalizadas

Se um autor desejar que uma página seja acessível de um segundo local para fins promocionais, os URLs personalizados do AEM, definidos página por página, podem ser úteis. Para adicionar um URL personalizado de uma página, navegue até ele no console Sites e edite as propriedades da página. Na parte inferior da guia Básico, você verá uma seção na qual URLs personalizados podem ser adicionados. Lembre-se de que ter a página acessível por mais de um URL fragmentará o valor SEO da página. Portanto, uma tag de URL canônica deve ser adicionada à página para evitar esse problema.

Nomes de página localizados

Talvez você queira exibir nomes de página localizados para usuários de conteúdo traduzido. Por exemplo:

  • Em vez de um usuário de língua espanhola navegar até:
    www.mydomain.com/es/home.html

  • Seria melhor que o URL fosse:
    www.mydomain.com/es/casa.html.

O desafio de localizar o nome da página é que muitas das ferramentas de localização disponíveis na plataforma AEM dependem que os nomes das páginas correspondam às localidades para manter o conteúdo sincronizado.

A propriedade sling:alias permite ter os dois. sling:alias pode ser adicionado como uma propriedade a qualquer recurso para permitir um nome de alias para o recurso. No exemplo anterior, você teria:

  • Uma página no JCR em:
    …/es/home

  • Em seguida, adicione uma propriedade a ela:
    sling:alias = casa

Isso permitiria que as ferramentas de tradução do AEM, como o gerente de vários sites, continuassem a manter uma relação entre:

  • /en/home

  • /es/home

Ao mesmo tempo, permitiria que os usuários finais interagissem com o nome da página em seus idiomas nativos.

OBSERVAÇÃO

A propriedade sling:alias pode ser definida usando a propriedade Alias ao editar as Propriedades da página.

/etc/map

Em uma instalação padrão do AEM:

  • para a configuração do OSGi
    Apache Sling Resource Resolver Factory
    (
    org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl)

  • a propriedade
    Localização do mapeamento ( resource.resolver.map.location)

  • toma como padrão /etc/map

As definições de mapeamento podem ser adicionadas neste local para mapear solicitações de entrada, regravar URLs em páginas no AEM ou em ambos.

Para criar um novo mapeamento, crie um novo nó sling:Mapping neste local no /http ou /https. Com base nas propriedades sling:match e sling:internalRedirect definidas neste nó, o AEM redirecionará todo o tráfego do URL correspondente para o valor especificado na propriedade internalRedirect.

Embora essa seja a abordagem documentada na documentação oficial do AEM e Sling, o suporte regular à expressão fornecido por essa implementação é limitado no escopo quando comparado às opções que estão disponíveis para nós usando o suporte SlingResourceResolver diretamente. Além disso, a implementação de mapeamentos dessa maneira pode levar a problemas com a invalidação do cache do dispatcher.

Este é um exemplo de como esse problema ocorre:

  1. Um usuário visita o site e solicita https://www.mydomain.com/my-page.html

  2. O dispatcher encaminha essa solicitação ao servidor de publicação.

  3. Usando o /etc/map, o servidor de publicação resolve essa solicitação para /content/my-brand/my-page e renderiza a página.

  4. O dispatcher armazena a resposta em cache no /my-page.html e retorna a resposta ao usuário.

  5. Um autor de conteúdo faz uma alteração nessa página e a ativa.

  6. O agente de liberação do dispatcher envia uma solicitação de invalidação para o /content/my-brand/my-page. Como o dispatcher não tem uma página em cache nesse caminho, o conteúdo antigo permanece em cache e será obsoleto.

Há maneiras de configurar regras de liberação do dispatcher personalizadas que mapearão o URL mais curto até o URL mais longo para fins de invalidação de cache.

No entanto, há também uma maneira mais simples de gerenciar isso:

  1. Regras SlingResourceResolver

    Usando o console da Web (por exemplo, localhost:4502/system/console/configMgr), você pode configurar o Sling Resource Resolver:

    • Apache Sling Resource Resolver Factory

      (org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl).
      É recomendável criar os mapeamentos necessários para encurtar URLs como expressões regulares e, em seguida, definir essas configurações em um nó OsgiConfig, config.publish, incluído na sua versão.

    Em vez de definir os mapeamentos no /etc/map, eles podem ser atribuídos diretamente à propriedade Mapeamentos de URL ( resource.resolver.mapping):

    resource.resolver.mapping="[/content/my-brand/(.*)</$1]"
    

    Neste exemplo simples, você está removendo /content/my-brand/ do início de qualquer URL em que ele esteja presente.

    Isso converteria um URL:

    • de /content/my-brand/my-page.html
    • para apenas /my-page.html

    Isso está de acordo com a prática recomendada de manter os URLs o mais curtos possível.

  2. Mapeamento da saída de URL nas páginas

    Depois de definir os mapeamentos no Apache Sling Resource Resolver, é necessário usar esses mapeamentos em seus componentes para garantir que os URLs enviados nas páginas sejam curtos e organizados. Você pode fazer isso usando a função de mapa do ResourceResolver.

    Por exemplo, se estava implementando um componente de navegação personalizado que lista os filhos da página atual, pode usar o método de mapeamento da seguinte maneira:

    for (Page child : children) {
      String childUrl = resourceResolver.map(request, child.getPath());
      //Output the childUrl on the page here
    }
    

Apache HTTP Server mod_rewrite

Até o momento, você implementou mapeamentos juntamente com a lógica nos componentes para usar esses mapeamentos ao enviar URLs para nossas páginas.

A peça final do quebra-cabeça é lidar com esses URLs encurtados quando eles chegam ao dispatcher, que é onde mod_rewrite entra em cena. O maior benefício de usar mod_rewrite é que os URLs são mapeados de volta ao formulário longo antes de serem enviados ao módulo do dispatcher. Isso significa que o dispatcher solicitará o URL longo do servidor de publicação e o armazenará em cache de acordo. Portanto, todas as solicitações de liberação do dispatcher que chegarem do servidor de publicação poderão invalidar esse conteúdo com êxito.

Para implementar essas regras, você pode adicionar elementos RewriteRule no host virtual na configuração do Apache HTTP Server. Se quiser expandir os URLs encurtados do exemplo anterior, você pode implementar uma regra que se pareça com esta:

<VirtualHost *:80>
  ServerName www.mydomain.com
  RewriteEngine on
  RewriteRule ^/(.*)$ /content/my-brand/$1 [PT,L]
  …
</VirtualHost>

Tags de URL canônicas

As tags de URL canônicas são tags de link colocadas no cabeçalho de um documento HTML para esclarecer como os mecanismos de pesquisa devem tratar uma página enquanto indexam o conteúdo. A vantagem que a oferta oferece é garantir que (versões diferentes de) uma página seja indexada como a mesma, mesmo quando o URL da página possa conter diferenças.

Por exemplo, se um site oferecesse uma versão de uma página compatível com a impressora, um mecanismo de pesquisa potencialmente indexaria essa página separadamente da versão normal da página. A tag canônica informará ao mecanismo de pesquisa que elas são as mesmas.

Exemplos:

  • https://www.mydomain.com/my-brand/my-page.html
  • https://www.mydomain.com/my-brand/my-page.print.html

Ambos aplicariam a seguinte tag ao cabeçalho da página:

<link rel=”canonical” href=”my-brand/my-page.html”/>

O href pode ser relativo ou absoluto. O código deve ser incluído na marcação da página para determinar o URL canônico da página e exibir essa tag.

Configurar o dispatcher para não diferenciação entre maiúsculas e minúsculas

A prática recomendada é distribuir todas as páginas usando letras minúsculas. No entanto, você não quer que um usuário tenha um 404 ao acessar o site usando letras maiúsculas no URL. Por esse motivo, a Adobe recomenda adicionar uma regra de regravação na configuração do Apache HTTP Server para mapear todos os URLs recebidos em minúsculas. Além disso, os autores de conteúdo devem ser treinados para criar suas páginas com nomes em minúsculas.

Para configurar o Apache para forçar todo o tráfego de entrada em letras minúsculas, adicione o seguinte à configuração vhost:

RewriteEngine On
RewriteMap lowercase int:tolower

Além disso, adicione o seguinte à parte superior do arquivo htaccess:

RewriteCond $1 [A-Z]
RewriteRule ^(.*)$ /${lowercase:$1} [R=301,L]

Implementar o robots.txt para proteger ambientes de desenvolvimento

Os mecanismos de pesquisa devem verificar a presença de um arquivo robots.txt na raiz do site antes de rastrear o site. Deve ser enfatizado aqui porque enquanto os grandes mecanismos de pesquisa como o Google, Yahoo, ou Bing respeitam isso, alguns mecanismos de pesquisa estrangeiros não respeitam.

A maneira mais simples de bloquear o acesso a todo o site é colocar um arquivo chamado robots.txt na raiz do site com o seguinte conteúdo:

User-agent: *
Disallow: /

Como alternativa, em um ambiente em tempo real, você pode optar por não permitir determinados caminhos que não deseja indexar.

O problema ao colocar o arquivo robots.txt na raiz do site é que as solicitações de liberação do dispatcher podem apagar esse arquivo e os mapeamentos de URL provavelmente colocarão a raiz do site em um local diferente do DOCROOT definido na configuração do Apache HTTP Server. Por isso, é comum colocar esse arquivo na instância do autor na raiz do site e replicá-lo na instância de publicação.

Criar um mapa de site XML no AEM

Os rastreadores usam mapas de site XML para entender melhor a estrutura dos sites. Embora não haja garantias de que a disponibilização de um mapa de site levará a melhores classificações de SEO, trata-se de uma prática recomendada acordada. É possível manter manualmente um arquivo XML no servidor da Web para usar como o mapa de site, mas é recomendável gerar o mapa de site de forma programática, o que garante que, à medida que os autores criarem novos conteúdos, o mapa de site reflita automaticamente as alterações.

O AEM usa o módulo Apache Sling Sitemap para gerar mapas do site XML, que fornece uma grande variedade de opções para desenvolvedores e editores para manter um mapa do site XML atualizado.

O módulo de Mapa do site do Apache Sling distingue entre um mapa de site de nível superior e um mapa de site aninhado, ambos sendo gerados para qualquer recurso que tenha a propriedade sling:sitemapRoot definida como true. Em geral, os mapas de site são renderizados usando seletores no caminho do mapa de site de nível superior da árvore, que é o recurso que não tem outro ancestral raiz do mapa de site. Essa raiz do mapa de site de nível superior também expõe o índice do mapa de site, que normalmente é o que um proprietário de site configuraria no portal de configuração do Mecanismo de pesquisa ou adicionaria ao robots.txt do site.

Por exemplo, considere um site que define uma raiz de mapa de site de nível superior em my-page e uma raiz de mapa de site aninhada em my-page/news, para gerar um mapa de site dedicado para páginas na subárvore de notícias. Os urls relevantes resultantes seriam

  • https://www.mydomain.com/my-brand/my-page.sitemap-index.xml
  • https://www.mydomain.com/my-brand/my-page.sitemap.xml
  • https://www.mydomain.com/my-brand/my-page.sitemap.news-sitemap.html
OBSERVAÇÃO

Os seletores sitemap e sitemap-index podem interferir nas implementações personalizadas. Se não quiser usar o recurso do produto, configure seu próprio servlet que serve esses seletores com um service.ranking maior que 0.

Na configuração padrão, a caixa de diálogo Propriedades da página fornece uma opção para marcar uma página como uma raiz do mapa de site e, portanto, conforme descrito acima, gerar um mapa de site próprio e seus descendentes. Esse comportamento é implementado pelas implementações da interface SitemapGenerator e pode ser estendido adicionando implementações alternativas. No entanto, como a frequência na qual os mapas de site XML são regenerados depende muito dos fluxos de trabalho e cargas de trabalho de criação de conteúdo, o produto não envia nenhuma configuração SitemapScheduler. Isso faz com que o recurso opte por participar com eficácia.

Para habilitar o trabalho em segundo plano que gera os mapas de site XML, um SitemapScheduler deve ser configurado. Para fazer isso, crie uma configuração OSGI para o PID org.apache.sling.sitemap.impl.SitemapScheduler. A expressão do agendador 0 0 0 * * ? pode ser usada como ponto de partida para gerar novamente todos os mapas do site XML uma vez por dia, à meia-noite.

Apache Sling Sitemap - Scheduler

O trabalho de geração de mapa de site pode ser executado em instâncias de nível de criação e publicação. Na maioria dos casos, é recomendável executar a geração em instâncias do nível de publicação, pois somente lá URLs canônicos adequados podem ser gerados (devido às regras de Mapeamento de recursos do Sling que geralmente estão presentes apenas em instâncias do nível de publicação). No entanto, é possível plug-in de uma implementação personalizada do mecanismo de externalização usado para gerar os URLs canônicos implementando a interface SitemapLinkExternalizer. Se uma implementação personalizada for capaz de gerar os URLs canônicos de um Mapa do Site nas instâncias de camada do autor, o SitemapScheduler poderá ser configurado para o modo de execução do autor e a carga de trabalho de geração de mapa do site XML poderá ser distribuída pelas instâncias do cluster de serviços do autor. Nesse cenário, deve-se ter especial cuidado ao manipular conteúdo que ainda não foi publicado, foi modificado ou está visível apenas para um grupo restrito de usuários.

Além dos pontos de extensão do Apache Sling Sitemap SitemapGenerator e SitemapLinkExternalizer descritos acima, e também SitemapExtensionProvider, a implementação específica AEM define alguns pontos de extensão para:

Além disso, a funcionalidade implementada para mapas de site XML também pode ser usada em casos de uso diferentes, por exemplo, para adicionar o link canônico ou o idioma alternativo ao cabeçalho de uma página. Consulte a interface SeoTags para obter mais informações.

Criar redirecionamentos 301 para URLs herdados

Ao iniciar um site com uma nova estrutura, é importante implementar e testar os redirecionamentos 301 no Apache HTTP Server por dois motivos:

  • Os URLs herdados acumularam o valor SEO ao longo do tempo. Ao implementar um redirecionamento, o mecanismo de pesquisa pode aplicar esse valor ao novo URL.
  • Os usuários do site podem ter criado marcadores nessas páginas. Ao implementar redirecionamentos, você pode direcionar o usuário para a página no novo site que melhor corresponde ao local em que ele estava tentando acessar no site antigo.

Verifique a seção de recursos adicionais a seguir para obter instruções sobre como implementar os redirecionamentos 301, além de uma ferramenta para testar se os redirecionamentos estão funcionando como esperado.

Recursos adicionais

Para obter mais informações, consulte os seguintes recursos adicionais:

Nesta página