Webentwicklung für SEO: Eine andere geht fast schief

Zuletzt aktualisiert am 14. September 2018

Aus diesem Grund haben Sie ein solches SEO-Unternehmen! Unternehmen, um zu erkennen und zu korrigieren, was bei der Neugestaltung einer bestehenden Website schief geht. Wie jeder, der in der Internet-Marketing-Branche arbeitet und eine funktionierende Website neu erstellt hat, weiß, können unzählige Dinge schief gehen. Kürzlich beendete ein PPC- (Pay-per-Click) und SEO- (Suchmaschinenoptimierungs-)Kunde gerade die Neugestaltung seiner Website und startete, ohne eine Überprüfung zuzulassen. Dieser letzte Neuaufbau der Website dieses Kunden ging beim Start schrecklich schief, daher werde ich einige der erwarteten und unerwarteten Dinge ansprechen, die schief gehen können und können.

Das Bedürfnis

Dieser Kunde erwarb ein bestehendes Unternehmen, das über eine bestehende E-Commerce- und Informationswebsite verfügte und in seiner Branche führend war. Der Webentwickler kam nicht mit dem Kauf. Aus irgendeinem Grund, der mir nie bekannt wurde, konnte der Client keine Seiten außerhalb des Warenkorbs aktualisieren. Der Warenkorb war nicht mobilfreundlich und wir konnten den Unterschied in ihren Conversions von Desktop zu Mobile sehen. Mobile Conversions waren praktisch nicht vorhanden. Die überwältigende Mehrheit ihrer Online-Verkäufe wurde durch organische Desktop-Suche, PPC, direkte und Empfehlungsbesuche generiert.

Viele der Elemente, die zur Verbesserung ihrer SEO benötigt werden, waren auch einfach nicht vorhanden. Keine Möglichkeit, Metadaten, h1-Tags, alt/title-Tags usw. zu ändern. Die meisten dieser Daten wurden programmgesteuert generiert; sowie die Menüs und Navigationsstruktur. Diese neue Website müsste auch sicher sein. Kurz gesagt, was sie brauchten, war eine neue, für Mobilgeräte optimierte, sichere Website und ein Einkaufswagen mit einem Konnektor, der mit ihrer bestehenden ERP-Softwaresuite (Enterprise Resource Planning) funktioniert.

Die Mission

Dieser Kunde hatte 3.766 Keywords mit Ranking-Ergebnissen in den Top 100 Google SERPs. Fünfhundertachtunddreißig (538) Keywords mit Ergebnissen auf Seite 1 mit einem durchschnittlichen monatlichen Suchvolumen von 65.790 und 43 Keywords auf Position eins in den Google SERPs mit einem durchschnittlichen monatlichen Suchvolumen von 6.110. Meine Aufgabe bestand darin, sie durch die Anforderungen zu führen, die ein neues Verwaltungssystem erfüllen musste, um SEO in Zukunft implementieren zu können. Dazu gehörte auch, ihre bestehenden Ranking-Ergebnisse so gut wie möglich zu schützen.

Die Auswahl

Der Kunde entschied sich schließlich für einen Offshore-Anbieter, der die Integration zwischen seiner bestehenden ERP-Software und einer neuen, mobilfreundlichen, sicheren Warenkorblösung und Website bereitstellen konnte. Da ich mit diesem Offshore-Anbieter nicht vertraut war, stellte mir der Kunde eine aufgezeichnete Produktdemo zur Verfügung, um zu bestätigen, dass das Verwaltungssystem das bieten würde, was wir für die Implementierung von SEO benötigen. Nach Durchsicht der Demo kam ich zu dem Schluss, dass wir über die notwendigen Elemente verfügten, um den Kunden bei SEO-Verbesserungen zu unterstützen. Wir könnten unsere eigenen Seitentitel, Meta-Beschreibungen und h1-Tags erstellen. Wir konnten den Code von Google Analytics (GA) aktualisieren, von dem sie alten, veralteten GA-Code und kein Search Console-Konto ausführten. Wir hatten Zugriff auf die Bilder, um richtig formatierten Alternativ-/Titeltext hinzuzufügen. Wie wir später und viel zu spät herausfanden, gab es sogar die Möglichkeit, die 301-Weiterleitung direkt auf jeder Seite anzuwenden. Aber das ist nur ein Teil der Geschichte.

Das Ergebnis

Wie sich herausstellte, stellte der Entwickler eine Vorlage, einen Warenkorb und eine ERP-Integration bereit. Der Kunde wurde beauftragt, die Inhalte zu verschieben (alte Seiteninhalte kopieren und in eine neue Seite im Verwaltungssystem einfügen), einschließlich der vorhandenen Metadaten. Sie wurden auch beauftragt, die URLs der alten Website Seite für Seite in die Daten der neuen Seite einzugeben. Es stellte sich heraus, dass dies durch die Tatsache erschwert wurde, dass der Client die URLs der alten Website nicht intakt kopieren und einfügen konnte. Der Kunde nahm dies als Standardverfahren und teilte dies niemandem mit. Wir hatten ursprünglich empfohlen, dass der Entwickler eine richtige 301-Umleitungsdatei erstellt. Der Rollout-Zeitplan erlaubte es dem Kunden nicht, uns den ordnungsgemäßen Betrieb überprüfen zu lassen. Sie haben es einfach gestartet und da ist alles schief gelaufen.

Als wir bemerkten, dass die neu erstellte Website gestartet wurde, begannen wir, die ursprünglichen Keyword-Ranking-Ergebnisse manuell mit den aktuellen Ranking-Ergebnissen zu vergleichen. Nur um zu sehen, wie die neue Seite aussah und ob alle Daten übertragen wurden. Alle noch vorhandenen Ranking-Ergebnisse in den Google-SERPs ergaben einen 404-Response-Code mit Ausnahme der Startseite. Wie sich herausstellte, wurden die URLs der alten Website mit .html-Erweiterungen erstellt und die neuen URLs nicht. Das Verwaltungssystem ließ einfach nicht zu, dass die alte URL in das bereitgestellte 301-Umleitungsfeld eingefügt wurde, also fügte der Client die alte URL ohne die Erweiterung .html ein. Der Kunde war davon ausgegangen, dass dies ein Standardarbeitsablauf sei.

Nach vielen internen Diskussionen haben wir festgestellt, dass die Seiten in den meisten Fällen korrekt auf die sichere Version der neuen URL umgeleitet werden, wenn Sie die Erweiterung .html entfernen. In einigen Fällen leitete die alte URL ohne die Erweiterung .html jedoch zu einer neuen, sehr nicht suchmaschinenfreundlichen URL weiter, die eine Abfragezeichenfolge enthielt, die wir noch nie zuvor gesehen hatten. Bei weiteren Untersuchungen stellten wir fest, dass diese neue, unbekannte URL von der Navigation im Hauptmenü generiert wurde. Wir hatten also in den meisten Fällen eine Eins-zu-Eins-Umleitung von der alten URL, ohne die Erweiterung .html, auf die neue sichere, suchmaschinenfreundliche URL, und wir konnten von der Hauptnavigation zu demselben Inhalt navigieren, der die neue Non generierte -freundliche URL.

Doppelte Inhalte? Nun, wurde das kanonische rel=-Tag platziert, fragen Sie sich vielleicht? Korrekt? Nein. Das Tag rel=canonical auf der suchmaschinenfreundlichen, umgeleiteten URL wurde so eingestellt, dass es auf die neue nicht suchmaschinenfreundliche URL verweist, die die Abfragezeichenfolge enthält. Bei der Untersuchung des rel=canonical-Tags der unfreundlichen Seite stellten wir fest, dass dieses Tag auf eine völlig andere URL verwies. Einer, der die Kategorie und nicht die Abfragezeichenfolge enthält. Ein Inhalt wurde also für drei verschiedene URLs mit falsch gesetzten rel=canonical-Tags angezeigt.

Als nächstes stellten wir fest, dass alle Bots in der robots.txt-Datei nicht zugelassen waren. Dann haben wir die Aktivität in GA überprüft. Der Kunde erhielt weiterhin Besuche aus allen Quellen, verzeichnete jedoch keine Conversions. Darüber hinaus wollte der Kunde, dass wir das Crawling und die Indexierung vorantreiben, was die Search Console von Google erfordert. Das Problem dabei ist, dass der vorhandene GA-Code alt war und nie ein Search Console-Verifizierungscode auf der Website platziert wurde. Dies ist einer der Punkte, die der Kunde aus nie bekannt gegebenen Gründen nicht ändern konnte.

Glücklicherweise war der Kunde unserer Empfehlung gefolgt, seinen GA-Code auf die neueste Version zu aktualisieren. Eigenständig fügten sie auch den Tag-Manager von Google hinzu. Hoppla! Möglicherweise doppeltes Auslösen des GA-Codes? Mit Google Tag Manager und dem aktualisierten asynchronen GA-Code konnten wir ein neues, sicheres (https vs. http) Search Console-Konto für den Kunden erstellen und stellten dann fest, dass es keine XML-Sitemap gab, die für einen angeforderten Crawl eingereicht werden konnte .

Nach der Benachrichtigung kommunizierte der Kunde mit dem Entwickler und erhielt zwei .xml-Sitemap-URLs. Einer hat funktioniert. Einer nicht. Die funktionierende hatte einen Eintrag, der auf die nicht funktionierende .xml-Sitemap verwies. Die nicht funktionierende .xml-Sitemap hatte bei der Anzeige in einem Browser nicht die richtige Formatierung. Daher haben wir die bereitgestellte .xml-Sitemap zu diesem Zeitpunkt nicht eingereicht.

Das Endergebnis

Wir informierten den Kunden durch inszenierte E-Mails über unsere Feststellungen. Erstens das Problem der fehlgeschlagenen Weiterleitungen und dass wir festgestellt haben, dass sie ordnungsgemäß weitergeleitet wurden, wenn wir die Erweiterung .html entfernten. Der Client hat den Entwickler benachrichtigt und der Entwickler hat geantwortet, dass Sie die Erweiterung .html nicht in das bereitgestellte 301-Umleitungstool einfügen konnten. Weitere Entdeckungen ergaben, dass der Kunde dies entdeckt hatte und dachte, dass dies ein Standardverfahren sei.

Aus irgendeinem Grund wurde die ursprüngliche Website gelöscht (großes Upsy hier, halten Sie immer eine funktionierende Version bereit, auf die Sie zurückgreifen können), sodass wir keine der alten URLs ziehen konnten, um eine neue permanente 301-Weiterleitung über die .htaccess-Datei zu erstellen. Die Lösung bestand darin, eine neue Eins-zu-eins-Übereinstimmung zu erstellen, alte URL vs. neue URL, Tabellenkalkulation, Landingpage-Daten aus GA für das vergangene Jahr abzurufen, damit der Entwickler eine ordnungsgemäß funktionierende Umleitung erstellen kann, die die 301-Umleitung in der überschreibt Verwaltungssystem, das auf dem Client beauftragt wurde.

Problem gelöst gegen zusätzliche Kosten für den Kunden vom Entwickler. Alle bestehenden alten Ranking-Ergebnisse mit einer .html-Erweiterung begannen ordnungsgemäß umzuleiten und innerhalb von 14 Tagen wurden die Ranking-Ergebnisse durch die neuen sicheren URLs ersetzt und zum größten Teil sehr nah am bereits bestehenden Ranking-Ergebnis. Das Problem mit dem rel=canonical-Tag wurde in einem Online-Meeting mit dem Vertriebsmitarbeiter des Webentwicklers gelöst und war auf einen Eingabefehler des Benutzers zurückzuführen. Es gab mehrere Felder, in die Daten eingegeben oder aus einer vorhandenen Auswahl ausgewählt werden konnten, und die Lösung erforderte das Zurücksetzen dieser Felder und das Löschen des Caches.

Die zwei zusätzlichen Versionen der freundlichen, sicheren URL verschwanden umgehend. In Bezug auf den Bot /disallow in der robots.txt hat der Entwickler dieses Problem nach Benachrichtigung schnell behoben.

Es wurde festgestellt, dass das Problem mit den GA-Konvertierungsdaten auf den Händlerdienstanbieter des Kunden beschränkt zu sein scheint. das war neu und anders als der alte Anbieter. Niemand dachte daran, dem Händlerdienstanbieter mitzuteilen, dass wir den GA-Code auf seiner Checkout-Seite benötigen, um die notwendigen E-Commerce-Daten bereitzustellen, die der Kunde benötigt, um fundierte Geschäftsentscheidungen über seine Marketingbemühungen zu treffen. Wir wurden nicht auf die Existenz eines neuen Anbieters von Handelsdienstleistungen aufmerksam gemacht.

Schließlich hatten wir manuell eine .xml-Sitemap-Datei erstellt, die wir auf den Server hochladen wollten, und den Entwickler aufgefordert, alles zu deaktivieren, was ihre nicht funktionierende .xml-Sitemap erstellte. In weiteren Gesprächen mit dem Vertriebsmitarbeiter des Entwicklers wurde uns mitgeteilt, dass wir keine weitere .xml-Sitemap auf den Server hochladen könnten.

Nachdem er dem Handelsvertreter des Entwicklers die Ergebnisse gezeigt hatte, erklärte er, dass er sich das ansehen würde, schlug jedoch vor, dass wir uns den Quellcode ansehen. Beim Anzeigen im Quellcode war das .xml-Dokument richtig formatiert. Als wir dieses Ergebnis sahen, teilten wir Google über die Search Console mit, dass wir tatsächlich eine funktionierende .xml-Sitemap haben. Schließlich hat Google im Laufe mehrerer Tage endlich aufgezeichnet, dass wir eine funktionierende .xml-Sitemap hatten, und begonnen, indexierte URLs anzuzeigen. Wie bereits erwähnt, hatte die korrekt formatierte .xml-Sitemap jedoch nur einen Eintrag, der auf die zusätzliche .xml-Sitemap verwies, die in einem Browser nicht aufgelöst, aber im Quellcode richtig angezeigt wurde.

Nun, dieses Problem hat sich zu einem größeren Problem entwickelt, da die zusätzliche .xml-Sitemap einen 500-Antwortcode generiert hat, also gibt es ein Problem mit dem Google-Agenten, der auf diesen Bereich der Website zugreift. Und ab heute generieren beide .xml-Sitemaps 500 Antwortcodes. In der Woche zuvor hatten wir mit dem uns in der Google Search Console zur Verfügung stehenden Tool zum Abrufen, Rendern und Senden ein Crawling veranlasst, von dem wir glauben, dass es das Crawling und die Indexierung der neuen Website verursacht hat.

Also, zum Schluss, wenn es schief gehen kann, wird es beim Neuaufbau Ihrer Website und hoffentlich werden Sie in der Lage sein, einige dieser Fehler zu vermeiden. Das Blockieren der Bots in der robots.txt-Datei und das unsachgemäße Umleiten kann Sie online aus dem Geschäft bringen oder zumindest gefährden. Wenn die Bots Ihre Website nicht crawlen können, werden Sie letztendlich aus dem Index fallen, und wenn Sie aus dem Index fallen, werden die meisten organischen Suchbesuche nicht mehr existieren, es sei denn, sie stammen aus Verweisen, direkten oder anderen nicht-organischen Quellen.

Wenn die Ergebnisse nicht richtig weitergeleitet werden, können organische Besucher Ihre Website als nicht vertrauenswürdig ansehen. Bestehende Kunden, die Ihre Website als Lesezeichen gespeichert haben, können frustriert sein, wenn ihr Lesezeichen nicht korrekt weiterleitet. Ganz zu schweigen davon, dass wir ihre PPC-Kampagne in der Zwischenzeit einstellen mussten. Auf eine bezahlte Anzeige zu klicken und eine 404-Seite nicht gefunden-Antwort zu erhalten, ist nicht nur frustrierend für Ihre Besucher, es ist auch teuer! Der Klick kostet Sie Geld und Sie erhalten keine Rendite auf Ihre Investition. Und dafür haben Sie uns.

– Mark Gray, leitender SEO-Manager