Rendering: teljes útmutató

A rendering az a lépés, amikor a kereső a letöltött oldalt egy böngészőmotorral megjeleníti, lefuttatja a JavaScriptet, és megnézi, mi lett a végeredmény. Ami csak ezután jelenik meg, azt a kereső később látja meg, mint a nyers HTML-ben lévő tartalmat, és néha egyáltalán nem.

Alapfogalmak

Nyers HTML és megjelenített HTML

A nyers HTML az, amit a kiszolgáló küld. A megjelenített HTML az, ami a JavaScript lefutása után áll elő. A kettő lehet szinte azonos, és lehet drámaian különböző. A böngésződben a forráskód megtekintése az elsőt mutatja, a fejlesztői eszközök elemvizsgálója a másodikat. Ez a legolcsóbb módja annak, hogy lásd, mekkora a különbség.

Kiszolgálóoldali megjelenítés

A kiszolgáló állítja elő a kész HTML-t, és azt küldi el. A kereső azonnal látja a tartalmat, mert nincs mire várnia. Ez a legbiztonságosabb megoldás keresőoptimalizálás szempontjából.

Böngészőoldali megjelenítés

A kiszolgáló egy szinte üres vázat küld, és a tartalmat a böngészőben futó JavaScript tölti be. A látogatónak ez általában nem tűnik fel, a keresőnek viszont plusz munka, és plusz kockázat.

Előre generált oldalak

A tartalom építéskor előre elkészül statikus HTML-ként. Gyors, olcsó és a kereső számára tökéletesen látható. Cserébe minden tartalomváltozásnál újra kell generálni.

Vegyes megoldás

Az első betöltés kiszolgálóoldali, utána a böngésző veszi át a vezérlést. Ez a mai keretrendszerek jellemző működése, és jól működik, ha a fontos tartalom az első betöltésben benne van.

Hogyan működik?

A kereső a letöltés után nem feltétlenül jeleníti meg azonnal az oldalt. A megjelenítés erőforrásigényes, ezért külön sorba kerül, és ott várakozik. A várakozás hossza változó, és nem befolyásolható.

Miért számít a késleltetés

Két oldal, azonos tartalommal: az egyiken a szöveg a nyers HTML-ben van, a másikon csak JavaScript után jelenik meg. Az elsőt a kereső a letöltés pillanatában feldolgozhatja. A másodikat csak akkor, amikor a megjelenítési sorban sorra kerül. Friss, időérzékeny tartalomnál ez a különbség számít a legtöbbet.

Mi romolhat el a megjelenítés közben

Blokkolt erőforrás. Ha a robots fájl kitiltja a szkript- vagy stílusfájlokat, a kereső nem tudja végigfuttatni az oldalt, és hiányosan látja.
Időtúllépés. Ha egy adatlekérés lassú, a megjelenítés befejeződhet azelőtt, hogy a tartalom megérkezne.
Hibás szkript. Egyetlen hiba megállíthatja a futást, és onnantól semmi nem töltődik be.
Felhasználói interakcióhoz kötött tartalom. Amit csak kattintás után tölt be az oldal, azt a kereső nem fogja látni, mert nem kattint.

A linkek külön kérdés

A kereső a hivatkozásokból fedezi fel a további oldalakat. Ha a linkek csak JavaScript után jönnek létre, vagy nem valódi hivatkozások, hanem kattintás-kezelők, akkor a felfedezés is a megjelenítésre vár, vagy el sem történik. Ez az egyik leggyakoribb rejtett oka annak, hogy egy szekció nem kerül be az indexbe.

Fő módszerek

1. Tedd a fontosat a nyers HTML-be

A legegyszerűbb szabály, ami a legtöbb problémát megoldja. A címsor, a törzsszöveg, a belső linkek és a metaadatok legyenek benne a kiszolgált HTML-ben. Ami ezen kívül van, az kényelmi funkció lehet, de ne múljon rajta a tartalom.

2. Használj valódi hivatkozásokat

A navigáció és a listák linkjei legyenek rendes hivatkozások címmel, ne kattintásra reagáló elemek. Így a kereső akkor is követni tudja őket, ha a megjelenítés késik.

3. Ne tiltsd ki a szkripteket és a stílusokat

Régi szokás volt ezeket a robots fájlban blokkolni, hogy ne vigyék el a bejárási keretet. Ma ez kárt okoz: a kereső nem tudja rendesen megjeleníteni az oldalt, és hiányosnak vagy rosszul használhatónak látja.

4. A végtelen görgetés mellé tegyél lapozást

A görgetésre betöltődő tartalom a keresőnek nem létezik, mert nem görget. Ha a lista fontos, legyen mellette hagyományos lapozás valódi linkekkel, akkor is, ha a látogatók többsége görget.

5. A késleltetett képbetöltésnél maradjon forrás

A képek késleltetett betöltése hasznos a sebesség miatt, de a képnek maradjon valódi forrásmegjelölése és mérete, különben a képkeresőből kiesel.

Gyakori hibák

„A böngészőben látszik, tehát rendben van"

A böngésződ türelmes, gyors hálózaton fut, és kattint is, ha kell. A kereső egyik sem. Attól, hogy te látod a tartalmat, a kereső még nem biztos, hogy látja.

A metaadatok JavaScripttel

A cím és a leírás cseréje futás közben működhet, de kockázatos: ha a megjelenítés késik vagy elakad, a kereső az eredeti, jellemzően általános változatot látja. A metaadatok legyenek benne a kiszolgált HTML-ben.

Egyetlen közös váz minden oldalhoz

Ha minden cím ugyanazt a nyers HTML-t adja vissza, és csak a JavaScript dönti el, mi jelenjen meg, akkor a kereső kezdetben minden oldalt azonosnak lát. Ez duplikációs problémákhoz vezet, és a megkülönböztetés a megjelenítésre marad.

A tesztelés kihagyása átalakítás után

A keretrendszer verziófrissítése vagy egy beállítás módosítása csendben átkapcsolhatja a megjelenítési módot. Ilyenkor a látogató semmit nem vesz észre, a kereső viszont hetek alatt elveszíti az oldalakat.

Melyik megjelenítési módot válaszd

Ez nem ízlés kérdése, hanem az oldal jellegéből következik. Négy tipikus helyzet, és mindegyikhez egy világos válasz.

Oldal jellege	Ajánlott mód	Miért
Blog, tartalmi oldal	Előre generált statikus	Ritkán változik, gyors, a kereső azonnal látja
Webshop terméklistával	Kiszolgálóoldali vagy vegyes	Sok oldal, gyakori változás, kritikus a keresőbeli jelenlét
Bejelentkezés utáni felület	Böngészőoldali	Nem is akarod, hogy indexelve legyen
Landing oldal kampányra	Kiszolgálóoldali	Egyetlen oldal, a betöltési sebesség konverziót érint

A táblázat egyetlen elvet fogalmaz meg: ami keresésből kell hogy forgalmat hozzon, azt a kiszolgáló adja ki készen. Ami mögötte van, és amit csak a bejelentkezett felhasználó lát, ott a böngészőoldali megoldás teljesen rendben van.

A leggyakoribb rossz döntés

Az, hogy a fejlesztői kényelem dönt. Egy egységes böngészőoldali alkalmazás gyorsabban elkészül, és a fejlesztő szemszögéből tisztább. A költség viszont a keresőbeli jelenlét, és ez fél évvel később derül ki, amikor már drága átalakítani.

Érdemes ezt a kérdést a projekt elején eldönteni, és a döntést leírni: melyik oldaltípus honnan kapja a tartalmát. Utólag ez az egyik legdrágább átalakítás.

Egy végigvitt eset: az eltűnt termékleírások

Egy webshop átállt új rendszerre. A látogatók számára minden ugyanolyan maradt, a forgalom viszont hetek alatt harmadára esett.

Mit mértünk

Forráskód. A termékleírás egyetlen mondata sem szerepelt a nyers HTML-ben. A kiszolgáló egy vázat küldött, a tartalom JavaScriptből jött.
Kikapcsolt JavaScript. Az oldal üres volt, csak a fejléc és a lábléc látszott.
Keresőkonzol. A megjelenített kódban a leírás egy része megvolt, egy része nem, tehát a megjelenítés részben sikerült, részben nem.
Indexelt szöveg keresése. Idézőjeles kereséssel a régi leírások még megvoltak az indexben, az újak nem.

Mit csináltunk

A termékleírás és a cím átkerült a kiszolgálóoldali kimenetbe. A kategóriaoldalak lapozása valódi linkekre cserélődött a görgetéses betöltés mellett. Semmi más nem változott.

Az eredmény

A termékoldalak hetek alatt visszakerültek az indexbe. A tanulság az, ami ilyenkor mindig: a baj nem akkor keletkezett, amikor a forgalom esett, hanem amikor a rendszer átállt, és senki nem nézte meg a nyers HTML-t. Egy háromperces ellenőrzés a bevezetés napján megelőzte volna.

Mérés

A három perces ellenőrzés

Nézd meg a forráskódot. Keress rá a törzsszöveg egy mondatára. Ha megtalálod, a tartalom a nyers HTML-ben van.
Kapcsold ki a JavaScriptet a böngésződben, és töltsd újra az oldalt. Amit így látsz, azt a kereső biztosan látja.
Nézd meg a linkeket kikapcsolt JavaScript mellett. Ha a menü eltűnik, a felfedezés is a megjelenítésre vár.

A keresőkonzol megjelenített kódja

Az egyedi cím vizsgálatakor megnézheted, hogy a kereső mit látott a megjelenítés után, és milyen erőforrásokat nem tudott betölteni. Ez a legpontosabb visszajelzés, mert a kereső saját eredménye, nem szimuláció.

Indexelt szövegrész keresése

Írj be a keresőbe egy pontos mondatot az oldaladról idézőjelben. Ha a keresőnek megvan a mondat, akkor a szöveg bekerült az indexbe. Ha nem, akkor vagy még nem dolgozta fel, vagy nem látta.

Döntési szabály

Ha a kikapcsolt JavaScriptes nézetben megvan a tartalom és a navigáció, akkor a megjelenítés nem a te problémád, és tovább kell lépni a bejárási vagy indexelési kérdésekre. Ha hiányzik, akkor itt a teendő, és semmilyen szövegírás nem fogja megoldani.

Mit kérj a fejlesztőtől, konkrétan

A megjelenítés az a terület, ahol a SEO és a fejlesztés találkozik, és ahol a félreértések a legdrágábbak. Nem elég annyit mondani, hogy „legyen SEO-barát". Hat konkrét kérés, amit egy fejlesztő értelmezni tud:

A törzsszöveg, a H1 és a metaadatok a kiszolgált HTML-ben legyenek minden olyan oldaltípuson, aminek keresésből kell forgalmat hoznia.
A navigáció és a listák linkjei valódi hivatkozások legyenek címmel, ne kattintás-kezelők.
A lapozás működjön JavaScript nélkül is, akkor is, ha a fő felhasználói élmény a görgetés.
A robots fájl ne tiltsa a szkript- és stílusfájlokat.
Minden cím saját, különböző nyers HTML-t adjon vissza, ne ugyanazt a vázat.
A kanonikus jelölés a kiszolgált HTML-ben legyen, ne futás közben kerüljön bele.

Ez a hat pont beilleszthető egy átvételi ellenőrzőlistába, és ellenőrizhető anélkül, hogy bárkinek SEO-tudása lenne: elég kikapcsolni a JavaScriptet, és végignézni.

Mikor kerül ez szóba a projektben

A helyes időpont a tervezés, nem az átadás. Ha a kérdés az élesítés előtti héten merül fel, akkor már csak kompromisszumok vannak. A leggyakoribb ilyen kompromisszum egy utólagos megoldás, ami a botoknak külön kiszolgált változatot ad. Ez működhet, de bonyolult, plusz karbantartást igényel, és hibázni is könnyebb vele.

A megjelenítés és a sebesség kapcsolata

A két téma összefügg, de nem ugyanaz, és a keverésük sok felesleges munkát okoz. A sebesség arról szól, milyen gyorsan használható az oldal a látogatónak. A megjelenítés arról, hogy a kereső egyáltalán látja-e a tartalmat.

Egy oldal lehet lassú, de tökéletesen látható, ha a tartalom a nyers HTML-ben van. És lehet villámgyors, mégis láthatatlan, ha minden JavaScriptből jön. A két problémát külön kell kezelni, és a láthatóság az előbbre való: a lassú, de indexelt oldal hoz forgalmat, a gyors, de nem indexelt nem hoz semmit.

Ami mégis közös bennük: a kiszolgálóoldali megjelenítés általában mindkettőn javít, mert a látogató is hamarabb lát tartalmat, és a kereső is. Ezért éri meg a legtöbb helyzetben.

Amit NEM kell megoldani

A megjelenítés körül sok felesleges aggodalom kering. Négy dolog, ami miatt nem érdemes dolgozni:

A bejelentkezés mögötti felület. Azt nem is akarod indexelni.
Interaktív elemek, mint kalkulátorok és szűrők, ha a lényegi tartalom mellettük van a HTML-ben.
Analitikai és egyéb követő szkriptek. Ezek nem befolyásolják, hogy a kereső mit lát a tartalomból.
A betöltés utáni apró módosítások, például egy sáv megjelenítése, ha a fő tartalom már ott van.

Döntési szabály ehhez: ha a kikapcsolt JavaScriptes nézetben megvan minden, ami keresésből forgalmat hozhat, akkor a maradék JavaScript szabadon használható.

Egy figyelmeztetés a mérésekhez

A sebességmérő eszközök egy része a megjelenített oldalt vizsgálja, tehát ugyanazt látja, amit a böngésződ. Ezért egy ilyen eszköz jó pontszáma nem bizonyítja, hogy a kereső is látja a tartalmat. A két kérdésre két külön mérés való, és ezt a legkönnyebb összekeverni.

A gyakorlatban ez a sorrend működik: előbb a kikapcsolt JavaScriptes nézet, aztán a keresőkonzol megjelenített kódja, és csak a végén a sebességmérés. Fordított sorrendben könnyű órákat elkölteni egy pontszám javítására, miközben a tartalom továbbra sem látszik.

Ez a három lépés együtt nagyjából tíz perc, és egy bevezetés napján kötelező körnek érdemes tekinteni, nem alkalmi ellenőrzésnek.

Kapcsolódó részletes útmutatók

A bejárás útmutatója arról szól, hogyan jut el a bot az oldalhoz, a keresőmotorok útmutatója a teljes négy szakaszt mutatja be, a Googlebot útmutatója pedig a konkrét bot viselkedését. A megjelenítés ezek közé ékelődik: akkor kerül sorra, amikor a letöltés már megtörtént, de az indexelés még nem.