5 Fehler bei der SEO-Site-Migration, die Sie mit Sara Moccand vermeiden sollten

Veröffentlicht: 2022-06-27


Waren Sie schon einmal an einer katastrophalen Website-Migration beteiligt? Vielleicht wurden Sie in ein Projekt eingebracht, um sich mit den Auswirkungen einer schlecht durchdachten Website-Migration auseinanderzusetzen.

Heute werden wir fünf wichtige Fehler besprechen, die Sie vermeiden sollten, wenn Sie Ihre Website mit einer Dame migrieren, die letztes Jahr nachgegeben und Netflix und Disney Plus abonniert hat. Sie ist Co-Moderatorin des SEO Nerds Switzerland Meetups und SEO-Spezialistin bei Liip, einer Agentur für Web- und Mobilentwicklung mit sechs Niederlassungen in der Schweiz. Herzlich willkommen zum In Search SEO-Podcast, Sara Moccand.

Die zu vermeidenden Fehler sind:
  1. Schlechte Planung
  2. Weiterleitungen nicht testen
  3. Die Inszenierung nicht auditieren
  4. Migration in einer Zeit hoher Nachfrage
  5. Die Inszenierung indiziert haben





5 Tipps zur Site-Migration, die Sie im Auge behalten sollten


    Sarah: Hallo.

    D: Hey Sara. Du findest Sara auf liip.ch. Also, Sara, warum ist die Website-Migration ein so großes Problem für SEOs?

    S: Hauptsächlich, weil Sie den gesamten organischen Verkehr verlieren können, der die Einnahmequelle darstellt, würde ich sagen. Das ist der Hauptgrund, daher muss jeder bei der Migration seiner Website sehr vorsichtig sein.

    D: Heute sprechen wir also über die fünf Hauptfehler, die Sie bei der Migration Ihrer Website vermeiden sollten. Beginnend mit Nummer eins, schlechte Planung.



    1. Schlechte Planung



    S: Ja, einer der größten Fehler ist schlechte Planung. Ich habe ein paar Beispiele. Schlechte Planung kann von Anfang an beginnen. Zum Beispiel in einer Agentur, die die falsche Anzahl von Tagen verkauft, was bedeutet, dass Sie das Budget neu besprechen müssen, was es extrem kompliziert macht. Es gibt mehrere Beispiele, aber beginnen wir mit den Hauptproblemen. Offensichtlich werden die Dinge nicht so umgesetzt, wie Sie es möchten, wenn Sie nicht richtig planen. Das zweite Problem ist, wie ich bereits sagte, der Verkehrsverlust. Das ist das katastrophale Szenario, Verkehrsverlust, und die Lösung dafür besteht darin, die Namen aller Beteiligten zu erfahren. Das ist das Geheimnis. Erfahren Sie, wer der Entwickler ist, wer das Frontend, Backend, der Designer usw. ist. Erfahren Sie alles über ihre Namen und was sie tun, damit Sie sie jederzeit kontaktieren können.

    Jede Website-Migration ist wie ein neues Projekt. Sie haben also das Projekt, das dann einen Plan hat. Und dort können Sie genau sehen, wo SEO interagieren kann. Das ist wichtig zu beachten. Zum Beispiel wissen Entwickler zu Beginn, was zu tun ist, sie werden die Technologie auswählen, mit der sie arbeiten möchten. Daher ist es für einen SEO interessant zu wissen, welche Technologie er verwenden möchte. Und vielleicht können Sie auch Einfluss auf die eingesetzte Technik nehmen. Manchmal, nicht sehr oft, aber manchmal. Dies ist nur ein Beispiel dafür, wie Sie die Gesamtplanung lernen und herausfinden, wo Sie interagieren können.

    D: Es gibt natürlich viele Dinge, die Sie in einen Plan aufnehmen können, aber gibt es irgendwelche Standardelemente, die Sie in einen Plan einbauen würden? Oder ist jedes Projekt einzigartig?

    S: Ich würde sagen, es gibt drei Standarddinge. Wenn Sie wissen, wann die Technologie ausgewählt wird, wann der Designer mit dem Entwurf der Architektur der Website beginnt und wann sie live geht, können Sie die Staging-Umgebung analysieren, um sicherzustellen, wann sie live geht. Dies bringt mich zur Aufschlüsselung der Website-Migration. Sie haben Ihren Plan und dann teilen Sie ihn in Phasen auf. Die erste Phase ist die Vorbereitungsphase, in der Sie mit den Entwicklern interagieren. Und dort müssen Sie auch analysieren, wie es der Website geht, welche Seiten wichtig sind usw. Außerdem bereiten Sie Ihre Weiterleitungskarte vor. Die nächste Phase ist die Testphase, in der Sie alles testen, denn alles, was sich im Staging befindet, wird zu 100 % live gehen. Wenn es also dort ein Problem gibt, wird es danach ein Problem geben.

    D: Sie haben dort auch URLs erwähnt. Ich denke, einige Website-Migrationen sind einfacher als andere. Einige von Ihnen migrieren möglicherweise Server und behalten die gleiche Technologie, das gleiche CMS, möglicherweise auch die gleichen URLs ... Was passiert, wenn Sie jede einzelne URL oder die Mehrheit der URLs ändern, weil Sie müssen? Vielleicht wechseln Sie von etwas, das beispielsweise ASP am Ende von URLs hat, zu einer ziemlich einfachen URL? Ist es möglich, alle Ihre Rankings beizubehalten und gleichzeitig URLs zu ändern?

    S: Da ich in einer Entwicklungsfirma arbeite, kommen Leute, um das zu tun. Sie kommen nicht, um den Server nur ein wenig zu verändern. Was sie tun wollen, ist genau das. Sie wollen alles verändern. Das ist mein Problem. Also ja, es funktioniert. Sie müssen Ihre Weiterleitungen erstellen, Sie müssen Ihre Weiterleitungskarte erstellen und Sie haben Zeit, wo sich die Suchmaschinen ein wenig anpassen müssen. Meistens funktioniert es gut, denn wenn Sie Ihre Umleitungskarte erstellen, ist das Ziel, dies intelligent zu tun. Sie wissen zum Beispiel, dass Sie, wenn eine Seite für etwas Bestimmtes rankt, sie zum selben Thema weiterleiten. Dann musst du in deiner Redirect-Map ein bisschen aufpassen, und dann klappt es. Auch hier ist das Szenario, das ich in den meisten Fällen gesehen habe, genau das, wo sie alles geändert haben.

    D: Eine weitere Anschlussfrage zu dem, was Sie gesagt haben. Sie haben gesagt, dass Suchmaschinen manchmal etwas Zeit brauchen, um sich anzupassen. Wie viel Zeit sollten Sie den Suchmaschinen angemessen widmen, bevor Sie die gleichen Rankings wie zuvor sehen sollten?

    S: Nein, ich meinte, bevor Sie in Panik geraten. Ich würde sagen, es kommt darauf an, aber ich habe einige Fälle erlebt, in denen sie nicht alles ändern, aber sie ändern sich ziemlich und sie passen sich ziemlich schnell an. Ich würde sagen maximal einen Monat, anderthalb Monate. Und wenn es sich danach nicht anpasst, dann gibt es irgendwo ein Problem.

    D: Kommen wir zu Nummer zwei, nicht zum Testen von Weiterleitungen.



    2. Weiterleitungen nicht testen



    S: Ja. Lassen Sie uns ein paar Beispiele an der Wand der Schande machen, wo ich schlecht abgeschnitten habe. Ich erinnere mich, dass ich am Anfang meine Umleitungskarte organisiert hatte und jede einzelne Datei in Ordnung war. Dann habe ich es dem Entwickler gegeben, um alles vorzubereiten, was ich getestet habe. Und ich sagte, dass alles in Ordnung ist. Dann ging es live. Und als wir live gingen, fragte ich mich, was passiert. Und dann wurde mir klar, dass es eine Umleitungskette generierte, worüber ich etwas überrascht war. Ich hatte also das Glück, eine sehr gute Beziehung zu den Entwicklern zu haben, die das vor Ort beheben konnten. Das war ein Szenario, in dem ich getestet habe, aber ich habe nicht gut genug getestet, weil ich es nicht bemerkt habe, bevor ich live gegangen bin.

    Ein weiteres Mal an der Wand der Scham und um sich bewusst zu machen, wie wichtig es ist, alles perfekt zu testen. Ich erinnere mich, dass es eine Website mit vielen Ländern gab, aber es gab eine bestimmte Rolle für die URL. Also habe ich den Entwickler gebeten, mir zu helfen, ein Skript für mich zu erstellen, damit wir schneller vorankommen. Er hat das Drehbuch geschrieben und dann habe ich einen halben Tag mit dem Entwickler gebucht, um den Test durchzuführen, aber dann sagte er: „Hey, Sara, ich habe es getestet.“ Fantastisch. Wenn Sie es bereits getan haben, fantastisch. Aber lassen Sie mich ein Land ausprobieren. Also habe ich es in den USA getestet und gesagt: "Alles funktioniert. Groß. Vielen Dank. Wiedersehen. Gib mir fünf!" Dann sind wir live gegangen. Ich habe alles überprüft und als ich es überprüft habe, war ich: „Was ist los? Was ist Springen? Wo sind Japan und Kuwait?“ Wie ich sehe, haben wir alles migriert, aber wir haben Japan und Kuwait vermisst, was mir nicht klar war, bevor sie live gingen. Und wieder hatte ich Glück, denn sie halfen mir, es sofort wiederherzustellen, sodass es keine wirklichen Auswirkungen gab, weil es an dem Tag passierte, an dem wir alles korrigierten. Aber das ist ein Problem. Sie müssen testen.

    D: Ich denke, das bezieht sich auch auf Punkt drei, weil Punkt drei nicht die Prüfung der Inszenierung ist.



    3. Das Staging nicht auditieren



    S: Ja, das ist Teil von Punkt drei. Am Anfang hatte ich meine Tickets, ich habe sie kontrolliert, und in der Inszenierung war alles in Ordnung. Fantastisch. Die Tickets werden umgesetzt. Aber dann wurde mir klar, dass ich nicht so auditierte, wie ich normalerweise eine Website auditieren würde. Zum Beispiel fangen Sie an, seltsame Dinge zu sehen. Ich erinnere mich an diese Website, die kürzlich passiert ist und auf der Serverseite perfekt gerendert wurde. Ich konnte alles im Code in der Konsole sehen. Also war ich glücklich. Aber ich habe ein Problem mit versteckten Elementen, ich überprüfe immer versteckte Elemente. Was passierte, war, dass sich JavaScript sehr seltsam verhielt. Es entfernte alle Texte aus dem versteckten Element. So konnte man es sehen, aber nicht im Code. Das ist ein Beispiel dafür, wie wichtig es ist, die Inszenierung der Website zu auditieren und die gesamte Umsetzung zu überprüfen.

    Das andere, was Sie tun müssen, ist, Ihre eigene Checkliste zu haben, die Checkliste mit allen Aufgaben zu reparieren, genau wie bei einem Audit, und dann können Sie immer eine Spalte hinzufügen. Wenn Sie zum Beispiel ein Google Sheet verwenden, haben Sie eine Spalte, dass ich für diese Aufgabe ein Ticket habe, für diese Aufgaben ist es nicht erforderlich, ich könnte es nehmen. Zum Beispiel für den JavaScript-Fall, den ich gegeben habe, öffnen Sie kein Ticket, Sie öffnen es nur, wenn es ein Problem gibt. Und dann geben Sie Ihre Prioritätenliste in einer anderen Spalte an, dem Status. Welche Status-URL ist in Bearbeitung, und dann kommentieren Sie. Kommentare sind super wichtig, jeder nimmt sie weg, aber Kommentare sind wichtig, weil Sie wissen müssen, warum etwas blockiert wird. Wenn beispielsweise eine Person blockiert oder ein anderes Ticket blockiert, müssen Sie wissen, dass Sie es blockieren müssen. Das ist ein bisschen über die Prüfung der Inszenierung und ihrer Bedeutung. Es hängt davon ab, aber einige Entwickler verwenden zum Beispiel auch den noindex auf allen Seiten im Code. Und dann werden sie vergessen, es zu entfernen, wenn sie live gehen. Das Problem ist, dass Sie sich bewusst sein müssen, dass sie es verwenden, damit Sie sie bitten können, daran zu denken, den noindex zu entfernen, bevor sie live gehen, bitte.

    D: Und Punkt Nummer vier, den es zu vermeiden gilt, ist die Migration in einer Zeit hoher Nachfrage.



    4. Migration in Zeiten hoher Nachfrage



    S: Ja. Dies sollte offensichtlich sein, da Sie dieses Problem haben, den Datenverkehr zu verlieren, oder zumindest für kurze Zeit, es ist nicht immer so. Auch hier hängt es von der Website-Migration ab, aber es besteht das Risiko der Anpassungszeit. Und wenn Sie dann noch Zeit für andere Aktivitäten haben … Nehmen wir an, Sie sind im eCommerce tätig. Zwischen voraussichtlich Oktober und Ende Dezember möchten Sie Ihre Website nicht migrieren, da Weihnachten vor der Tür steht und viele Leute über Ihren E-Commerce-Shop einkaufen werden. Der Kunde weiß normalerweise, dass er in diesem Zeitraum eine hohe Nachfrage hat. So können Sie mit dem Kunden seine Analysen überprüfen, um ein Problem zu vermeiden.

    D: Sie haben vorhin erwähnt, dass einige Entwickler sogar noindex auf jede Seite setzen, um tatsächlich zu versuchen und zu vermeiden, dass Seiten indexiert werden. Fehler Nummer fünf besteht darin, dass die Inszenierung indiziert wird. Würden Sie das noindex-Tag auf jeder Seite in der Staging-Umgebung empfehlen, um so etwas zu vermeiden?



    5. Das Staging indizieren lassen



    S: Nein, Passwortschutz ist immer die Lösung. Sie können noindex machen, aber wie in meinem Beispiel könnten Sie es vergessen, wenn Sie live gehen. Am Ende ist die beste Lösung, die immer funktioniert, ein Passwortschutz, Punkt. Ich erinnere mich, dass die Inszenierung vor einigen Jahren einmal indiziert wurde, und das war wahrscheinlich die schockierendste Erfahrung, die ich hatte. Staging wurde indiziert und das Problem war… man konnte Tickets auf der Website kaufen und das Problem war, dass die Leute, die versuchten, die Tickets auf der Staging-Website zu kaufen, ein bisschen katastrophal waren. Können Sie sich vorstellen, dass Leute versuchen, auf der Staging-Website einzukaufen? Also haben sie mich kontaktiert und gesagt, dass sie dieses Problem haben. Und wir konnten es lösen, da es relativ einfach zu lösen ist. Das ist wahrscheinlich einer der wichtigsten Punkte für mich. Einmal haben die Entwickler den Passwortschutz und den noindex. Ich muss also darauf achten, nicht nur zu überprüfen, ob es passwortgeschützt ist, sondern auch den noindex zu überprüfen.

    D: Ich bin sicher, Sie hätten dieses Gespräch auf 101 Fehler erweitern können, die Sie bei der Migration unserer Website vermeiden sollten, aber hoffentlich haben wir Ihre Top 5 dort. Wie immer tolle Sachen von Sara dabei. Lassen Sie uns mit der Pareto Pickle abschließen. Pareto sagt, dass Sie 80 % Ihrer Ergebnisse mit 20 % Ihrer Bemühungen erzielen können. Welche SEO-Aktivität würden Sie empfehlen, die mit geringem Aufwand unglaubliche Ergebnisse liefert?





    Die Pareto-Pickle - Website-Migrationsplanung



    S: Für mich ist es bei einer Website-Migration die Planung. Nehmen Sie sich ein wenig Zeit bei der Planung. Es ist kein enormer Zeitaufwand im Vergleich zu der Arbeit, die Sie erledigen müssen. Wenn Sie Struktur haben, dann machen Sie keine Fehler, und dann sparen Sie sich viel Zeit, weil Sie für jeden Fehler Zeit brauchen, um sich von den Fehlern zu erholen, also planen Sie auf jeden Fall.

    D: Richtig planen. Ich war Ihr Gastgeber, David Bain. Du findest Sara auf liip.ch. Sara, vielen Dank, dass Sie beim SEO-Podcast „The In Search“ dabei sind.

    S: Danke.

    D: Und danke fürs Zuhören.