Best practice per la gestione di SEO e URL seo-and-url-management-best-practices

L’ottimizzazione SEO (Search Engine Optimization) è diventata una preoccupazione chiave per molti esperti marketing. Di conseguenza, le preoccupazioni in materia di SEO devono essere affrontate in molti progetti AEM.

In questo documento vengono innanzitutto descritte alcune best practice per l'ottimizzazione SEO e raccomandazioni per l'implementazione AEM. Vengono quindi approfonditi alcuni dei passaggi di implementazione più complessi illustrati nella prima sezione.

Best practice per l’ottimizzazione SEO seo-best-practices

Questa sezione descrive alcune best practice generali relative all’ottimizzazione SEO (Search Engine Optimization).

URL urls

Con gli URL sono presenti alcune best practice accettate.

Durante la valutazione degli URL nel progetto AEM, considera le seguenti domande:

"Potendo vedere solo questo URL e non i contenuti della pagina, un utente sarebbe in grado di descrivere questa pagina?"

Se la risposta è affermativa, è probabile che l’URL funzioni correttamente per un motore di ricerca.

Ecco alcuni suggerimenti di carattere generale su come creare URL per l’ottimizzazione SEO (Search Engine Optimization):

Configurazione del server server-configuration

Dal punto di vista della configurazione del server, puoi adottare le seguenti misure per garantire che venga effettuata la ricerca per indicizzazione solo del contenuto corretto:

Configurazioni AEM aem-configurations

Questa sezione descrive i passaggi di implementazione per configurare l’AEM con le seguenti raccomandazioni SEO (Search Engine Optimization).

Utilizzo dei selettori Sling using-sling-selectors

In precedenza, per la creazione di un’applicazione web aziendale si usavano in genere i parametri di query.

Negli ultimi anni, la tendenza è stata quella di rimuovere i parametri per rendere gli URL più leggibili. Su molte piattaforme, questo processo di rimozione comporta l’implementazione di reindirizzamenti sul server web o sulla rete CDN (Content Delivery Network), ma Sling rende il processo semplice. I selettori Sling:

Utilizzo dei selettori per i servlet using-selectors-for-servlets

AEM offre due opzioni per la scrittura di servlet:

Gli esempi seguenti illustrano come registrare i servlet conformi a questi modelli che consentono di sfruttare i vantaggi ottenuti utilizzando i servlet Sling.

Servlet Bin (un livello inferiore) bin-servlets-one-level-down

I servlet Bin sono conformi al modello a cui molti sviluppatori sono abituati dalla programmazione J2EE. Il servlet viene registrato in un percorso specifico che, in AEM, si trova in genere in /bin ed è possibile estrarre i parametri di richiesta necessari dalla stringa di query.

L’annotazione SCR per questo tipo di servlet sarà simile al seguente:

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

Estrai quindi i parametri dalla stringa di query tramite l’oggetto SlingHttpServletRequest incluso nel metodo doGet; ad esempio:

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

L’URL risultante usato sarà simile al seguente:

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

Con questo approccio ci sono alcuni aspetti da considerare:

Servlet Sling (un livello inferiore) sling-servlets-one-level-down

I servlet Sling permettono di registrare il servlet in modo opposto. Invece di gestire un servlet e specificare il contenuto di cui vuoi eseguire il rendering in base ai parametri di query, devi indirizzare il contenuto desiderato. Inoltre, specifica il servlet che deve eseguire il rendering del contenuto in base ai selettori Sling.

L’annotazione SCR per questo tipo di servlet sarà simile al seguente:

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

In questo caso, la risorsa gestita dall'URL, un'istanza della risorsa myPageType, è accessibile automaticamente nel servlet. Per accedervi, chiama quanto segue:

Resource myPage = req.getResource();

L’URL risultante usato sarà simile al seguente:

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

I vantaggi di questo approccio sono i seguenti:

Riscrittura di URL url-rewriting

In AEM, tutte le pagine web vengono memorizzate in /content/my-brand/my-content. Anche se questa posizione è utile dal punto di vista della gestione dei dati dell’archivio, non corrisponde necessariamente alla modalità di visualizzazione del sito da parte dei clienti. Inoltre, mantenere gli URL il più brevi possibile potrebbe entrare in conflitto con le linee guida SEO (Search Engine Optimization). È anche possibile che più siti web vengano gestiti dalla stessa istanza di AEM e da nomi di dominio diversi.

Questa sezione esamina le opzioni disponibili in AEM per gestire questi URL e presentarli agli utenti in modo più leggibile e compatibile con SEO.

Gli URL personalizzati vanity-urls

Se un autore vuole che una pagina sia accessibile da una seconda posizione a scopo promozionale, potrebbe essere utile utilizzare gli URL personalizzati di AEM, definiti pagina per pagina. Per aggiungere un URL personalizzato a una pagina, passa alla pagina nella console Sites e modifica le proprietà della pagina. Nella parte inferiore della scheda Base, è disponibile una sezione in cui è possibile aggiungere URL personalizzati. Tieni presente che l’accesso alla pagina tramite più URL comporterà la frammentazione del valore SEO della pagina. Per evitare questo problema è quindi necessario aggiungere alla pagina un tag di URL canonico.

Nomi di pagina localizzati localized-page-names

Può essere necessario visualizzare i nomi delle pagine localizzate agli utenti del contenuto tradotto. Ad esempio:

Il problema correlato alla localizzazione del nome della pagina è che molti degli strumenti di localizzazione disponibili sulla piattaforma AEM dipendono dalla corrispondenza dei nomi delle pagine tra diverse lingue, per garantire la sincronizzazione del contenuto.

La proprietà sling:alias consente di utilizzare torta di Adobe e mangiarla. È possibile aggiungere sling:alias come proprietà a qualsiasi risorsa per consentire l'utilizzo di un nome di alias per la risorsa. Nell’esempio precedente, si otterrebbe quanto segue:

Questo flusso consente agli strumenti di traduzione dell’AEM come il gestore multisito di continuare a mantenere una relazione tra:

Allo stesso tempo gli utenti finali potranno interagire con il nome della pagina nelle rispettive lingue native.

/etc/map etc-map

In un’installazione standard di AEM:

È possibile aggiungere definizioni di mappatura in questa posizione per mappare le richieste in entrata, riscrivere gli URL nelle pagine in AEM o eseguire entrambe le operazioni.

Per creare una mappatura, crea un nodo sling:Mapping in questa posizione in /http o /https. In base alle proprietà sling:match e sling:internalRedirect impostate su questo nodo, AEM reindirizzerà tutto il traffico dell’URL corrispondente al valore specificato nella proprietà internalRedirect.

Sebbene questo approccio sia documentato nella documentazione ufficiale di AEM e Sling, il supporto delle espressioni regolari fornito da questa implementazione ha un ambito limitato rispetto alle opzioni disponibili utilizzando direttamente SlingResourceResolver. Inoltre, una tale implementazione delle mappature può causare problemi con l’annullamento della validità della cache del Dispatcher.

Ecco un esempio di scenario in cui si verifica questo problema:

Sono disponibili vari modi per configurare regole di eliminazione personalizzate che mappano l’URL più breve all’URL più lungo per consentire l’annullamento della validità della cache.

Tuttavia, esiste anche un modo più semplice per gestire questo problema:

mod_rewrite di Apache HTTP Server apache-http-server-mod-rewrite

Finora, hai implementato le mappature insieme alla logica nei tuoi componenti per utilizzarle durante l’output degli URL sulle pagine.

Non resta che definire come gestire questi URL abbreviati quando arrivano al Dispatcher ed è qui che entra in gioco mod_rewrite. Il principale vantaggio associato all’uso di mod_rewrite è che gli URL vengono mappati sulla relativa forma estesa prima di essere inviati al modulo del Dispatcher. Questo flusso significa che Dispatcher richiede l’URL lungo al server di pubblicazione e lo memorizza nella cache come al solito. Pertanto, qualsiasi richiesta di svuotamento del Dispatcher proveniente dal server di pubblicazione può annullare la validità di questo contenuto.

Per implementare queste regole, puoi aggiungere elementi RewriteRule nell’host virtuale della configurazione di Apache HTTP Server. Se vuoi espandere gli URL abbreviati dell’esempio precedente, puoi implementare una regola simile alla seguente:

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

Tag di URL canonici canonical-url-tags

I tag URL canonici sono tag di collegamento inseriti nell’intestazione di un documento HTML che consentono di definire la modalità di gestione di una pagina nei motori di ricerca durante l’indicizzazione del contenuto. Questo approccio offre il vantaggio di garantire che una pagina o versioni diverse di essa vengano indicizzate allo stesso modo anche quando l’URL della pagina presenta differenze.

Se, ad esempio, un sito include una versione di una pagina adatta alla stampa, un motore di ricerca potrebbe indicizzarla come pagina diversa da quella della versione normale della stessa pagina. Il tag canonico indica al motore di ricerca che tali pagine sono uguali.

Esempi:

Per entrambi viene applicato il seguente tag all’intestazione della pagina:

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

Il valore href può essere relativo o assoluto. Per determinare l’URL canonico per la pagina e generare questo tag, il codice deve essere incluso nel markup della pagina.

Configurazione del Dispatcher per rimuovere la distinzione tra maiuscole/minuscole configuring-the-dispatcher-for-case-insensitivity

Secondo la best practice, è consigliabile utilizzare solo lettere minuscole nei nomi di pagina. Se, però, non vuoi che un utente riceva un errore 404 quando accede al sito web utilizzando lettere maiuscole nell’URL, Adobe consiglia di aggiungere nella configurazione di Apache HTTP Server una regola di riscrittura per mappare tutti gli URL in arrivo utilizzando lettere minuscole. È inoltre necessario chiedere agli autori dei contenuti di utilizzare nomi contenenti solo lettere minuscole quando creano le pagine.

Per configurare Apache in modo che per tutto il traffico in entrata vengano utilizzate lettere minuscole, aggiungi quanto segue alla configurazione di vhost:

RewriteEngine On
RewriteMap lowercase int:tolower

Aggiungi inoltre quanto segue nella parte iniziale del file htaccess:

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

Implementazione di robots.txt per proteggere gli ambienti di sviluppo implementing-robots-txt-to-protect-development-environments

I motori di ricerca devono verificare la presenza di un file robots.txt nella directory principale del sito prima di eseguire la ricerca per l’indicizzazione del sito. Anche se i principali motori di ricerca come Google, Yahoo o Bing rispettano tutti questo file, alcuni motori di ricerca stranieri non lo rispettano.

Il modo più semplice per bloccare l’accesso all’intero sito consiste nell’inserire nella directory principale del sito un file denominato robots.txt con il seguente contenuto:

User-agent: *
Disallow: /

In alternativa, in un ambiente live, puoi scegliere di non consentire l’indicizzazione di determinati percorsi.

Bisogna però prestare attenzione quando si inserisce il file robots.txt nella directory principale del sito. Le richieste di svuotamento del Dispatcher potrebbero cancellare questo file. Inoltre, è probabile che le mappature URL posizionino la directory principale del sito in un punto diverso da DOCROOT come definito nella configurazione di Apache HTTP Server. Per questo motivo, questo file viene in genere inserito nell’istanza di authoring nella directory principale del sito e replicato nell’istanza di pubblicazione.

Creazione di una mappa del sito XML in AEM building-an-xml-sitemap-on-aem

I crawler utilizzano le mappe del sito XML per comprendere meglio la struttura dei siti web. Anche se non è detto che la creazione di una mappa del sito si traduca in un miglioramento dei ranking SEO, si tratta di una best practice comunemente accettata. Puoi gestire manualmente un file XML sul server web da utilizzare come mappa del sito. Tuttavia, l’Adobe consiglia di generare la mappa del sito a livello di programmazione, in modo che, quando gli autori creano contenuti, le modifiche apportate vengano applicate automaticamente alla mappa del sito.

AEM utilizza il modulo Sling Sitemap di Apache per generare mappe del sito XML. Questo modulo fornisce un’ampia gamma di opzioni che consentono agli sviluppatori e agli editor di mantenere aggiornata la mappa del sito XML.

Il modulo Sling Sitemap di Apache distingue tra una mappa del sito di livello superiore e una mappa del sito nidificata, entrambe generate per tutte le risorse per le quali la proprietà sling:sitemapRoot è impostata su true. In generale, le mappe del sito vengono sottoposte a rendering utilizzando i selettori nel percorso della mappa del sito di primo livello della struttura, che è la risorsa senza altri predecessori nella directory principale della mappa del sito. La directory principale della mappa del sito di primo livello espone anche l’indice della mappa del sito, che solitamente viene configurata da proprietario del sito nel portale di configurazione del motore di ricerca oppure aggiunta al file robots.txt del sito.

Ad esempio, considera un sito in cui la directory principale della mappa del sito di livello superiore è my-page e la directory principale di una mappa del sito nidificata è my-page/news, per generare una mappa del sito dedicata per le pagine della sottostruttura “news”. Gli url pertinenti risultanti sarebbero

Nella configurazione predefinita, la finestra di dialogo Proprietà pagina consente di contrassegnare una pagina come radice di una sitemap e quindi, come descritto in precedenza, di generare una sitemap di se stessa e dei suoi discendenti. Questo comportamento è implementato dalle implementazioni dell’interfaccia SitemapGenerator e può essere esteso aggiungendo implementazioni alternative. Tuttavia, poiché la frequenza con cui rigenerare sitemap XML dipende dai flussi di lavoro e dai carichi di lavoro per l'authoring dei contenuti, il prodotto non presenta configurazioni SitemapScheduler. In quanto tale, rende la funzione effettivamente opt-in.

Per abilitare il processo in background che genera sitemap XML, SitemapScheduler deve essere configurato. Per farlo, crea una configurazione OSGI per il PID org.apache.sling.sitemap.impl.SitemapScheduler. Espressione di pianificazione 0 0 0 * * ? può essere utilizzato come punto di partenza per rigenerare tutte le sitemap XML una volta al giorno a mezzanotte.

Il processo di generazione della sitemap può essere eseguito sia sulle istanze del livello di authoring che su quelle del livello di pubblicazione. In genere, si consiglia di eseguire la generazione sulle istanze del livello di pubblicazione, in quanto gli URL canonici corretti possono essere generati solo lì (a causa delle regole di mappatura risorse Sling comunemente presenti solo sulle istanze del livello di pubblicazione). Tuttavia, è possibile collegare un'implementazione personalizzata del meccanismo di esternalizzazione utilizzato per generare gli URL canonici implementando l'interfaccia SitemapLinkExternalizer. Se un'implementazione personalizzata è in grado di generare gli URL canonici di una sitemap sulle istanze del livello di authoring, SitemapScheduler può essere configurato per la modalità di esecuzione dell'autore. Inoltre, il carico di lavoro di generazione della mappa del sito XML può essere distribuito tra le istanze del cluster del servizio di authoring. In questo scenario, è necessario prestare attenzione alla gestione di contenuti non ancora pubblicati, modificati o visibili solo a un gruppo ristretto di utenti.

AEM Sites contiene un’implementazione predefinita di un SitemapGenerator che attraversa una struttura ad albero di pagine per generare una sitemap. È preconfigurato per generare solo gli URL canonici di un sito e qualsiasi alternativa linguistica, se disponibile. Può anche essere configurato in modo da includere l’ultima data modificata di una pagina, se necessario. Per farlo, abilita l'opzione Aggiungi ultima modifica della configurazione Adobe AEM SEO - Page Tree Sitemap Generator e seleziona un Last Modified Source. Quando vengono generate le mappe del sito sul livello di pubblicazione, si consiglia di utilizzare la data cq:lastModified.

Per limitare il contenuto di una sitemap, è possibile implementare le seguenti interfacce di servizio quando necessario:

Se le implementazioni predefinite non funzionano su un particolare caso d'uso, o se i punti di estensione non sono abbastanza flessibili, implementa un SitemapGenerator personalizzato per assumere il controllo completo del contenuto di una sitemap generata. Nell'esempio seguente viene utilizzata la logica di implementazione predefinita per AEM Sites. Utilizza il ResourceTreeSitemapGenerator come punto iniziale per scorrere la struttura ad albero delle pagine:

import java.util.Optional;

import org.apache.sling.api.resource.Resource;
import org.apache.sling.sitemap.SitemapException;
import org.apache.sling.sitemap.builder.Sitemap;
import org.apache.sling.sitemap.builder.Url;
import org.apache.sling.sitemap.spi.common.SitemapLinkExternalizer;
import org.apache.sling.sitemap.spi.generator.ResourceTreeSitemapGenerator;
import org.apache.sling.sitemap.spi.generator.SitemapGenerator;
import org.jetbrains.annotations.NotNull;
import org.osgi.service.component.annotations.Component;
import org.osgi.service.component.annotations.Reference;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import com.adobe.aem.wcm.seo.sitemap.PageTreeSitemapGenerator;
import com.day.cq.wcm.api.Page;

@Component(
    service = SitemapGenerator.class,
    property = { "service.ranking:Integer=20" }
)
public class SitemapGeneratorImpl extends ResourceTreeSitemapGenerator {

    private static final Logger LOG = LoggerFactory.getLogger(SitemapGeneratorImpl.class);

    @Reference
    private SitemapLinkExternalizer externalizer;
    @Reference
    private PageTreeSitemapGenerator defaultGenerator;

    @Override
    protected void addResource(@NotNull String name, @NotNull Sitemap sitemap, Resource resource) throws SitemapException {
        Page page = resource.adaptTo(Page.class);
        if (page == null) {
            LOG.debug("Skipping resource at {}: not a page", resource.getPath());
            return;
        }
        String location = externalizer.externalize(resource);
        Url url = sitemap.addUrl(location + ".html");
        // add any additional content to the Url like lastmod, change frequency, and so on
    }

    @Override
    protected final boolean shouldFollow(@NotNull Resource resource) {
        return super.shouldFollow(resource)
            && Optional.ofNullable(resource.adaptTo(Page.class)).map(this::shouldFollow).orElse(Boolean.TRUE);
    }

    private boolean shouldFollow(Page page) {
        // add additional conditions to stop traversing some pages
        return !defaultGenerator.isProtected(page);
    }

    @Override
    protected final boolean shouldInclude(@NotNull Resource resource) {
        return super.shouldInclude(resource)
            && Optional.ofNullable(resource.adaptTo(Page.class)).map(this::shouldInclude).orElse(Boolean.FALSE);
    }

    private boolean shouldInclude(Page page) {
        // add additional conditions to stop including some pages
        return defaultGenerator.isPublished(page)
            && !defaultGenerator.isNoIndex(page)
            && !defaultGenerator.isRedirect(page)
            && !defaultGenerator.isProtected(page);
    }
}

Inoltre, la funzionalità implementata per le sitemap XML può essere utilizzata per casi d’uso diversi, ad esempio per aggiungere il collegamento canonico o la lingua nell’intestazione di una pagina. Per ulteriori informazioni, vedere l'interfaccia SeoTags.

Creazione di reindirizzamenti 301 per gli URL legacy creating-redirects-for-legacy-urls

Quando si lancia un sito con una nuova struttura, è fondamentale implementare e testare i reindirizzamenti 301 in Apache HTTP Server per due motivi:

Consulta la sezione seguente, dove troverai risorse aggiuntive con istruzioni sull’implementazione dei reindirizzamenti 301, nonché uno strumento per verificare che i reindirizzamenti funzionino come previsto.

Risorse aggiuntive additional-resources

Per ulteriori informazioni, consulta le seguenti risorse aggiuntive: