Community-Wiki
Advertisement
Community-Wiki

Evolving with the web.png

Während das Web wächst und sich weiterentwickelt, müssen auch die technischen Aspekte von Seiten wie Fandom an die neuen Umstände und Gewohnheiten der Benutzerinnen und Benutzer angepasst werden.

Obwohl wir gerne sagen würden, die meisten Leute würden einfach die Webadresse eines Fandom-Wikis eintippen, um Informationen zu erhalten, ist die Wahrheit, dass über 80 Prozent der Aufrufe über Suchmaschinenergebnisse zu uns finden.[1] In den meisten Teilen der Welt bietet Google die nahezu einzig relevante Plattform für Websuchen.[2] Hinzu kommt: Die meisten Personen suchen nicht nach bestimmten Wikis, sondern nach spezifischen Inhalten, Themen und Seitennamen. Dies stellt eine Änderung der Gewohnheiten der Internetnutzer dar.

Google aktualisiert regelmäßig die Algorithmen, welche hinter dem Suchdienst stecken. Gelegentlich signalisieren sie der Öffentlichkeit ihre Pläne. Wir erwarten, dass drei dieser angekündigten Änderungen[3][4][5] wegen der Natur von Wikis und ihrer Entstehung einen großen Einfluss auf Fandom im Besonderen haben werden. Reagieren wir nicht rechtzeitig, könnte das zukünftig die Sichtbarkeit sowohl einzelner Wikis als auch der Plattform als Ganzes in den Suchergebnissen schaden. Daher soll dieser Leitfaden darüber aufklären, wie Wikis aus technischer und menschlicher Sicht gesehen werden und was Communitys tun können, um im sich entwickelnden Web mithalten zu können.

Maßstäbe

Die Geschwindigkeit und Performanz eines Wikis hängt von vielen Faktoren ab. Für jeden Schritt in diesem Prozess gibt es verschiedene Maßstäbe.

Grundlage: MediaWiki

Bevor eine Wiki-Seite im Internet dargestellt werden kann, muss sie in HTML umgewandelt werden. Der Prozess des Parsens und Renderns findet innerhalb der MediaWiki-Server-Software statt. Es findet dabei eine schrittweise Übersetzung in „die Sprache des Internets“ von Ebene zu Ebene statt. Die Geschwindigkeit dieser Verarbeitung und der Bereitstellung der Daten liegt in der Regel in unter zwei Sekunden. Wenn dieselbe Seite unverändert erneut dargestellt werden soll, kann dieser Vorgang durch einen Prozess, dem Caching, weiter beschleunigt werden.

Die Performanz einer MediaWiki-Seite wird in Zeit, Speicherressourcen, die zum Rendern der Seite benötigt wurden, und der Komplexität des HTML-Ergebnisses gemessen. Letzteres hat damit zu tun, dass Browser den Code interpretieren müssen, um diesen in eine für Menschen sichtbare Form umzuwandeln. Seiten, auf denen Informationen aufgerufen werden, welche sich an anderer Stelle auf dem Server befinden (dieser Vorgang wird Transklusion genannt), benötigen dabei mehr Zeit und Ressourcen. Die Nutzung von Vorlagen ist eine Form von Transklusion. Die Komplexität und Verschachtelungstiefe von Vorlagencode beeinflusst also die Performanz. Je nach Arbeitsweise kann das auch Erweiterungen betreffen, welche Inhalte einer Seite in einer anderen einbinden (zum Beispiel DynamicPageList).

Fließdiagramm, welches den Renderprozess von MediaWiki visualisiert

Core Web Vitals

In letzter Zeit achtet Google vor allem auf drei Schlüsselwerte, die einen Aufschluss über die Performanz von Seiten geben, und die Platzierung der Inhalte in den Suchergebnissen beeinflussen. Diese Werte, Core Web Vitals genannt, sind:

  • Largest Contentful Paint oder LCP, was die Ladegeschwindigkeit bzw. die Zeit, die es braucht, bis der Großteil des Inhalts für Besucherinnen und Besucher sichtbar ist, darstellt.
  • First Input Delay oder FID, was die Interaktivität darstellt, also die Zeit, die es braucht, bis zum Beispiel Links oder Formulare angeklickt werden können.
  • Cumulative Layout Shift oder CLS, was die visuelle Stabilität darstellt. Gemeint ist damit, wie sehr sich ursprünglich sichtbare Elemente noch bewegen, bevor man mit ihnen interagieren kann.

Ein großer Teil von dem, was von den Core Web Vitals erfasst wird, ist abhängig davon, wie Fandom Seiten technisch bereitstellt. Es gibt aber auch einige Dinge, die Communitys tun können, um die Werte ihres Wikis zu verbessern. Das Hauptaugenmerk legt Google dabei aber nicht auf die Desktopansicht, sondern auf die Ansicht, die nicht angemeldete Besucherinnen und Besucher auf Mobilgeräten bekommen. Bei einigen Gesichtspunkten beachtet Google individuelle Wikis beim Erstellen der Rankings, bei anderen wird Fandom als Ganzes betrachtet.

Verständliche Inhalte

Es spielt eine große Rolle, dass die Wiki-Seiten gut sichtbar und auffindbar sind.

Blind men and elephant4.jpg

Wichtige Teile des Google-Algorithmus betreffen „Passage Ranking“ und „Total Page Indexing“. Google erstellt „Pläne“ und Kopien in den eigenen Datenbanken, indem die Crawler allen verlinkten Seiten auf einer Seite folgen. Diese Pläne werden dann genutzt, um bestimmte Informationen zu finden. Die gespeicherten Informationen betreffen den gelesenen Inhalt sowie den Kontext dieses. Wenn zum Beispiel auf einer Seite (in einem zusammenhängenden Satz) „X ist die Mutter von Y“ und auf einer anderen Seite „Z ist der Vater von X“ steht, „weiß“ Google (ohne dass es explizit irgendwo geschrieben steht), dass Z der Großvater von Y ist. Das Verarbeiten dieser semantischen Zusammenhänge ermöglicht es Google, Fragen zu beantworten, wenn jemand danach sucht. Früher basierte das Crawlen auf Schlüsselwörtern, die auf Seiten gefunden wurden. Passage Ranking hingegen ermöglicht das Erstellen von Modellen anhand von natürlicher Sprache und sichtbarer Daten (wie Tabellen oder Infoboxen). Auf gewisse Weise ähnelt das sehr dem Gleichnis Die blinden Männer und der Elefant[6], bei dem aus ungleichen Informationen ein Gesamtbild geschaffen wird. Daher ist es hilfreich, möglichst viel Kontext und ausführliche Schilderungen zu bieten. Es ist kein Zufall, dass dadurch auch uns Menschen das Verständnis von Inhalten leichter fällt, denn viele von Google verwendete Methoden wurden dem menschlichen Denken nachempfunden. Wenn Google den Inhalt einer Seite versteht, geht Google davon aus, dass es sich auch um die beste Ressource handelt, mit der Menschen den Inhalt verstehen können und platziert die Seite (und andere Seiten des Wikis) höher in den Suchergebnissen.

Sehr kurze Seiten mit den wichtigsten Fakten zu haben, ist für Datenbank-orientierte Webseiten hilfreicher als für Fandom-Wikis, in denen Besucher nach dem gesammelten Wissen der Fans suchen. Es ist dabei wichtig einschätzen zu können, wann man Unterthemen teilt und wann man kurze Seiten zu ähnlichen Themen zusammenführt.

Nutzungserlebnis

Niemand wird bleiben, wenn er verscheucht wird. Artikel, die nur aus Informationsauflistungen bestehen, oder die schwer bedienbar sind, verleiten dazu, lieber woanders zu suchen. Gleiches gilt für schlecht geschriebene Seiten oder solche, die generell eine schlechte Qualität aufweisen.

Google misst das Nutzungserlebnis auf verschiedene Weisen. Objektiv kann Google erfassen, wie viel Zeit auf einer Seite verbracht wird und durch Modelle erfassen, wie man die Inhalte erlebt. Außerdem beschäftigt Google menschliche Qualitäts-Bewerter, um zu verifizieren, wie erfolgreich der Algorithmus dabei ist, Suchende an die richtigen Stellen weiterzuleiten. Diese Bewerter geben auch eine Einschätzung darüber ab, wie nützlich und bedienbar eine Quelle ist.

Der wichtigste Maßstab des Nutzungserlebnisses erfasst allerdings, wie einfach oder kompliziert es ist, eine Webseite zu bedienen (besonders auf Mobilgeräten). Egal wie hübsch das Design oder die Funktionen einer Seite sind – sie ändern nichts daran, wie organisiert Material ist oder wie es geschrieben ist. Solche Funktionen können das Nutzungserlebnis sogar negativ beeinflussen, zum Beispiel, wenn nach bestimmten Inhalten gesucht wird und diese hinter Elementen versteckt oder wegen zu vieler Spielereien nicht auffindbar sind.

Praktische Anpassungen

Als Bearbeiter oder Bearbeiterin hat man einige Möglichkeiten, um die Performanz eines Wikis zu verbessern. Dabei muss man sich einige Dinge abgewöhnen, die den Entwicklungen des Internets seit der ersten Entstehung von Wikis geschuldet sind. Einzeln machen diese Dinge nicht viel aus, aber zusammen können sie die Position eines Wikis verbessern.

Seiteninhalte und Stubs

Es gibt zwar MediaWiki-Tools zur Erfassung und Interpretation der technischen Aspekte von Wiki-Seiten, zum Beispiel deren Länge, allerdings können diese keine oberflächlichen Inhalte oder Stubs identifizieren. „Stubs“ ist ein traditioneller Ausdruck für Wiki-Seiten, welche manuell als unvollständig markiert wurden. Oberflächlicher Inhalt ist solcher, der nicht die Fragen von jemandem beantwortet, der nach Informationen sucht. Aus diesem Grund sind Stubs und oberflächliche Inhalte in der Regel dasselbe, auch wenn nicht alle kurzen Seiten Stubs sind. Fandom-Wikis werden zur Zeit nicht im Ganzen für die Fülle an kurzen Seiten bestraft, obwohl es Beweise dafür gibt, dass Google Rückschlüsse auf eine Community (oder die ganze Plattform) zieht, wenn es Mustern von oberflächlichen Inhalten begegnet. In der Zukunft könnte das Auswirkungen haben.

Kurze Seiten haben einen schmalen Inhaltsbereich – es kann dazu kommen, dass Headerbereiche und Werkzeugleisten zum größten Teil einer Seite werden. Die kurzen Inhaltsbereiche können dadurch relativ gesehen mehr durch andere Elemente wie Werkzeugleisten verschoben werden – der CLS-Wert ist hoch (und daher schlecht). Wegen ihrer interaktiven Beschaffenheit laden Header und Werkzeugleisten langsamer als Texte. Wenn sie den größten Seitenbereich ausmachen (gemessen an HTML-Umfang, nicht der visuellen Ausdehnung) und am langsamsten laden, fallen auch der LCP- und FID-Wert alles andere als ideal aus.

Stubs tendieren aufgrund ihrer Oberflächlichkeit dazu, in den Google-Ergebnissen weiter unten gelistet zu werden. Ein signifikanter Prozentsatz von Stubs gegenüber vollständigen Seiten kann dazu führen, dass Google insgesamt das Vertrauen darin verliert, anhand des Wiki-Inhalts Fragen beantworten zu können. Als Folge wird das gesamte Wiki niedriger in den Ergebnissen gelistet – sogar die vollständigen Seiten. Stubs sollten daher so schnell wie möglich (innerhalb von 30 Tagen, wenn man davon ausgeht, dass Google ein Wiki regelmäßig neu indexiert) beseitigt werden – durch Vervollständigen, Löschen oder Zusammenschluss mit einer thematisch passenden Seite. Es hilft, sich in Erinnerung zu rufen, dass Menschen ähnlich denken und unvollständige und isolierte Informationen nicht gerne nutzen. Leere Seitenabschnitte, insbesondere, wenn es sich um den Einleitungsbereich handelt, haben einen negativen Einfluss auf die Google-Parser und die Nutzungserfahrung menschlicher Besucherinnen und Besucher, da eine solche Leere eher mit Sackgassen als mit Chancen verbunden wird.

„Redlinks“ (Platzhalter-Links zu nicht existierenden Seiten) wurden in der Vergangenheit als Chance gesehen, Personen zum Bearbeiten anzuregen. Dennoch schaden sie den Core Web Vitals und werden aus diesem Grund in der mobilen Ansicht als normaler Text angezeigt. Sie führen Suchmaschinen-Crawler zu nicht existierenden Bereichen, die effektiv als Fehler (fehlende Seite) gesehen werden. Die Anzahl dieser Fehler senkt aus Googles Sicht die Glaubwürdigkeit und Zuverlässigkeit einer Webseite. Die Reduzierung der Anzahl von Redlinks wirkt sich positiv auf die Platzierung einer Seite aus.

Kategorieseiten werden oft vernachlässigt, können aber ebenso hoch wie normale Artikelseiten in den Suchergebnissen auftauchen, wenn Google sie für relevant hält. Ohne Kontext oder Beschreibung, erscheint in Googles Ergebnissen nur wirrer Text. Daher sollte jede Kategorieseite zumindest eine kurze Beschreibung beinhalten.

Robustheit und mobile Nutzbarkeit einer Seite

Falsch interpretiert werden häufig Aufteilungen von Inhalten in Segmente (entweder durch Links am Seitenanfang oder interaktive Reiter). Verlinken diese zu anderen Seiten, erzeugen sie automatisch den Eindruck von unvollständigen Konzepten. Die Aufteilung von Informationen, welche eigentlich Konzept eines einzelnen Artikels sind (zum Beispiel Charaktere, Episoden, Waffen – auch als „Inhaltsentität“ bezeichnet), macht es für Google schwieriger, ein Modell dieser Inhalte zu erstellen. Parallel dazu ist es unwahrscheinlich, dass menschliche Leserinnen und Leser mehrere Seiten ansehen wollen, um verschiedene Facetten eines Oberthemas zu verstehen. Diesen Effekt beschreibt man manchmal mit „Unsere Prinzessin ist in einem anderen Schloss“, weil der Suchende mehrere Links „durchreisen“ muss, um zu finden, wonach er sucht.

Ein „ganzes Bild“ zu bieten, indem sich eine tiefere und längere Erklärung eines einzelnen Aspekts auf einer separaten Seite befindet, ist nicht schlecht. Eine Übersichtsseite sollte aber mindestens die Grundlagen beinhalten, die es braucht, um die Konzepte der Artikel zu verstehen. Links innerhalb des Inhaltsbereiches (zum Beispiel durch Nutzung von Vorlagen wie {{Siehe auch}} unter Abschnittsüberschriften) kann Suchende zu detaillierteren Informationen leiten, wenn sie das wollen. Am besten finden sie zusätzlich eine Erklärung zum Kontext. Wie würde zum Beispiel jemand auf einer Seite mit Links zu „Biografie“ und „Geschichte“ wissen, welche Informationen man auf den jeweiligen Seiten findet? Jede Inhaltsseite muss in sich zusammenhängend und keine Fragmentsammlung sein.

Erwähnenswert ist zudem, dass solche Seiten-Reiter auf Mobilgeräten nicht richtig funktionieren, wenn sie mit JavaScript oder Vorlagen erstellt wurden. Reine Links haben für Google außerdem keine Relevanz mit semantischem Hintergrund (der Kontext fehlt). Anstatt etwas Neues zu erschaffen, das gar nicht oder nicht richtig funktioniert, können zum Beispiel <navigation>-Tags in Infoboxen genutzt werden, die eine Brücke bilden.

In diesem Modell wird unterschieden zwischen Reiter-Links am Seitenanfang und Link-Symbolen an beliebiger anderer Stelle auf der Seite (den Seitenanfang eingeschlossen). Beide Formen sind auf Mobilgeräten schwer darzustellen und zu bedienen. Beide sollten daher in ein Navigations-Tag einer Infobox gebracht werden.

Kein Textabschnitt ist so wichtig für einen Artikel wie eine Infobox. Zusammen mit dem Einleitungsbereich liefert eine Infobox Kontext und Daten zum Artikelthema. Aus diesem Grund erhalten sie im mobilen Skin eine Spezialbehandlung. Ihre prominente Position macht sie geeignet zur Navigation und Verlinkung nah verwandter Seiten.

Ein Problem von Seiten ist häufig, dass sie keinen narrativen Anker bieten, um Bilder, Tabellen und Galerien in einen Kontext zu setzen. Ein solcher Anker hat semantische Gründe (damit Google und Leser verstehen, was das Verhältnis zwischen dem Element und dem Inhalt ist) und dient der Zugänglichmachung der Inhalte (zum Beispiel, damit Bildschirmleser einen Hinweis darauf geben können, ob ein Element relevant ist, bevor es interpretiert wird). Idealerweise sollten alle Bilder eine Bildunterschrift (Text, der das Bild in den Kontext des Artikels einordnet, z. B. „Batman 2020“) und/oder einen Alternativtext (der für Personen, die ein Bild nicht sehen können, beschreibt, was auf dem Bild zu sehen ist, z. B. „Eine Person in Fledermaus-ähnlichem Kostüm (Batman) grübelt bei Nacht auf einem Dach“) haben. Anders ausgedrückt: Alternativtext beschreibt, was etwas ist, und eine Bildunterschrift erklärt, warum es zu sehen ist. Es ist für den Renderprozess und das menschliche Verständnis einfacher, wenn lange Bildergalerien, die man gruppieren kann, in kleinere Galerien aufgeteilt werden. Ideal ist dabei die Verschachtelung solcher Bilder mit dem erklärenden Fließtext, damit sie sich gegenseitig ergänzen. Ein solches Layout funktionieren auf allen Geräten.

Seiten kürzen

Aus Sicht einer Suchmaschine sind lange Seiten von Natur aus unproblematisch. Wie oben erklärt, werden die Inhalte dann eher als zusammenhängend interpretiert. Sofern der Seiteninhalt gut strukturiert ist, finden auch Leserinnen und Leser die Inhalte, nach denen sie suchen.

Das Platzieren von Inhalten in Reiterstrukturen („Tabber“) stellt eine technische Hürde dar. Das Bearbeiten von Inhalt in verschachtelten Wikitext-Blöcken ist mit dem VisualEditor, den die meisten nutzen, kompliziert. Aber auch im Quelltexteditor kann es schwer sein, zu identifizieren, wo ein Element beginnt oder endet. Die Ebene von interaktivem JavaScript erhöht den FID-Wert, weil ein Rendern der Elemente nötig ist. Sofern der Tabber in dem Bereich ist, der beim Seitenladen zuerst sichtbar ist, wird auch der CLS-Wert erhöht. Hinzu kommt, dass die Bedienung der Reiter auf Mobilgeräten möglicherweise gar nicht möglich ist. Berichte weisen darauf hin, dass Inhalte, die in einem nicht sichtbaren Reiter eines Tabbers versteckt sind, von Google als weniger wichtig angesehen werden.

Am wichtigsten bei der Betrachtung von Tabbern ist jedoch das Nutzungserlebnis: Inhalte, die sich nicht im ersten (sichtbaren) Reiter befinden, sind „aus den Augen, aus dem Sinn“. Sie werden seltener angeklickt und gelesen – mit jedem zusätzlichen Reiter nimmt diese Anzahl dabei ab. In den meisten Fällen wissen Leserinnen und Leser nicht mal, dass es Inhalte gibt, die nicht sofort sichtbar sind, und übersehen die Reiter bei der Suche nach Informationen.

Aus diesem Grund ist die Nutzung von Tabbern zum Kürzen von Seiten aus Sicht der Performanz und der Nutzbarkeit in den meisten Fällen nicht geeignet. Falls Tabber überhaupt mal genutzt werden, sollten sie:

  • nicht verschachtelt in anderen Elementen sein,
  • nur eine visuelle Reihe von Reitern haben und
  • anschauliche Beschreibungen haben.

DataTables ist eine Funktion, die wir euch ans Herz legen möchten und bald im Fandom Developers Wiki zur Verfügung steht. DataTables fügt viele neue Funktionen hinzu, welche die Nutzung von langen Datentabellen vereinfachen sollen. Von der Nutzung mehrerer Infoboxen auf einer Seite ist aus Gründen der Verarbeitungsgeschwindigkeit und des Parsens der Informationen durch Suchmaschinen abzuraten. Insbesondere Infoboxen, die viele ähnliche Informationen enthalten, sollten daher ein einer einzelnen Box vereint werden. Zusätzlich kann die Panel-Funktion genutzt werden.

Startseiten und Navigation

Startseiten sind für Wikis aus unterschiedlichen Gründen sehr wichtig. Für Menschen und Maschinen, die ein Wiki aufrufen, indem sie nur die Basis-URL aufrufen (statt einer speziellen Seite), ist sie der primäre Einstiegspunkt, von dem Links weiter führen. Google nutzt Links auf der Startseite und der lokalen Navigationsleiste als wichtige Indikatoren dafür, was das Thema eines Wikis ist. Wenn Google ein Wiki zum ersten Mal untersucht, interpretiert es alle Links als gleichwertig (bezogen auf ihre Relevanz für das Thema). Das funktioniert, wenn es 10-20 Links zu Seiten und Kategorien gibt. Wenn Module und Panel auf der Startseite hunderte von Links hinzufügen, ist der Gehalt dieser Links nahezu null. Auch dies spiegelt das menschliche Verhalten wider: Hat man zu viel Auswahl, kann man sich nicht entscheiden. Man weiß nicht, wo man Beginnen soll, um das Thema zu verstehen.

Aus technischen Gründen und für ein besseres Nutzungserlebnis raten wir daher dazu, Links auf der Startseite auf die wichtigsten Seiten und Kategorien zu beschränken. Wir raten auch von Widgets ab, welche automatisiert Links anzeigen, da dadurch die Renderzeit erhöht wird. Wenn man davon ausgeht, dass an anderer Stelle zu ihnen verlinkt wird, findet der Crawler sie sowieso. Gut zu wissen ist auch, dass Google beim Aufrufen von Spezial- oder Diskussionsseiten in den meisten Fällen aufgefordert wird, diese nicht zu crawlen und eine Fehlermeldung erhält oder weitergeleitet wird. Wir empfehlen, keine Links zu diesen auf der Startseite einzubinden – zumal sich Links zu diesen normalerweise bereits in der lokalen Navigation oder der Community-Seite befinden, welche für Google nicht sofort sichtbar sind.

Die Einbindung von Videos in ein Wiki kann Chancen bieten. Wir empfehlen dabei ein Maximum von zwei bis drei eingebetteten Video-Playern auf der Startseite. Ansonsten könnte die Ladezeit der Seite und die Effektivität der Videos negativ beeinflusst werden.

Das Web entwickelt sich

Es ist wichtig, dass Google mit unseren Seiten zufrieden ist, denn dadurch finden Leute zu uns. Die Algorithmen basieren dabei auf menschlichen Gedanken und Verhaltensweisen. Bei den dargestellten Praktiken handelt es sich nicht um Strafen für Wikis. Es handelt sich vielmehr um Maßnahmen, um einzelne Wikis in einem sich entwickelnden Internet relevant zu halten.

Auf Hilfe:Performance findest du einige der Methoden zusammengefasst.

  1. Es ist schwierig, hier genaue Angaben zu machen. Man muss sich im Klaren darüber sein, wie wichtig Google für das Internet weltweit geworden ist. Die wenigsten Informationsseiten könnten ohne Google dauerhaft gleichmäßige Besucherzahlen erreichen. Die Google-Suche macht im wahrsten Sinne des Wortes aus Chaos Ordnung und treibt damit das gesamte Internet an.
  2. Googles Suchplattform ist in nahezu allen Sprachen und Ländern vorherrschend, abgesehen von China, Japan, Russland, Südkorea und der Türkei. Selbst im Großteil der genannten Länder beherrscht Google einen großen Teil des Marktes – oder wird durch die nationalen Regierungen beschränkt. Auch wenn einzelne Nutzerinnen und Nutzer Bing, Yahoo, Baidu, Yandex oder DuckDuckGo präferieren mögen, repräsentieren diese Suchanbieter zusammen nicht mehr als 10 % aller Websuchen weltweit. Google ist daher effektiv die einzig relevante Suchmaschine für Fandom. Im Endeffekt nutzt es aber der Platzierung in allen Suchmaschinen, wenn wir Google als Maßstab für unsere Praktiken nehmen.
  3. Barry Schwartz, „Google: Mobile-First Indexing Should Be Mobile-Only Indexing,“ Search Engine Roundtable (https://www.seroundtable.com/google-mobile-first-indexing-mobile-only-indexing-30270.html, ohne Datum)
  4. Roger Montti, „What Is Google Passage Ranking: 16 Key Points You Should Know,“ Search Engine Journal (https://www.searchenginejournal.com/google-passage-ranking-martin-splitt/388206/, November 2020)
  5. Detlef Johnson, „Guide to Core Web Vitals for SEOs and Developers,“ Search Engine Land (https://searchengineland.com/google-core-web-vitals-guide-for-seo-developers-337825, Juli 2020)
  6. Gleichnis Die blinden Männer und der Elefant (Bild “Blind Men and an Elephant,” 1907.)


SpacePucky avatar.png

Pucky FANDOM-HELFER

SpacePucky ist Mitglied des International Volunteering Teams und übersetzt unter anderem Blog-Beiträge für die deutschsprachige Community. Außerdem kümmert er sich um die Aktualisierung der Hilfeseiten. Zu seinen sonstigen Projekten gehören aktuell das YouTube Wiki und das Deponia Wiki.

Willst du weitere Updates von Fandom erhalten? Klicke hier, um diesen Blog zu verfolgen.