OnPage.org Teil 2: Meta-Daten optimieren

Meta-Angaben der Webseite mit OnPage.org optimieren und analysieren.

Letzte Woche begann ich die OnPage.org Testreihe mit der Einrichtung der eigenen Webseite in die Software, die Konfiguration der Mitbewerber und Keywords. Heute möchte ich auf die ersten sehr wichtigen Funktionen eingehen. Die Meta-Daten. Vorab möchte ich aber noch ein paar andere Informationen teilen.

Zwei mögliche Analyse-Wege

Nachdem der Crawlvorgang abgeschlossen ist, stehen auf dem Dashboard die ersten Informationen zum Status der Webseite zur Verfügung. Dort gibt es auch visuell eine Übersicht über die vorhandenen Fehler, sortiert in Schwierigkeitsgrade (Level). Durchs Ergebnis arbeiten, kann man sich sowohl auf Basis der Level, als auch auf Basis der Hauptnavigation die in Bereiche gegliedert ist.

Ich entscheide mich für den Testbericht für den Weg durch die Navigation. Dadurch kann ich den Bericht übersichtlich in mehrere Teile aufteilen.

Meta-Daten mit OnPage.org optimieren

In diesem Teil des Tests geht es um die nachfolgenden Schwerpunkte, die mit OnPage.org analysiert werden können.

  1. Seitentitel
  2. Seitenbeschreibung
  3. Canonical
  4. Robots-Attribut
  5. Mime-Type
  6. Sprache
  7. Autorenverknüpfung

Dashboard

Im ersten Schritt möchte ich aber kurz das Dashboard vorstellen. Wie ich schon schrieb, ist es die erste Seite die man nach abgeschlossenem Crawlvorgang bekommt.

onpage-dashboard

Auf dem Dashboard stehen u.a. die Statistiken zum letzten Crawl. Die Anzahl der gefundenen URLs (113,544) und auch die Anzahl der gecrawlten URLs. Diese sind 50.000 Stück, wie ich es bei den Grundeinstellungen im ersten Teil festlegte. Die Webseite verfügt über deutlich mehr URLs und ich konnte nicht alle in meinem PRO-Account analysieren.

Ist das schlimm? Nein! Die meisten Webseiten – so auch Apfelpage.de – basieren auf einem CMS mit einer begrenzten Anzahl an Templates. Seitentypen die es bei Apfelpage.de beispielsweise gibt sind:

  1. Startseite
  2. Kategorie-Seite
  3. Tag-Seite
  4. Tag-Landingpage
  5. Beitragsseite
  6. Datumsarchive
  7. Blätterseiten

Viele OnPage-Fehler sind bei Webseiten basierend auf Template-Konfigurationen. Zu lange Seitentitel zum Beispiel kommen zustande, wenn eine zu lange Domain oder Marke als Standard im Seitentitel mit ausgegeben wird. Da kommt man schnell an die Pixel-Grenzen von Google. Sicher sehen wir dieses Problem gleich im Testbericht. Behandelt man so ein Problem, löst man ggf. tausende Fehler mit wenigen Klicks. Deshalb ist es nicht schlimm wenn nicht alle URLs einer Domain gecrawlt werden.

Rechtsseitig neben den Crawl-Statistiken befinden sich die Einstufungen in Schwierigkeitsgrade. Von sehr leicht zu ändernden Problemen, bis hin zu Aufgaben die eher Expertenwissen benötigen. Wie ich schon schrieb, könnte ich auch über diesen Weg in die Analyse einsteigen. Klappt man so einen Bereich auf, sieht das wie folgt aus.

einfache optimierungsfaktoren

Erklären muss ich wohl zu dieser Ansicht nichts. Die Spalte mit der Tendenz bezieht sich auf die Veränderung zum letzten Crawlvorgang. Ich habe die Webseite bereits zwei Mal gecrawlt, da die Performance der Seite beim ersten Versuch gerade litt, da in diesem Moment diverse Apple-Meldungen die Seite in Mitleidenschaft zogen. Die Auswirkungen werden wir auch noch sehen.

Was ich gut finde, ist die Anzeige der „Abteilung“ die einen Fehler beheben kann. Ihr seht deshalb auf dem Bild oben „Redaktion / Management“ und auch „Technik / IT“. Natürlich passt das so nicht in jede Firma. Es ist nur eine Zuordnung basierend auf typischen Strukturen.

Abschließend befinden sich auf dem Dashboard noch die Daten für Social-Networks und ein paar Informationen zu den Linkdaten (extern), basierend auf der Datenbasis von seokicks.de und moz.com. Hier möchte ich auch kurz Kritik anbringen. Eine Domainpopularität von 504 weicht mir persönlich etwas zu stark von der Realität ab. OnPage.org ist zwar kein Tool für eine Backlink-Analyse, aber wenn MajesticSEO bereits über 1.200 verweisende Domains findet und ahrefs.com über 1.400 Domains, dann sind die 504 Domains aus der SEOkicks-Datenbank nicht befriedigend. Länger möchte ich darauf aber nicht rumreiten, es geht jetzt schließlich um OnPage SEO!

Seitentitel optimieren

Steigen wir ein in die Optimierung der Webseite „apfelpage.de“ und beginnen ganz oben – im Header-Segment.

Die Analyse der Seitentitel kann auf drei Ebenen durchgeführt werden. Begonnen wird damit, herauszufinden welche Seitentitel zu lang oder zu kurz sind. Standard basiert diese Auswertung auf Grundlage der Pixel. Aber auch eine Analyse anhand der Zeichen kann gemacht werden, ist aber für Google nicht mehr zeitgemäß, da die Suchmaschine die Länge von Seitentiteln in Pixel berechnet. Und die dritte Ebene ist die Analyse auf Mehrfachverwendung, also doppelte Seitentitel auf der Webseite.

Seitentitel optimieren

Ganz oben rechts kann der derzeitige Optimierungsgrad aller Seitentitel gesehen werden. 49% ist kein Highlight. Die Seite leidet vor allem auch unter der großen Menge an zu langen und zu kurzen Seitentiteln.

Über 14.000 Seitentitel sind zu lang. Sehen wir uns das mal im Detail an.

Bevor ich anfange eine ewig lange Tabelle zu durchforsten, probiere ich bei Tools generell aus, ob ich Werte anklicken kann. Bei OnPage.org funktioniert es. Ich kann im Diagramm die Säule anklicken die ich analysieren will. Ich habe auf die „14k“ geklickt und es wurde sofort ein Filter aktiviert.

filter-durch-klick

In der Tabelle habe ich nun nur noch Ergebnisse die zu optimieren sind. Sprich, alle Dokumente die zu lange Seitentitel haben, aber sich noch im Rahmen bewegen. Denn würde ich die wirklich viel zu langen Titel sehen wollen, hätte ich im Diagramm eine Säule weiter rechts aktivieren können. Ich könnte aber auch beide Filter kombinieren. Sehen wir uns die Ergebnisse mal an.

lange-seitentitel

Wie man sieht, ist einfach der Seitentitel normaler Beiträge immer deutlich zu lang. Einsparen kann man hier durchs Brand und auch durch geschicktere Seitentitel. Das Title-Attribut muss nicht zwangsläufig auch der Überschrift eines Beitrags im Frontend der Webseite gleichen. Denn wer zu lange Seitentitel nutzt, bekommt in Google nur drei Punkte und eine abgeschnittene Headline.

Google Snippet

Statt „Neuerscheinungen“ hätte hier auch „Neuerscheinung“ oder einfach „Release“ ausgereicht. Spart viele Pixel und lässt Raum, um die Headline mit einem Punkt abzuschließen – sofern gewünscht. Der komplette Title-Tag ist aber ja eigentlich noch länger. Es fehlt das Brand und es fehlt der zweite Teil der Headline.

  • „Release: SwiftKey Note ab sofort verfügbar.“ = für Google toll.
  • „Neuerscheinungen: SwiftKey Note ab sofort verfügbar, Facebooks Paper erst später“ = die Headline auf der Webseite.
  • „Neuerscheinen: SwiftKey Note ab sofort verfügbar, Facebooks Paper erst später – Apfelpage“ = ist der Seitentitel im Header.

Wird der Seitentitel nach Anzahl der Zeichen analysiert, ist die Mehrheit der Seiten übrigens in Ordnung innerhalb des Limits.

Was mir gut gefällt, ist die Anzeige diverser anderer Werte direkt in der Tabelle unter jedem Snippet. So sehe ich gleich ob eine Seite überhaupt indexiert werden kann. Ob ein Canonical-Tag aktiv ist und wenn ja, ob er auf sich selbst führt oder auf ein anderes Dokument. Und ich sehe den Status-Code der URL.

statusleiste-snippet

Würde ich einen dieser Werte anklicken, täte sich ein Filter auf diesen Wert aktivieren und ich würde beispielsweise alle zu langen Seitentitel sehen, deren Seiten indexiert werden können aber nicht in der Sitemap.xml stehen und einen Canonical auf ein anderes Dokument setzen. Filter sind flexibel – sehr flexibel.

[box type=“infobox“] Für eine bessere CTR in Google würde ich empfehlen, Title-Attribut und Artikel-Headline voneinander zu trennen. Und dabei auch gleich die URL zu überdenken. Für die Technik würde ich eine kurze und knackige Headline empfehlen. Für die Besucher der Webseite dann eine dazu passende, selbstredende Überschrift.

[/box]

Doppelte Seitentitel

Die dritte Ebene die ich ansprach, sind doppelte Seitentitel gewesen. Diese sehe ich mir jetzt genau an. Es kommt wieder ein Diagramm mit Säulen. Auffällig, wie viele Seitentitel es mehr als 9x doppelt gibt. Wenn ich darunter dann die Tabelle ansehe, erkenne ich auch schon ein Ausmaß was mir nicht gefällt.

doppelte-seitentitel

In dieser Tabelle brauche ich nichts recherchieren. Der nächste Klick geht direkt auf die Lupe in der letzten Spalte. Dort komme ich zu den Duplikaten des Seitentitels. Und was sehe ich? Ein Problem was ganz typisch für WordPress ist.

replytocom

WordPress gibt bei den URLs, die zum Antworten auf Kommentare dienen, „replytocom“ mit. Kann man auch ganz einfach nachvollziehen wenn man bei eisy.eu auf einen bestehenden Kommentar antworten möchte. Was bei apfelpage.de aber auch der Fall ist, ist eine Indexierung all dieser URLs.

replytocom-index

In der robots.txt werden die URLs ausgesperrt, aber im Header der Webseite wird ein „index, follow“ für die URLs ausgegeben und ein Canonical-Tag gesetzt, der auf die ursprüngliche URL des Artikels verweist. Dadurch nimmt Google die Seiten in den Index auf, holt sich aber keine Description und lässt die URLs nicht ranken. Zum Glück nicht.

Da es vielleicht noch mehr doppelte Seitentitel gibt, aber die Problematik mit „replytocom“ wirklich die Übersicht in der Tabelle vernichtet, ist jetzt ein Filter sinnvoll. Ich setze einen „URL beinhaltet nicht“-Filter und schreibe „replytocom“ rein. Kriege jetzt nur noch Ergebnisse mit doppelten Seitentiteln aber ohne diese bereits gefundene Problemzone.

no-replytocom

Und das lohnt sich, denn ich erhalte weitere Treffer. Davon klicke ich einen an, der 12 Duplikate hat. Und was sehe ich, es sind tatsächlich 12 verschiedene Artikel im Blog, die alle die gleiche Überschrift verwenden.

rabattwochen-seitentitel

Es gehen jede Woche Artikel mit Rabatt-Angeboten raus. Dabei wird die URL immer durch die neue Kalenderwoche ergänzt, aber die Headline der Artikel und der Seitentitel, nicht. Um das Problem zu lösen, einfach die Kalenderwoche mit in den Seitentitel packen. Kann ja beispielsweise durch „KW 12“ ergänzt werden.

Eine weitere Problematik sind Seiten, die über mehrere Seiten führen. Also Kategorien und Tags, bei denen geblättert wird um weitere Artikel zu sehen. Die können derzeit noch in den Index und haben alle den gleichen Titel. Hier sollte über „noindex, follow“ nachgedacht werden. Und im Seitentitel einfach automatisch immer die Nummer der Seite eintragen. Schon sind alle Titel einzigartig, wenn auch geringfügig.

[box] Was mich an OnPage.org gerade im Workflow behindert:

Wenn ich einen Filter setze und Ergebnisse bekomme. Klicke ich anschließend auf die Lupe in der Tabelle um alle Ergebnisse zum doppelten Seitentitel zu betrachten. Nun habe ich das Problem aber erkannt und will zurück zur Übersicht, um beim nächsten Resultat auf die Lupe zu klicken. Mein Filter ist jedoch weg. Ich muss ihn entweder neu eingeben, oder ich müsste mir Filter speichern. Für spätere Analysen finde ich gespeicherte Filter ja super. Aber inmitten eines Workflows sollte der Filter zumindest für 1x Zurück-Taste gespeichert bleiben. Oder ein Popup erscheinen mit „Möchtest Du den letzten Filter beibehalten?“. Die meisten klicken wahrscheinlich auf „Ja“, weil es nur logisch ist. 😉

[/box]

Meta-Description optimieren

Verlassen wir den Seitentitel und begeben uns zum nächsten Punkt. In der Navigation geht es mit der „Beschreibung“ (Meta-Description) weiter.

lange-description

Sieht ja vielversprechend aus, was da an zu langen Beschreibungen auf mich wartet. Ich habe mir das nur kurz angesehen und wusste, es muss ein Bug sein der nicht an der Website liegt. Daher kurz mit dem OnPage.org Team geschrieben und der Bug wurde behoben. Ein neuer Crawl zeigt nun das echte Ergebnis der Meta-Descriptions.

metadescription-status

4 Beschreibungen sind zu lang und 689 Beschreibungen zu kurz. Über 35.000 Beschreibungen sind korrekt. Sehen wir uns deshalb die zu langen und die kurzen Werte an. Es braucht wieder nur einen Klick auf die gewünschte Säule im Diagramm.

beschreibung-lang

Ein Blick auf die 689 zu kurzen Beschreibungen offenbart einen Klassiker beim Einsatz von WordPress.

beschreibung-kurz

Na, wer erkennt das Problem?

Richtig, die Webseite verwendet das Plugin „wpSEO“ und Sergej (Entwickler des Plugins) liefert es nach der Installation so aus, dass in der Description nur vollständige Sätze, jedoch maximal 140 Zeichen angezeigt werden. Die maximal 140 Zeichen sind in Ordnung. Die nur vollständigen Sätze jedoch eher unpraktisch. So beendet das Plugin die Beschreibung nach dem ersten vollständigen Satz, auch wenn das nur ein Wort + Satzzeichen ist.

beschreibung-satzbau

Hier muss nur in wpSEO in der Konfiguration die Funktion deaktiviert werden, in der nur vollständige Sätze verwendet werden.

Doppelte Beschreibungen sind auch ein Problem von Apfelpage.de. Hier werden zum Beispiel in den AppSalat Beiträgen jedes mal die gleichen Descriptions verwendet. Ich würde empfehlen, auch hier entweder die Kalenderwoche gleich an den Anfang des Beitrags zu schreiben oder noch besser, ein „Von – Bis“-Datum und die Kalenderwoche. So wird die Beschreibung jedes Mal unique.

Canonical Tag optimieren

Kommen wir zum dritten Schritt mit OnPage.org im Bereich der Meta-Daten. Der Canonical-Tag sorgt bei vielen Seitenbetreibern für Stirnrunzeln. Nicht ohne Grund, denn die einen wissen nicht wie man den Tag einsetzt, die anderen glauben es zu wissen aber nutzen ihn falsch. Und wieder andere machen einfach alles richtig. Oder arbeiten ohne Canonical Tag. Immer öfters verbreitet sich die Meinung, der Canonical-Tag „muss“ zwingend immer aufs jeweilige Dokument selbst zeigen. Quatsch.

Mit einem kleinen Video aus OnPage.org TV möchte ich das Allgemeinwissen zu diesem Tag klären. Danach gehen wir in die Analyse mit der Webseite.

Jetzt wo jeder versteht was der Canonical Tag ist, legen wir einfach los und schauen was Apfelpage.de mit diesem Attribut anstellt.

canonical-tag-onpage

OnPage.org stellt verschiedene Ebenen für die Analyse zur Verfügung. Ich möchte jetzt auf folgende Bereiche eingehen:

  • Canonical Tag Verwendung
  • Relative Canonicals
  • Ungültige Canonicals
  • Widersprüchliche Canonicals

Den Abschnitt „Status Codes“ lasse ich an dieser Stelle noch aus, da diese Analyse nicht mehr direkt im Bereich „Meta / Head“ stattfindet sondern in der Seitenarchitektur. Und da komme ich in einem weiteren Teil des Tests noch drauf zu.

Die Grafik zeigt 11k Canonicals die auf die gleiche URL führen. Also auf sich selbst. Wie ich schon vorher sagte, setzt die Seite auf wpSEO und da ist auch das eine typische Einstellung. Geht auch grundsätzlich in Ordnung, so lange es keine Kopien sind, die auf sich selbst verweisen sondern wirklich die Originale. Dies muss aber der Seitenbetreiber immer selbst prüfen und einschätzen.

Ich schaue mir jetzt die Canonicals an, die nicht auf sich selbst zeigen. Denn auch das sind stolze 25k Stück.

canonical-fremde-url

Sofort erkenne ich dabei die „replytocom“ URLs wieder. Die pushen natürlich die Anzahl der Canonical Tags enorm. Sind aber korrekt eingesetzt. Denn niemand möchte eine solche URL bei Google als Original eingestuft bekommen. Wobei man diese Tags auch weglassen könnte, wenn solche URLs konsequent auf „noindex“ stehen und auch via robots.txt nicht für Suchmaschinen verfügbar sind.

Um jetzt zu prüfen welche URLs sonst betroffen sind, setze ich wieder einen Filter. Ich schließe einfach „replytocom“ in den URLs aus.

Jetzt bleiben noch 6 Treffer übrig. Davon möchte ich besonders auf einen Treffer eingehen.

canonical-301

Hier liegt ein kleiner Schönheitsfehler vor. Die URL verweist ohne den abschließenden Slash in der URL via Canonical auf eine andere URL. Diese jedoch integriert den Slash durch eine 301-Weiterleitung. Was am Ende dazu führt das man sich erneut auf der Ursprungsseite befindet. Hier muss nur beim Canoncial-Tag ein / hinten dran und fertig. Kann schon mal passieren. Ohne OnPage.org wäre dieser Fehler vermutlich auch nicht aufgefallen.

Die Startseite selbst verweist übrigens auch von ohne Slash mit Canonical auf die apfelpage.de/. Da das Logo und auch sonst die internen Navigationslinks aber die Startseite ohne / verlinken, sollte der Canonical für die Startseite entsprechend angepasst werden.

Relative Canonicals

Es sind alle Canonical Tags der Webseite „absolute“ Pfade. Somit zeigt OnPage.org hier keinerlei Fehler an sondern meldet alle Tags als grün. Google schreibt selbst auch, dass der Canonical-Tag immer „absolut“ und niemals „relativ“ sein soll. Nachzulesen in den Content Considerations.

Ungültige Canonicals

Auch in diesem Bereich liegen keine Fehler vor. Alle eingesetzten Attribute sind korrekt bzw. sind gültig und führend nicht auf eine 404 Seite oder andere Fehlerquelle. Sprich, der Besucher kommt über die verweisende kanonische URL immer zu Inhalten.

Widersprüchliche Canonical Tags

Zum Glück gibt es auch hier keine Fehler. Die kanonische URL kann ja im Header und in Meta-Angaben gemacht werden. Ein Widerspruch liegt dann vor, wenn diese beiden Einträge sich unterscheiden. Also der Eintrag im Header ein anderer ist, als der in den Meta-Daten. Da hier aber alles in Ordnung ist, kann ich auch nichts weiter analysieren.

Damit schließe ich den Bereich der Canonical Tags ab. Widmen wir uns dem nächsten Segment.

Robots-Attribut

Der Bereich der Robots-Attribute ist etwas übersichtlicher als die Canonicals. Gemessen an die Anzahl der Ebenen. Hier gibt es nur eine Ebene und es geht um den Einsatz von Index, Follow, Noindex und Nofollow im Meta-Bereich der Webseite.

Ich finde diesen Bereich sehr wichtig. Besonders wenn man SEO-Plugins oder WordPress Themes mit eigenen SEO-Konfigurationen nutzt und damit sich nicht weiter befasst, ist ein Blick in diesen Bereich kampfentscheidend. Und bei sehr großen Webseiten lassen sich hier fast immer ein paar Fehler oder Potentiale finden. So sieht es derzeit bei Apfelpage.de aus.

robots-attribut

In diesem Fall würde mich interessieren, was es an über 400 Seiten gibt, die Noindex als Attribut führen und dadurch nicht in den Google Index sollen. Schnell stellt sich heraus, es handelt sich auf den ersten Blick nur um „Blätterseiten“. Also Seiten, die beim Umblättern in Kategorien etc. generiert werden. Oder auch bei langen Beiträgen, wenn dieser mehrere Seiten beinhaltet.

noindex-attribut

Auch jetzt ist es empfehlenswert mit Filtern die Analyse zu vertiefen. Ich schließe im ersten Schritt /page/ aus den URLs aus.

filter-nichtseite

Ich schließe diese URLs deshalb aus, weil „Page“ immer nur bei Blätterseiten integriert ist. Nun habe ich in meiner Auswertung noch 51 Ergebnisse. Die kann ich manuell und ohne Filter durchsehen. Es sind mehrheitlich Archivseiten mit Zeitstempel. Hätte ich nun noch 500 Ergebnisse übrig, würde ich weitere Filter einbinden und kombinieren. Zum Beispiel die Jahreszahlen aus den URLs entfernen. Was dann noch bleibt?

noindex-fragwuerdig

Meistens ist mir der Einsatz vom Noindex-Attribut klar. Bei drei Ergebnissen jedoch bin ich unsicher, ob hier nicht besser ein „Index, Follow“ rein muss. Diese Seiten erscheinen mir wie kleine Hub Sites und sollten entsprechend intern verlinkt werden und gleichzeitig auch selbst in den Google-Index rein. Aber ggf. hat der Seitenbetreiber hier seine eigenen Gründe.

MIME-Type

Der nächste Bereich ist für den MIME-Type. Hier sind bis auf 10 Seiten, alle anderen Dokumente der Webseite in Ordnung. Bei 10 Seiten fehlt jedoch der MIME-Type.

mime-type

Die fehlenden MIME-Type sind nur bei den Feeds. In normalen Seiten sind alle MIME-Type vorhanden. Feeds verfügen nur über Header-MIME und nicht über Meta-MIME. Ob es alle Feeds der Webseite betrifft muss manuell geprüft werden.

mime-type-feed

Es kann sein, dass es nur 10 Ergebnisse sind, weil ich mit meinen 50.000 URLs Crawl-Budget komplett ausgereizt bin. Sollte aber kein Problem darstellen.

Sprache der Webseite

Im Meta- und Head-Bereich einer Webseite kann und sollte, die Sprache der Webseite festgelegt werden. Außerdem kann das auch über die Google Webmaster Tools gemacht werden. So hilft man sich selbst bei den Rankings in Google in verschiedenen Sprachregionen. Prüfen wir mal, wie es bei Apfelpage.de aussieht.

spachen

Bei 10 Dokumenten ist keine Sprache gesetzt, sonst ist überall eine Sprache gesetzt. Es widersprechen sich auch keine Angaben. Ob aber überall die korrekte Sprache gesetzt ist, sollte geprüft werden. Die Seiten ohne Sprache sind jeweils die Feeds, da ist also kein Problem. Sehen wir nun ob es Seiten gibt die nicht Deutsch als Sprache haben.

filter-umkehren

In den Analysen können immer die Werte in den „Snippets“ geklickt werden. Dadurch setzt man positive Filter. Um einen negativen Filter zu setzen, einfach beim „Klick“ die „ALT“-Taste gedrückt halten. In meinem Fall bedeutet es dann: „zeige mir alle Einträge, die nicht „Deutsch“ als Sprache haben.“ Dazu zählen auch Einträge ohne eine Sprache.

Hier gibt es für Apfelpage.de keine weiteren Sprachen. Es sind wirklich alle Seiten entweder „Deutsch“ konfiguriert oder es gibt gar keinen Eintrag. Und letzteres beschränkt sich wie gesagt auf Feeds.

Autorenverknüpfungen

Zwar hat Google die Autorenintegration in den Suchergebnissen in Form von Avataren abgeschafft, aber dies bedeutet nicht, den Verknüpfungen jede Relevanz entzogen zu haben.

Deshalb halte ich es weiterhin für sinnvoll, als Blogger oder Journalist meine eigenen Inhalte auch mit meinem Autorenprofil zu verknüpfen. Und ich würde es auch in erster Linie mit mir als Person verbinden und erst mit zweiter Priorität mit einer Seite. Zumindest wenn es um einen Blog geht. Bei einer Unternehmensseite verbindet man den Eintrag natürlich unbedingt auch mit einer Page statt einem Profil.

So verhält es sich bei Apfelpage.de im Moment.

autorenverknuepfungen

Die Masse an nicht vorhandenen Verknüpfungen liegt bei den „replytocom“ URLs. Mal wieder. 😉 Aber interessant ist auch der Unterschied der vorhandenen Profile. Es gibt zwei unterschiedliche Autoren mit unterschiedlicher Anzahl an Integrationen.

Die erste ID gehört der Apfelpage.de Fanpage auf Google Plus. Die zweite ID gehört einem personalisiertem Profil. Sie gehört aber nicht dem Betreiber der Seite und auch keinem aus der Redaktion. Zumindest ist der Name der Person im Impressum nicht geführt. Die ID vom Seitenbetreiber selbst ist dagegen gar nicht vorhanden. Was mich wundert und überarbeitet werden sollte.

Ob und in wie weit eine Integration jetzt korrekt ist oder nicht, muss der Seitenbetreiber selbst einschätzen. Daher kann ich in diesem Bereich nicht tiefer analysieren. Nur 313 Einträge mit einer Verknüpfung zur Fanpage erscheinen mir aber etwas wenig. Denn die Webseite hat deutlich mehr Inhalte. Entweder wurde es erst später eingefügt und ist nicht rückwirkend integriert, oder es gibt andere Gründe.

Weiterführende Links

Fazit zum Meta / Head Bereich

Wollt ihr wirklich nach über 3.300 Worten noch ein Fazit? 😉 Na gut.

Ich hatte bisher auch noch keinen Kontakt zum OnPage.org ZOOM! und bin selbst überrascht, wie tief eine Analyse geht. Die Filter sind sehr wichtig und helfen dabei, große Datenmengen übersichtlich zu analysieren. Ein bisschen Kritik gibt es wegen des fehlenden Zwischenspeichers für Filter. Und auch dafür, dass noch nicht ausreichend „Hilfe“-Inhalte für ZOOM! verfügbar sind. Sicher werden sich einige fragen was MIME-Types sind. Ein Problem gab es beim Crawling, konnte aber sofort vom Team behoben werden und ist deshalb nicht mehr relevant. So konnte ich auch den technischen Support testen. Zufrieden.

Mein Fazit für diesen Teil: Ich finde die neue Version bisher gelungen. Es ist ungewohnt über eine horizontale Navigation zu arbeiten. Ich musste mich beherrschen nicht zwischendurch in andere Bereiche zu gehen. Für den Testbericht und auch später im produktiven Einsatz ist es wichtig, diszipliniert zu arbeiten damit man nicht „kreuz und quer“ optimiert.

Im nächsten Teil (Teil 3), geht es um Inhalte, Texteinzigartigkeit usw. Freut euch also. Habt ihr Wünsche, Anregungen (außer Rechtschreibfehler)?

Professionelle Google Ads Betreuung

Hast du Interesse an professioneller Betreuung für Google Ads und Bing Ads? Dann melde dich bei mir und wir finden einen Weg, dein Projekt über Google Ads und Bing erfolgreicher zu machen. Mehr Umsatz, mehr EBIT, mehr Markensichtbarkeit!
Informationen ansehen

Über Soeren 432 Artikel
Ich bin Soeren, Blogger und Betreiber von eisy.eu. Über die Jahre hat es sich ergeben, dass mich viele einfach eisy nennen. Das ist okay. :-) Ich blogge seit 2005 und teile hier mein Wissen und meine Erfahrungen.

7 Kommentare

    • Diese Wahrnehmung kann ich bisher nicht bestätigen. Der maximale Preis für eine Domain mit 50.000 URLs beträgt 99 Euro im Monat. Sobald Du noch mehr Domains möchtest, sinkt der Preis pro Domain und Monat erheblich. Und die Funktionsvielfalt die mir bisher begegnete, bekommst Du ggf. auch bei keinem anderen Produkt am Markt (Stand heute). Dieser zweite Teil ist ja auch wieder nur „ein Teil“ von OnPage.org. Warte mal alle Teile ab. 🙂

      Teuer würde ich es nicht bezeichnen. Viel Geld sind 99 EUR aber natürlich.

  1. Für mich ist Onepage.org auch einfach zu teuer. Ich nutze Onepagedoc, kostet nur ein Bruchteil und reicht völlig aus. Habe das nun gut einen Monat im Einsatz und jetzt schon deutlich bessere Rankings.

    Aber wieder mal ein ganz toller Bericht Soeren!

  2. Ich schlag mal in die gleiche Kerbe, in der Hoffnung, dass hier jemand von Onpage.org mitließt: Ich verwende Onpage.org aus Preisgründen auch nur extrem punktuell und kündige dann sofort wieder. Gerade bei kleinen Kunden mit kleinen Websites (<50 Seiten) sind mir hundert Euro pro Monat für eine einzige Domain einfach zu teuer. Da gewöhne ich mir lieber an, mit unterschiedlichen Tools (Xovi + Screaming Frog + Xenu + Was gerade anliegt) zu arbeiten – was dazu führt, dass ich dann Onpage.org auch bei größeren Kunden nicht einsetze.

    Der Testbericht ist aber ganz große Klasse und ich freu' mich schon auf mehr! Herzlichen Dank dafür!

    • Servus Phil!
      Du kannst die Domain innerhalb Deines Projekts doch alle 36 Stunden ändern. So kannst Du easy auch mehrere kleinere Projekte auf Herz & Nieren prüfen.

Kommentar hinterlassen

E-Mail Adresse wird nicht veröffentlicht.


*