Bästa praxis för hantering av SEO och URL seo-and-url-management-best-practices

Sökmotoroptimering (SEO) har blivit en viktig fråga för många marknadsförare. Därför måste SEO:s problem hanteras i många AEM projekt.

Det här dokumentet beskriver först några Bästa praxis för SEO och rekommendationer för att uppnå dessa när det gäller AEM implementering. Sedan får du en närmare titt på några av de mer komplexa implementeringsstegen som togs upp i det första avsnittet.

SEO-metodtips seo-best-practices

I det här avsnittet beskrivs några allmänna SEO-metodtips.

URL:er urls

Det finns vissa allmänt vedertagna bästa metoder för URL:er.

Ställ följande fråga när du utvärderar URL:er i ett AEM-projekt:

Om svaret är ja är det troligt att URL:en är lämplig för en sökmotor.

Här följer några allmänna tips om hur du skapar URL:er för SEO:

Serverkonfiguration server-configuration

Följ följande steg för serverkonfigurationen för att se till att endast rätt innehåll crawlas:

AEM-konfigurationer aem-configurations

I det här avsnittet beskrivs de implementeringssteg som krävs för att konfigurera AEM för att följa dessa SEO-rekommendationer.

Använda Sling-väljare using-sling-selectors

Tidigare var användning av frågeparametrar den allmänt accepterade metoden när ett företagswebbprogram byggdes.

Trenden under de senaste åren har varit att ta bort dessa i ett försök att göra webbadresserna enklare att läsa. På många plattformar innebär det att omdirigeringar implementeras på webbservern eller innehållsleveransnätverket (CDN) – men Sling gör det enklare. Sling-väljare:

Använda väljare för servletar using-selectors-for-servlets

AEM ger oss två alternativ när vi skriver servletar:

Följande exempel visar hur du registrerar servletar som följer båda dessa mönster samt fördelarna med att använda Sling-servletar.

Bin-servletar (en nivå ned) bin-servlets-one-level-down

Bin-servletar följer mönstret som många utvecklare är vana vid från J2EE-programmering. Servleten registreras på en viss sökväg, som för AEM vanligtvis finns under /bin, och du extraherar de nödvändiga parametrarna från frågesträngen.

SCR-anteckningen för den här typen av servlet skulle se ut ungefär så här:

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

Sedan extraherar du parametrarna från frågesträngen via objektet SlingHttpServletRequest som finns i metoden doGet. Till exempel:

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

Den URL som skapas skulle se ut ungefär så här:

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

Några saker att ha i åtanke:

Sling-servletar (en nivå ned) sling-servlets-one-level-down

Med Sling-servletar kan du registrera en servlet på motsatt sätt. I stället för att adressera en servlet och ange det innehåll som du vill att servleten ska återge baserat på frågeparametrarna, kan du adressera det innehåll som du vill ha och ange den servlet som ska återge innehållet baserat på Sling-väljare.

SCR-anteckningen för den här typen av servlet skulle se ut ungefär så här:

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

I det här fallet är den resurs som URL:en adresserar (en instans av resursen myPageType) automatiskt tillgänglig i servleten. För att få åtkomst till den ska du anropa:

Resource myPage = req.getResource();

Den URL som skapas skulle se ut ungefär så här:

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

Fördelarna med det här tillvägagångssätt är:

URL-omskrivning url-rewriting

I AEM lagras alla webbplatser under /content/my-brand/my-content. Det kan vara användbart för databashantering, men det är inte nödvändigtvis så du vill att dina kunder ska se din webbplats och det kan strida mot SEO-riktlinjen som förespråkar att URL:er ska hållas så korta som möjligt. Dessutom kan du betjäna flera webbplatser från samma AEM-instans och från olika domännamn.

I det här avsnittet beskrivs alternativen i AEM som används för att hantera URL:erna och hur de kan presenteras för användarna på ett mer läsbart och SEO-vänligt sätt.

Alternativa URL:er vanity-urls

Om en författare vill att en sida ska vara tillgänglig från en andra plats i marknadsföringssyfte, kan det vara användbart att definiera alternativa URL:er, sida för sida, för AEM. Om du vill lägga till en ogiltig URL-adress för en sida går du till den i Sites konsol och redigera sidegenskaperna. Längst ned på Basic visas ett avsnitt där det går att lägga till mål-URL:er. Tänk på att sidans SEO-värde fragmenteras om sidan är tillgänglig via mer än en URL. Du kan dock undvika det här problemet genom att lägga till en kanonisk URL-tagg på sidan.

Lokaliserade sidnamn localized-page-names

Du kanske vill visa lokaliserade sidnamn för användare av översatt innehåll. Till exempel:

Utmaningen med att lokalisera sidans namn är att många av de lokaliseringsverktyg som är tillgängliga på AEM-plattformen kräver att sidnamnen matchar för alla språk för att innehållet ska kunna synkroniseras.

Egenskapen sling:alias gör att du både kan äta kakan och ha den kvar. Du kan lägga till sling:alias som en egenskap för alla resurser för att tillåta att ett aliasnamn används för resursen. I föregående exempel skulle du få:

På så sätt kan AEM-översättningsverktyg som Multi Site Manager fortsätta att upprätthålla relationen mellan:

Samtidigt som slutanvändarna kan visa sidnamnen på olika språk.

/etc/map etc-map

I en vanlig AEM-installation:

Mappningsdefinitioner kan läggas till på den här platsen för att mappa inkommande begäranden, skriva om URL:er på sidorna i AEM, eller både och.

Om du vill skapa en ny mappning ska du skapa en ny sling:Mapping-nod på den här platsen under /http eller /https. Baserat på egenskaperna sling:match och sling:internalRedirect som har angetts för den här noden dirigerar AEM om all trafik för den matchade URL:en till det värde som har angetts i egenskapen internalRedirect.

Det här är den metod som beskrivs i den officiella AEM- och Sling-dokumentationen, men det stöd för reguljära uttryck som tillhandahålls av implementeringen är begränsat i omfattning jämfört med de alternativ som är tillgängliga om SlingResourceResolver används direkt. Implementering av mappningar på det här sättet kan dessutom leda till problem med cachelagring av ogiltighetsposter.

Här är ett exempel på hur problemet uppstår:

Det finns sätt att konfigurera anpassade rensningsregler för dispatcher som mappar den kortare URL:en till den längre URL:en för cachelagring av ogiltighetsposter.

Det finns dock ett enklare sätt att hantera det här på:

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

Hittills har du implementerat mappningar tillsammans med logiken i dina komponenter för att använda mappningarna när du skriver URL:er på våra sidor.

Den sista biten i pusslet är att hantera de förkortade URL:erna när de kommer till dispatchern, och det är nu som mod_rewrite kommer in i bilden. Den största fördelen med att använda mod_rewrite är att URL:erna mappas tillbaka till de långa versionerna innan de skickas till dispatchermodulen. Det innebär att dispatchern begär den långa URL:en från publiceringsservern och cachelagrar den därefter. Alla begäranden om rensning av dispatchern som kommer in från publiceringsservern kan därför göra det här innehållet ogiltigt.

Om du vill implementera den här reglerna kan du lägga till RewriteRule-element under den virtuella värden i Apache HTTP Server-konfigurationen. Om du vill utöka de förkortade URL:erna från det tidigare exemplet kan du implementera en regel som ser ut så här:

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

Kanoniska URL-taggar canonical-url-tags

Kanoniska URL-taggar är länktaggar som placeras i ett HTML-dokuments sidhuvud för att klargöra hur sökmotorer ska hantera en sida när innehållet indexeras. Fördelen som de ger är att de säkerställer att (olika versioner av) en sida indexeras som samma sida även när sidans URL kan innehålla skillnader.

Om en webbplats till exempel har en utskriftsvänlig version av en sida skulle en sökmotor kunna indexera sidan separat från den vanliga versionen av sidan. Den kanoniska taggen anger för sökmotorn att de är samma sida.

Exempel:

Båda skulle använda följande tagg i sidans sidhuvud:

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

href kan vara relativt eller absolut. Koden bör inkluderas i sidmarkeringen för att fastställa sidans kanoniska URL och returnera den här taggen.

Konfigurera dispatchern för skiftlägesokänslighet configuring-the-dispatcher-for-case-insensitivity

Den bästa metoden är att skicka alla sidor med gemener. Du vill däremot inte att en användare som får åtkomst till webbplatsen med URL med versaler får en 404-felkod. Därför rekommenderar Adobe att du lägger till en omskrivningsregel i Apache HTTP Server-konfigurationen för att mappa alla inkommande URL:er till gemener. Dessutom måste innehållsförfattarna få utbildning i hur de skapar sidor med namn i gemener.

Lägg till följande i vhost-konfigurationen om du vill konfigurera Apache för att tvinga all inkommande trafik till gemener:

RewriteEngine On
RewriteMap lowercase int:tolower

Lägg dessutom till följande längst upp i filen htaccess:

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

Implementera robots.txt för att skydda utvecklingsmiljöer implementing-robots-txt-to-protect-development-environments

Sökmotorer bör kontrollera om det finns en robots.txt-fil i webbplatsroten innan de crawlar webbplatsen. Det bör understrykas att även om stora sökmotorer som Google, Yahoo och Bing gör det, så gör inte vissa utländska sökmotorer det.

Det enklaste sättet att blockera åtkomst till hela webbplatsen är att placera en fil med namnet robots.txt i webbplatsroten med följande innehåll:

User-agent: *
Disallow: /

I en aktiv miljö kan du även välja att inte tillåta specifika sökvägar som du inte vill indexera.

Något att tänka på när robots.txt-filen placeras i webbplatsroten är att begäranden om rensning av dispatchern kan ta bort filen och URL-mappningar kommer troligtvis att placera webbplatsroten på en annan plats än DOCROOT, enligt Apache HTTP Server-konfigurationen. Därför är det vanligt att placera den här filen på författarinstansen i webbplatsroten och replikera den till publiceringsinstansen.

Bygga en XML-webbplatskarta på AEM building-an-xml-sitemap-on-aem

Crawlers använder XML-webbplatskartor för att bättre förstå webbplatsernas struktur. Det är en vedertagen bästa metod, även om det inte finns någon garanti för att en webbplatskarta kommer att ge en förbättrad SEO-rankning. Du kan underhålla en XML-fil manuellt på webbservern och använda den som en webbplatskarta, men vi rekommenderar att du genererar webbplatskartan programmatiskt, vilket säkerställer att webbplatskartan automatiskt återspeglar ändringarna när författare skapar nytt innehåll.

Om du vill skapa en webbplatskarta programmatiskt registrerar du en Sling-servlet som lyssnar efter ett sitemap.xml-anrop. Servleten kan sedan använda resursen som tillhandahålls via servletens API för att titta på den aktuella sidan och dess underordnade sidor, och skapa XML. XML-filen cachelagras sedan i dispatchern. Den här platsen bör refereras till i egenskapen för webbplatskartan för filen robots.txt. Dessutom måste en anpassad rensningsregel implementeras för att säkerställa att filen rensas när en ny sida aktiveras.

Skapa 301-omdirigeringar för äldre URL:er creating-redirects-for-legacy-urls

När du startar en webbplats med en ny struktur är det av två skäl viktigt att implementera och testa 301-omdirigeringar i Apache HTTP Server:

Anvisningar för hur 301-omdirigeringar implementeras och information om ett verktyg som kan användas för att testa att omdirigeringarna fungerar som väntat finns i följande avsnitt.

Ytterligare resurser additional-resources

Mer information finns i följande resurser: