Best Practices für SEO und URL-Verwaltung

Suchmaschinenoptimierung (SEO) ist zu einem wichtigen Thema für viele Marketer geworden. Deshalb müssen SEO-Thematiken bei vielen AEM-Projekten berücksichtigt werden.

Dieses Dokument beschreibt zunächst einige Best Practices für SEO und Empfehlungen zu deren Erreichung bei einer AEM-Implementierung. Anschließend beschäftigt sich das Dokument intensiver mit einigen der komplexeren Implementierungsschritte aus dem ersten Abschnitt.

Best Practices für SEO

Dieser Abschnitt beschreibt einige allgemeine Best Practices für SEO

URLs

Hinsichtlich URLs bestehen einige allgemein akzeptierte Best Practices.

Wenn Sie URLs für Ihr AEM-Projekt bewerten, stellen Sie sich die folgenden Fragen:

„Wäre ein Benutzer in der Lage zu beschreiben, worum es auf der Seite geht, wenn er nur die URL und nicht den Inhalt der Seite sähe?“

Wenn die Antwort „ja“ lautet, ist es wahrscheinlich, dass die URL für Suchmaschinen gut funktioniert.

Im Folgenden finden Sie einige allgemeine Tipps zum Erstellen von URLs für SEO:

  • Verwenden Sie Bindestriche, um Wörter voneinander zu trennen.

    • Verwenden Sie Bindestriche (-) als Trenner zwischen Seitennamen.
    • Vermeiden Sie Binnenmajuskeln, Unterstriche und Leerzeichen.
  • Vermeiden Sie, wenn möglich, die Verwendung von Abfrageparametern. Falls erforderlich, begrenzen Sie diese auf maximal zwei.

    • Verwenden Sie eine Verzeichnisstruktur, um die Informationsarchitektur, falls vorhanden, darzustellen.
    • Wenn eine Verzeichnisstruktur keine Option ist, verwenden Sie Sling-Selektoren anstelle von Abfragefolgen. Zusätzlich zu den gebotenen SEO-Vorteilen ermöglichen Sling-Selektoren dem Dispatcher außerdem die Zwischenspeicherung der Seiten.
  • Je leichter es für Menschen ist, die URL zu lesen, desto besser. Die Verwendung von Keywords in der URL macht diese wertvoller.

    • Selektoren, die einen semantischen Wert bieten, sind auf Seiten, die Selektoren verwenden, zu bevorzugen.

    • Wenn ein Mensch Ihre URL nicht lesen kann, kann eine Suchmaschine das auch nicht.

    • Beispiel:

      mybrand.com/products/product-detail.product-category.product-name.html
      wird bevorzugt mybrand.com/products/product-detail.1234.html

  • Vermeiden Sie Subdomänen wo möglich, da Suchmaschinen diese als unterschiedliche Einheiten einordnen und so den SEO-Wert der Website fragmentieren.

    • Nutzen Sie stattdessen Unterpfade auf erster Ebene. For example, instead of es.mybrand.com/home.html, use www.mybrand.com/es/home.html.

    • Planen Sie die Inhaltshierarchie passend zur der Art und Weise, wie die Inhalte dargestellt werden, gemäß dieser Richtlinie.

  • Die Effektivität von Keywords in URLs nimmt bei mit zunehmender Länge der URL und späterer Position des Keywords ab. Anders ausgedrückt, kürzer ist besser.

    • Nutzen Sie die von AEM zur Verfügung gestellten Techniken und Funktionen zum Kürzen von URLs, um unnötige URL-Elemente zu entfernen.
    • Dies mybrand.com/en/myPage.html wird beispielsweise bevorzugt mybrand.com/content/my-brand/en/myPage.html.
  • Verwenden Sie kanonische URLs.

    • When a URL can be served from different paths or with different parameters or selectors, make sure to use a rel=canonical tag on the page.

    • Dieses kann im Code für die AEM-Vorlage enthalten sein.

  • Passen Sie URLs wann immer möglich an Seitentitel an.

    • Inhaltsautoren sollten dazu ermutigt werden, diese Praxis zu befolgen.
  • Unterstützen Sie das Ignorieren von Groß- und Kleinschreibung in URL-Anfragen.

    • Konfigurieren Sie den Dispatcher so, dass alle eingehenden Anfragen in Kleinbuchstaben umgeschrieben werden.
    • Schulen Sie die Autoren darin, sämtliche Seiten mit Kleinbuchstaben zu erstellen.
  • Stellen Sie sicher, dass jede Seite nur von einem Protokoll bedient wird.

    • Manchmal werden Websites über http bedient, bis ein Benutzer eine Seite erreicht, die beispielsweise ein Zahlungsformular oder Anmeldeformular enthält, weswegen die Seite in das https-Format wechselt. Wenn von dieser Seite aus verlinkt wird und der Benutzer auf http-Seiten zurückkehren und auf diese über https zugreifen kann, verfolgt die Suchmaschine diese als zwei getrennte Seiten.

    • Google currently prefers https pages to http ones. Aus diesem Grund ist es häufig für alle Beteiligten einfacher, die ganze Website über https zu bedienen.

Serverkonfiguration

Hinsichtlich der Serverkonfiguration können Sie mit den folgenden Schritten gewährleisten, dass nur korrekte Inhalte durchsucht werden:

  • Use a robots.txt file to block crawling of any content that should not be indexed.

    • Blockieren Sie sämtliches Crawling in den Testumgebungen.
  • Richten Sie beim Launch einer neuen Website mit aktualisierten URLs eine 301-Weiterleitung ein, um sicherzustellen, dass das derzeitige SEO-Ranking nicht verloren geht.

  • Fügen Sie der Website ein Favicon hinzu.

  • Implementieren Sie eine XML-Sitemap, um Suchmaschinen das Durchsuchen des Inhalts zu erleichtern. Sorgen Sie dafür, dass mobile und/oder responsive Sites über eine mobile Sitemap verfügen.

AEM-Konfigurationen

In diesem Abschnitt werden die notwendigen Implementierungsschritte für die AEM-Konfiguration zur Befolgung dieser SEO-Empfehlungen erläutert.

Verwenden von Sling-Selektoren

Früher war die Verwendung von Abfrageparametern allgemein akzeptierte Praxis bei der Erstellung einer Webanwendung für Unternehmen.

In den letzten Jahren geht der Trend jedoch dahin, diese zu entfernen, um URLs lesbarer zu gestalten. Bei vielen Plattform beinhaltet dies die Einführung von Weiterleitungen auf dem Webserver oder dem Content Delivery Network (CDN), Sling macht dies jedoch zu einem geradlinigeren Prozess. Sling-Selektoren:

  • verbessern die Lesbarkeit der URL;
  • ermöglichen es, die Seiten auf dem Dispatcher zwischenzuspeichern, was häufig die Sicherheit erhöht;
  • ermöglichen es, Inhalte direkt zu bearbeiten, anstelle der Verwendung eines allgemeinen Servlets zur Inhaltsabfrage. Dadurch erhalten Sie die Vorteile von ACLs, die Sie auf das Repository anwenden, und Filter, die Sie für den Dispatcher verwenden.

Verwenden von Selektoren für Servlets

AEM bietet uns zwei Optionen zum Schreiben von Servlets:

  • Container-Servlets;
  • Sling-Servlets.

Das folgende Beispiel zeigt, wie diesen beiden Mustern folgende Servlets registriert werden, sowie den Vorteil, der durch die Verwendung von Sling-Servlets erzielt wird.

Container-Servlets (eine Ebene nach unten)

Container-Servlets folgen dem Muster, das viele Entwickler für die J2EE-Programmierung verwenden. The servlet is registered at a specific path, which in the case of AEM is usually under /bin, and you extract the needed request parameters from the query string.

Der SCR-Vermerk für diese Art von Servlet sieht in etwa so aus:

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

You then extract the parameters from the query string via the SlingHttpServletRequest object that is included in the doGet method; for example:

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

Die daraus resultierende URL könnte beispielsweise in etwa so aussehen:

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

Es gibt einige Aspekte, die bei diesem Ansatz berücksichtigt werden sollten:

  • Die URL selbst verliert an SEO-Wert. Die auf die Website zugreifenden Benutzer, einschließlich Suchmaschinen, erhalten keinerlei semantischen Wert von der URL, da die URL einen Programmierungspfad darstellt und nicht die Inhaltshierarchie.
  • Die Anwesenheit von Abfrageparametern in der URL bedeutet, dass der Dispatcher nicht in der Lage ist die Antwort zwischenzuspeichern.
  • Wenn Sie dieses Servlet sicher möchten, müssen Sie Ihre eigene benutzerdefinierte Sicherheitslogik in dieses Servlet implementieren.
  • The dispatcher must be configured (carefully) to expose /bin/myApp/myServlet. Simply exposing /bin would allow access to certain servlets that should not be open to site visitors.

Sling-Servlets (eine Ebene nach unten)

Sling-Servlets ermöglichen die Registrierung von Servlets auf gegensätzliche Art und Weise. Anstatt ein Servlet zu adressieren und den Inhalt festzulegen, welchen dieses basierend auf den Abfrageparametern rendern soll, adressieren Sie den gewünschten Inhalt und legen das Servlet fest, das den Inhalt basierend auf den Sling-Selektoren rendern soll.

Der SCR-Vermerk für diese Art von Servlet sieht in etwa so aus:

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

In diesem Fall ist die Ressource, welche die URL bedient (ein Fall einer myPageType Ressource) in dem Servlet automatisch zugänglich. Um darauf zuzugreifen, rufen Sie Folgendes ab:

Resource myPage = req.getResource();

Die daraus resultierende URL könnte beispielsweise in etwa so aussehen:

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

Die Vorteile dieses Ansatzes:

  • Sie können den SEO-Wert, der durch die auf der Site-Hierarchie und im Seitennamen vorhandenen Semantiken erzielt wird, mit einbeziehen.
  • Da keine Abfrageparameter vorhanden sind, kann der Dispatcher die Antwort zwischenspeichern. Zusätzlich machen jegliche Updates auf der adressierten Seite diese Zwischenspeicherung ungültig, wenn die Seite aktiviert wird.
  • All ACLs applied to /content/my-brand/my-page will come into effect when a user tries to access this servlet.
  • Der Dispatcher ist bereits konfiguriert, um diesen Inhalt als Bestandteil der Bedienung der Website zu bedienen. Es ist keine zusätzliche Konfiguration notwendig.

Umschreiben der URL

In AEM, all of your web pages are stored under /content/my-brand/my-content. Während dies aus der Perspektive der Repository-Datenverwaltung nützlich sein kann, ist dies nicht notwendigerweise die Art und Weise, wie Ihre Kunden die Website sehen sollen, und kann im Widerspruch zu den SEO-Richtlinien stehen, URLs so kurz wie möglich zu halten. Darüber hinaus können Sie mehrere Websites aus derselben AEM-Instanz und aus verschiedenen Domänennamen bereitstellen.

Dieser Abschnitt erläutert die verfügbaren AEM-Optionen zum Verwalten und der Präsentation dieser URLs gegenüber dem Benutzer auf leichter lesbare, SEO-freundliche Weise.

Vanity-URLs

Wenn ein Autor wünscht, dass die Seite von einem zweiten Ort aus für Werbezwecke zugänglich ist, können die auf Seitenbasis definierten Vanity-URLs von AEM nützlich sein. To add a vanity URL for a page, navigate to it in the Sites console and edit the page properties. At the bottom of the Basic tab, you see a section where vanity URLs can be added. Bedenken Sie, dass die Zugänglichkeit einer Seite über mehr als eine URL den SEO-Wert der Seite fragmentiert. Der Seite sollte also ein kanonisches URL-Tag hinzugefügt werden, um dieses Problem zu vermeiden.

Lokalisierte Seitennamen

Sie möchten eventuell lokalisierte Seitennamen für Benutzer übersetzter Inhalte anzeigen. Beispiel:

  • Anstatt einen Spanisch sprechenden Benutzer zu haben, navigieren Sie zu:
    www.mydomain.com/es/home.html

  • Die URL sollte besser sein:
    www.mydomain.com/es/casa.html.

Die Herausforderung bei der Lokalisierung des Seitennamens besteht darin, dass viele der für die AEM-Plattform erhältlichen Lokalisierungswerkzeuge für die Synchronisierung von Inhalten identische Seitennamen für verschiedene Sprachen benötigen.

Die Eigenschaft sling:alias Eigenschaft ermöglicht beides. sling:alias kann jeder Ressource als Eigenschaft hinzugefügt werden, um einen Alias für die Ressource zu erlauben. Im vorangegangenen Beispiel hätten Sie Folgendes:

  • Eine Seite in JCR unter:
    …/es/home

  • Fügen Sie dann eine Eigenschaft hinzu:
    sling:alias = casa

Dies würde es den AEM-Übersetzungswerkzeugen wie dem Multi-Site-Manager ermöglichen, eine Beziehung zwischen

  • /en/home

  • /es/home

während es Benutzern ermöglicht wird, in ihrer Muttersprache mit dem Seitennamen zu interagieren.

Hinweis

Die sling:alias Eigenschaft kann beim Bearbeiten der Seiteneigenschaften mithilfe der Alias-Eigenschaft festgelegt werden.

/etc/map

Bei der Standardinstallation von AEM:

  • für die OSGi-Konfiguration
    Apache Sling Resource Resolver Factory
    ( org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl)

  • the-Eigenschaft
    Zuordnungsort ( resource.resolver.map.location)

  • defaults to /etc/map.

Zuordnungsdefinitionen können in diesem Verzeichnis hinzugefügt werden, um eingehende Anfragen zuzuordnen, URLs auf Seiten in AEM umzuschreiben oder beides.

To create a new mapping, create a new sling:Mapping node in this location under /http or /https. Basierend auf den Eigenschaften sling:match und sling:internalRedirect, die für diesen Knoten eingestellt sind, leitet AEM sämtlichen Traffic für die passende URL an den in der Eigenschaft internalRedirect spezifizierten Wert weiter.

Während dies der Ansatz ist, der in der offiziellen AEM- und Sling-Dokumentation aufgeführt wird, ist die von dieser Implementierung bereitgestellte Unterstützung für reguläre Ausdrücke im Vergleich zu den Optionen, die durch die direkte Verwendung von SlingResourceResolver zur Verfügung gestellt werden, begrenzt. Außerdem kann die Implementierung von Zuordnungen auf diese Art zu Problemen mit der Invalidierung des Dispatcher-Cache führen.

Ein Beispiel dafür, wie dieses Problem auftritt:

  1. A user visits your website and requests https://www.mydomain.com/my-page.html

  2. Der Dispatcher leitet diese Anfrage an den Veröffentlichungsserver weiter.

  3. Using /etc/map, the publish server resolves this request to /content/my-brand/my-page and renders the page.

  4. The dispatcher caches the response at /my-page.html and returns the response to the user.

  5. Ein Inhaltsautor ändert diese Seite und aktiviert sie.

  6. The dispatcher flush agent sends an invalidation request for /content/my-brand/my-page.​Da der Dispatcher an diesem Pfad keine Seite zwischengespeichert hat, bleibt der alte Inhalt zwischengespeichert und ist statisch.

Es gibt Möglichkeiten, benutzerdefinierte Dispatch-Flush-Regeln zu konfigurieren, welche die kürzere URL zur Invalidierung des Cache an die längere URL weiterleiten.

Es gibt jedoch einfachere Möglichkeiten, dies zu lösen:

  1. SlingResourceResolver-Regeln

    Verwenden Sie die Web-Konsole (zum Beispiel localhost:4502/system/console/configMgr) zur Konfiguration von Sling Resource Resolver:

    • Apache Sling Resource Resolver Factory

      (org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl).
      Es wird empfohlen, die zur Kürzung von URLs zu regulären Ausdrücken notwendigen Zuordnungen zu erstellen und diese Konfigurationen dann unter einem OsgiConfignod, config.publish, zu definieren, der im Build enthalten ist.

    Rather than defining your mappings in /etc/map, they can be assigned directly to the property URL Mappings ( resource.resolver.mapping):

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

    In this simple example, you are removing /content/my-brand/ from the beginning of any URL where it is present.

    Dadurch würde eine URL umgewandelt:

    • from /content/my-brand/my-page.html
    • nur /my-page.html

    Dies steht im Einklang mit den empfohlenen Verfahren, URLs so kurz wie möglich zu halten.

  2. Zuordnen von URL-Output auf Seiten

    Nachdem Sie die Zuordnungen im Apache Sling Resource Resolver definiert haben, müssen Sie diese Zuordnungen in den Komponenten verwenden, um zu gewährleisten, dass die URLs auf Ihren Seiten kurz und ordentlich sind. You can do this by using the map function of the ResourceResolver.

    Wenn Sie beispielsweise eine benutzerdefinierte Navigationskomponente implementieren, welche die untergeordneten Elemente der aktuellen Seite auflistet, können Sie die Zuordnungsmethode wie folgt verwenden:

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

Apache HTTP-Server mod_rewrite

Bislang haben Sie Zuordnungen zusammen mit der Logik in Ihren Komponenten implementiert, um diese Zuordnungen beim Ausgeben von URLs auf unseren Seiten zu verwenden.

Das letzte Teil des Puzzles besteht darin, diese gekürzten URLs zu verwalten, wenn sie beim Dispatcher ankommen, wobei mod_rewrite ins Spiel kommt. Der größte Vorteil bei der Verwendung von mod_rewrite besteht darin, dass die URLs zurück in ihre Langform gebracht werden, bevor sie an das Dispatcher-Modul gesendet werden. Das bedeutet, dass der Dispatcher die lange URL vom Veröffentlichungsserver abfragt und diese entsprechend zwischenspeichert. Sämtliche vom Veröffentlichungsserver ausgehenden Dispatcher-Flush-Anfragen können diesen Inhalt erfolgreich ungültig machen.

Um diese Regeln zu implementieren, können Sie RewriteRule-Elemente unter Ihrem virtuellen Host in der Apache HTTP Server-Konfiguration hinzufügen. Wenn Sie gekürzte URLs aus dem vorherigen Beispiel erweitern möchten, können Sie eine Regel implementieren, die folgendermaßen aussieht:

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

Kanonische URL-Tags

Kanonische URL-Tags sind Link-Tags die in der Kopfzeile des HTML-Dokuments eingegeben werden und festlegen, wie Suchmaschinen die Seite bei der Indizierung des Inhalts behandeln sollen. Ihr Vorteil besteht darin, dass sichergestellt wird, dass eine Seite (verschiedene Versionen davon) auf gleiche Weise indiziert wird, auch wenn die auf die Seite verweisende URL Unterschiede enthält.

Bietet eine Website beispielsweise eine druckfreundliche Version einer Seite an, könnte eine Suchmaschine diese Seite getrennt von der regulären Version der Seite indizieren. Das kanonische Tag erklärt der Suchmaschine, dass es sich um dieselbe Seite handelt.

Beispiele:

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

Bei beiden würde das folgende Tag der Kopfzeile der Seite hinzugefügt:

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

Das href-Attribut kann relativ oder absolut sein. Der Code sollte im Seitenmarkup enthalten sein, um die kanonische URL für die Seite zu ermitteln und dieses Tag auszugeben.

Konfigurieren des Dispatchers für das Ignorieren von Groß- und Kleinschreibung

Die Best Practice besteht darin, alle Seiten mit Kleinbuchstaben zu bedienen. Sie wollen jedoch vermeiden, dass der Benutzer einen 404-Fehler erhält, wenn er versucht, unter Verwendung von Großbuchstaben in der URL auf die Website zuzugreifen. Aus diesem Grund empfiehlt Adobe, in der Apache HTTP-Serverkonfiguration eine Regel zum Umschreiben hinzuzufügen, um alle eingehenden URLs Kleinbuchstaben zuzuordnen. Darüber hinaus müssen Autoren dahingehend geschult werden, Seiten nur mit Namen in Kleinbuchstaben zu erstellen.

Um Apache so zu konfigurieren, dass sämtlicher eingehender Traffic in Kleinbuchstaben erfolgt, fügen Sie der Konfiguration vhost Folgendes hinzu:

RewriteEngine On
RewriteMap lowercase int:tolower

Fügen Sie zusätzlich Folgendes am Anfang der Datei htaccess hinzu:

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

Implementieren von robots.txt zum Schutz von Entwicklungsumgebungen

Suchmaschinen sollten das Vorhandensein einer Datei robots.txt im Stammverzeichnis der Website überprüfen, bevor die Website durchsucht wird. Sollte hier hervorgehoben werden, denn während große Suchmaschinen wie Google, Yahoo oder Bing dies alle respektieren, tun dies einige ausländische Suchmaschinen nicht.

Die einfachste Möglichkeit, den Zugang zu der gesamten Website zu blockieren, ist eine Datei namens robots.txt im Stammverzeichnis der Website zu platzieren, die Folgendes enthält:

User-agent: *
Disallow: /

Wahlweise können Sie in einer Live-Umgebung bestimmte Pfade ablehnen, die nicht indiziert werden sollen.

The caveat with placing the robots.txt file at the site root is that dispatcher flush requests may clear this file out and URL mappings will likely place the site root somewhere different than the DOCROOT as defined in the Apache HTTP Server configuration. Aus diesem Grund ist es üblich, diese Datei in der Autoreninstanz am Site-Stamm zu platzieren und sie in der Veröffentlichungsinstanz zu replizieren.

Erstellen einer XML-Sitemap in AEM

Crawler verwenden XML-Sitemaps, um die Websitestrukturen besser zu verstehen. Während es keine Garantie dafür gibt, dass die Bereitstellung einer Sitemap zu verbesserten SEO-Rankings führt, ist dies dennoch eine allgemein anerkannte Best Practice. Sie können die XML-Datei manuell auf einem Webserver als Sitemap verwalten, es wird jedoch empfohlen, die Sitemap programmatisch zu generieren, was gewährleistet, dass die Sitemap automatisch Änderungen widerspiegelt, sobald sie von den Autoren vorgenommen werden.

Um eine Sitemap programmatisch zu generieren, registrieren Sie einen Sling-Servlet-Listener für eine sitemap.xml-Anfrage. Das Servlet kann dann die über die Servlet-API bereitgestellten Ressourcen verwenden, um die aktuelle Seite und deren untergeordnete Elemente zu sehen, und gibt dabei XML aus. Die XML-Datei wird dann vom Dispatcher zwischengespeichert. Auf diesen Ort sollte in den Sitemap-Eigenschaften der Datei robots.txt verwiesen werden. Zusätzlich muss eine benutzerdefinierte Flush-Regel implementiert werden, um zu gewährleisten, dass diese Datei geleert wird, wann immer eine neue Seite aktiviert wird.

Hinweis

You can register a Sling Servlet to listen for the selector sitemap with the extension xml. Dadurch verarbeitet das Servlet die Anforderung jedes Mal, wenn eine URL angefordert wird, die wie folgt endet:
/<path-to>/page.sitemap.xml
Sie können die angeforderte Ressource von der Anfrage erhalten und eine Sitemap für diesen Punkt im Inhaltsbaum generieren, indem Sie die JCR-APIs verwenden.
Ein solcher Ansatz ist dann vorteilhaft, wenn mehrere Sites von derselben Instanz bedient werden. A request to /content/siteA.sitemap.xml would generate a sitemap for siteA while a request for /content/siteB.sitemap.xml would generate a sitemap for siteB without the need for writing additional code.

Erstellen von 301-Weiterleitungen für veraltete URLs

Beim Starten einer Site mit einer neuen Struktur ist die Implementierung und das Testen von 301-Umleitungen in Apache HTTP Server aus zwei Gründen wichtig:

  • Die veralteten URLs bauen über die Zeit hinweg SEO-Wert auf. Durch Implementierung einer Umleitung kann die Suchmaschine diesen Wert auf die neue URL anwenden.
  • Benutzer der Website könnten Lesezeichen für diese Seiten erstellt haben. Durch die Implementierung von Umleitungen kann sichergestellt werden, dass der Benutzer auf den Bereich der Site weitergeleitet wird, der seinem ursprünglichen Zielort am ehesten gerecht wird.

Werfen Sie einen Blick in den Abschnitt mit zusätzlichen Ressourcen für Anleitungen zur Implementierung von 301 Weiterleitungen, sowie einem Werkzeug zum Testen der Weiterleitung.

Zusätzliche Ressourcen

Weitere Informationen finden Sie in den zusätzlichen Ressourcen:

Auf dieser Seite