Tady je hned několik kroků, které byste měli zvážit, když začnete migraci webových stránek vytvořených se statickou HTML do rámce JavaScriptu.
 
Během poklesu organického provozu o osmdesát procent se každá stránka ocitá ve zlé noční můře a byznysmeni skáčou z oken. Naneštěstí se tento až hororový scénář může velmi lehce stát realitou, pokud migrace vaší webové stránky selže a je provedena špatně – namísto zlepšení stávající situace se vám eventuálně dostane jenom jedné velké katastrofy, ze které se jen tak nevymaníte a bude trvat dlouho, než se vůbec z díry, kterou jste si vykopali (nebo vám ji někdo vykopal), dostanete.

 
Existuje spousta různých typů a druhů migrací, jako je změna, splynutí nebo rozdělení domén, redesign webové stránky nebo přesunutí do úplně nového rámce.
 
Trendy vývojářství webových stránek nám jasně ukazují, že použití JavaScriptu se stává čím dál rozšířenější a během několika let se staly JAvasScriptové rámce pro tvorbu webových stránek více a více populární. V budoucnosti můžeme čekat takové scénáře, kde více a více webových stránek bude používat JavaScript a na statické HTML se úplně zapomene.

 
V tomto článku se vám pokusíme ukázat několik kroků, jak se vlastně připravit na migraci vaší webové stránky, která je vytvořená se statickou HTML do rámce JavaScriptu.
 

Internetové vyhledávače vs. JavaScript

Google je jediným internetovým vyhledávačem, který je schopen provést JavaScript a vidět jisté elementy jako je obsah nebo navigace, i když jsou poháněny JAvaScriptem. Avšak i přesto zde existují dvě věci, na které si vždycky budete muset dávat pozor a budete si je muset pamatovat, pokud budete někdy rozmýšlet změnu či migraci na JS rámec.
 
Předně bychom měli zmínit, že Google používá Chrome 41 pro vykreslování stránek. Tohle je asi tři roky starý prohlížeč, který ještě nepodporuje všechny moderní funkce potřebné pro vykreslení pokročilých funkcí. I kdyby mohly vykreslit JV webové stránky obecně, může se stát, že některé důležité části zůstanou neobjevené díky přílišnému spoléhání se na technologii, kterou Google nedokáže nějak zpracovat.
 
Zadruhé spouštění JS je extrémně těžký proces, dokonce tak těžký, že Google indexuje JS webové stránky ve dvou různých vlnách. První vlna získá samotné HTML, které je následně indexováno. V případě webových stránek běžících na JS je výsledek první vlny tak maximálně prázdná stránka. Během druhé vlny, Google spustí JavaScript, aby mohli vidět další elementy načtené JS. Až poté jsou připraveni indexovat úplný obsah stránky.
 
Kombinace těchto dvou elementů dělá to, že pokud se rozhodnete změnit vaši stávající webovou stránku a budete jí chtít migrovat do JS rámce, musíte vždycky zkontrolovat, jesti Google může efektivně procházet a indexovat takovou vaši novou stránku.
 

Dobře zvládnutá migrace do rámce JS

SEO společnostem se sice JS líbit nemusí, avšak to nic nemění na tom, že jeho popularita bude neustále růst. Měli bychom se tedy pořádně připravit, jak jen můžeme a implementovat tento moderní rámec správně.
 
Níže najdete informace, které vám pomohou navigovat se skrze celý proces změny stávajícího rámce. Určitě vám tady nedáváme „ready-to-go“ řešení a návody, protože vaše situace může být výsledkem rozdílných a naprosto jiných faktorů a určitě neexistuje na tyto případy nějaký univerzální návod. Každopádně bychom chtěli zdůraznit ty elementy, kterým byste měli věnovat velkou pozornost.
 

Nejdříve pokryjeme základy standardní migrace

Nemůžete počítat s nějakým zázrakem, že Google pochopí změny bez vaší pomoci. Celý proces migrace by měl být naplánovaný do nejmenšího detailu.
 
Chtěli bychom se zaměřit především na migraci JS v tomto článku, ale pokud budete chtít detailnější průvodce migrací, Bastian Grimm již toto téma dostatečně pokryl.

(John: Je tu spousta věcí, na které si musíte dát pozor, co se týče migrací stránek. Dali jste hodně času do vytváření stránky, tak musíte dát hodně času do migrace, abyste to všechno udělali správně. Stáhněte si tento úžasný návod, vytiskněte si ho, uložte si ho na potom, a určitě si dávejte pozor na detaily.
 

Musíte chápat vaše potřeby, co se týče servírování obsahu pro Google

S tímto krokem byste měli být hotoví ještě předtím, než uděláte cokoliv jiného. Potřebujete se rozhodnout, jak vlastně Google v budoucnosti uvidí obsah na vaší stránce. Máte dvě možnosti:

1. Vykreslování na straně klienta: to znamená, že budete naprosto spoléhat na Google ve vykreslování. Každopádně, pokud se rozhodnete pro tuhle možnost, musíte také vzít nějaká rizika toho, že to nebude příliš efektivní. Prvním důležitým následkem tohoto řešení je odložené indexování vašeho obsahu kvůli dvěma vlnám indexování, které jsme zmínili výše. Zadruhé, může se stát, že ne všechno bude fungovat tak, jak by mělo, protože Chrome 41 nepodporuje všechny moderní funkce. A konečně, ne však na posledním místě, ne všechny internetové vyhledávače mohou spustit JavaScript, takže vaše JS webová stránka se může zdát prázdná Bingu, Twitteru nebo Facebooku.

1. Vykreslování ze strany serveru: toto řešení spoléhá především na vykreslování nějakým externím mechanismem nebo dodatečným mechanismem / komponentem, který bude odpovědný za vykreslování vaší JS webové stránky, vytvářením statických snímků a servírováním je procházečům internetových vyhledávačů. Na konferenci Google I/O, Google oznámil, že nabízení oddělené verze vaší stránky procházečům je naprosto v pohodě. Tohle je tzv. dynamické vykreslování, což znamená, že nyní můžete detekovat agenta uživatele procházeče a poslat mu serverem vykreslenou verzi. Toto řešení má ale také několik nevýhod: vytvoření a udržování další infrastruktury, pravděpodobné zdržení, pokud bude velmi těžká stránka vykreslována na serveru nebo možné problémy s cachingem (GoogleBot může dostat ne-čerstvou verzi vaší stránky).

 
Pokud bude úspěch vašeho podnikání postaven okolo čerstvého obsahu (novinky, zprávy, reality, nabídky, kupóny), nemůžeme si představit, že byste se spoléhali jenom na verze vykreslené na straně klienta. Může to vyústit ve velmi dramatické zdržení v indexování, takže vaši konkurenti mohou získat výhodu na trhu.
 
Pokud ale máte malou webovou stránku a obsah na ní není aktualizován tak často, můžete to zkusit nechat na vykreslení na straně klienta, ale měli byste to otestovat ještě předtím, než spustíte stránku, jestli Google skutečně vidí obsah a navigaci. Nejužitečnějším nástrojem pro takové testování je Fetch jako Google v Google Search Console nebo také Chrome 41 prohlížeč.
 
Ale Google oficiálně oznámil, že je lepší používat dynamické vykreslování, abyste se ujistili, že objeví neustále nebo často se měnící obsah správně a rychle.
 

Rámec vs. řešení

Pokud vaše volba byla použití dynamického vykreslování, je čas na to odpovědět na otázku, jak vlastně bude obsah nabízen procházečům. Na tohle není žádná univerzální odpověď. Obecně řešení spoléhá na technologii A vývojáře A rozpočet A také vaše potřeby.
 
Níže najdete recenzi některých možností, které jsou dostupné hned z několika různých přístupů k nim, ale volba je stále jenom na vás:

• Potřebuji to nejjednodušší řešení, co to jde

Pravděpodobně bychom šli do pre-vykreslování, například s prerender.io. Je to externí zařízení, které projde vaší stránku, vykreslí vaše stránky a vytvoří statické snímky, které poté nabídne, pokud si o to nějaký procházeč zažádá. Velkou výhodou tohoto řešení je ten fakt, že nepotřebujete vytvářet vaši vlastní infrastrukturu.
 
Můžete si dokonce naplánovat opětovné procházení a vytvořit čerstvé snímky vaší stránky. Ale pro větší a častěji měnící se stránky to může být značně těžší, abyste se ujistili, že všechny stránky jsou skutečně načteny na čas a ukazují přesně ten samý obsah jak pro GOogleBota, tak pro uživatele.
 

• Potřebuji univerzální řešení a chci následovat trendy

Pokud tvoříte stránku s nějakým populárním rámcem jako je React, Vue, Angular, můžete použít také jednu z metod vykreslování na straně serveru, která je dedikovaná danému rámci. Tady je hned několik populárních shod:

• Angular Universal je řešení pro Angular
• Nuxt.js jde dobře s Vue.js
• React je podporován Next.js

 
Použiváním jednoho z těchto rámců instalovaných navrch na React or Vue bude ve výsledku vytvářet univerzální aplikace, což znamená, že určitý kód bude proveden jak na serveru (vykreslování na straně serveru) a také na straně klienta (vykreslování na straně klienta). Minimalizuje to problém s chybějícím obsahem, který byste mohli mít, pokud byste se spoléhali na vytváření snímků a těžkém cachingu, tak jako to je s pre-vykreslováním.
 

• Potřebuji univerzální řešení a nechci používat žádné populární rámce

 
Může se stát, že chcete používat rámec, který ještě nemá ready-to-use řešení pro vytváření univerzální aplikace. V tomto případě můžete jít budovat vaši infrastrukturu pro vykreslování. Což znamená, že můžete instalovat headless prohlížeč na vašem serveru, který bude vykreslovat všechny substránky na vaší webové stránce a vytvářet snímky, které budou nabízeny procházečům internetových vyhledávačů. Google poskytuje dokonce i řešení – Puppeteer je knihovna, která má podobnou funkci jako prender.io. Ale všechno se děje na vaší infrastruktuře.
 

• Chci dlouhotrvající řešení

Pro tento přístup bychom použili hybridní vykreslování. Je známo, že toto řešení poskytuje nejlepší zkušenost jak pro uživatele, tak pro procházeče, protože oba dva dostávají vykreslenou verzi stránky na straně serveru hned na první požádání. Ve spoustě případů, nabízení SSR stránky je rychlejší pro uživatele, než spouštění všech těžkých souborů v prohlížeči. A všechny následující interakce uživatele jsou v rámci JavaScriptu. Procházeče nijak neinteragují s webovou stránkou klikáním nebo posouváním kolečkem myši, takže to bude vždycky nový požadavek pro server a oni vždycky dostanou SSR verzi. Zní to dobře, ale není to tak úplně lehké na implementaci.

Tato možnost, kterou byste si mohli zvolit, záleží na spoustě faktorů, jako je technologie, vývojáři a také rozpočet. V některých případech můžete mít ještě méně možností, ale zase na druhou stranu, pro většinu případů platí, že můžete mít spoustu omezení, takže vybrání řešení může být jednoduché, neboť vám zbyde jenom jediná možnost.
 

Testování implementace

Neumíme si představit migraci, aniž bychom vytvořili nějaké falešné prostředí a otestovali, jak se všechno podaří. Migrace do JavaScriptu přidává trošku více komplexnosti a další pasti, na které si musíte dávat pozor.
 
Jsou zde pouze dva scénáře. Pokud jste se z nějakého důvodu rozhodli spoléhat se na vykreslování na straně klienta, potřebujete si nainstalovat Chrome 41 a zkontrolovat, jak vykresluje a pracuje. Snad nejdůležitější krok vůbec je audit kontroly chyb v konzoli v Chrome Dev tools. Zapamatujte si, že i malá chybka může v procesu JavaScriptu způsobit pořádný problém s vykreslením.
 
Pokud jste se rozhodli použít jednu z metod nabízení obsahu procházeči, budete potřebovat nějakou cvičnou stránku, kde je toto řešení nainstalováno. Níže jsme vám podtrhli hned několik důležitých elementů, které by měly být vždy zkontrolovány ještě předtím, než se na všechno pustíte naživo.
 

1. Parita obsahu

Měli byste vždycky zkontrolovat, jestli uživatelé a procházeči vidí přesně ten samý obsah. Abyste tak učinili, potřebujete změnit agenta uživatele v prohlížeči, abyste mohli vidět verzi, která je posílaná procházečům. Měli byste také ověřit obecné nerovnoměrnosti, které se týkají vykreslování. Ale abyste mohli vidět celý obrázek, budete také potřebovat zkontrolovat DOM (Document Object Model) vaší webové stránky. Zkopírujte zdrojový kód z vašeho prohlížeče, změňte User Agent na GoogleBota a vezměte taky zdrojový kód. Diffchecker vám pomůže vidět některé rozdíly mezi těmito dvěma soubory. Měli byste se zvláště dívat na různé rozdíly v obsahu, navigaci a metadatech.
 
Extrémní situace je taková, kdy vám někdo pošle prázdnou HTML složku do GoogleBota, stejně jako Disqus.
 

1. Navigace a hyperodkazy

Abyste si byli stoprocentně jisti, že Google vidí, prochází a předává šťávu z odkazů, měli byste následovat jasné doporučení implementace vnitřních odkazů, které byly se všemi sdílené na Google I/O konferenci v roce 2018.
 
Pokud spoléháte na vykreslování na straně serveru a jeho metody, potřebujete zkontrolovat, jestli HTML vykreslené verze stránky obsahuje všechny odkazy, které byste tam čekali. Jinými slovy, pokud má tu samou navigaci jako vaše verze vykreslená na straně klienta. Jinak Google neuvidí interní odkazy mezi jednotlivými stránkami. Kritické oblasti mohou mít problémy jako je facet navigace, paginace a hlavní menu.
 

1. Metadata

Metadata by neměla být příliš závislá na JS. Google zdůraznil, že pokud načtete kanonický tag s JAvaScriptem, tak pravděpodobně neuvidí tento tag ve své první vlně indexování a určitě to nebudou podruhé kontrolovat v druhé vlně. Výsledkem může být to, že kanonické signály mohou být úplně ignorovány.
 
Zatímco testujete na pokusné stránce, vždycky zkontrolujte, jestli má SSR verze kanonický tag v přední sekci. Pokud ano, tak potvrďte kanonický tag jako ten správný. Pravidlo palce neustále posílá konzistentní signály internetovým prohlížečům, ať už používáte klientské či serverové vykreslování.
 
Zatímco kontrolujete webovou stránku, vždycky ověřujte, jestli CSR i SSR verze mají ty samé tituly, popisky a instrukce pro robota.
 

1. Strukturovaná data

Strukturovaná data pomáhají internetovým vyhledávačům lépe pochopit obsah vaší stránky.
 
Ještě předtím, než spustítě novou stránku, ujistěte se, že SSR verze vaší webové stránky zobrazuje všechny elementy, které chcete označit jako strukturovaná data a pokud jsou markupy zahrnuty v pre-vykreslovací verzi. Například pokud chcete přidat markupy do drobečkové navigace. V prvním kroce zkontrolujte, že jsou drobečky zobrazeny v SSR verzi. Ve druhém kroce spusťte test v Rich Results Testeru, abyste viděli, jestli jsou markupy správné.
 

1. Líné načítání

Naše pozorování ukazují, že moderní stránky milují načítání obrázků a obsahu (produktů) s líným načítáním. Přídavným elementem jsou „načteny při zobrazení na displeji“. Možná to může být velmi pěkná funkce pro uživatele, pro GOogleBota, která ale neumí zrovna posouvat kolečko myši, to zrovna sranda není, takže jako následek toho tyto jednotlivé věci nebudou objeveny.
 
Vidíme, že spousta správců webu má problémy s líným načítáním v docela SEO-přátelském způsobu, proto Google publikoval návod pro ty nejlepší praktiky líného načítání. Pokud chcete načítat obrázky, zatímco posouváte stránku kolečkem myši, ujistěte se, že podporujete paginované načítání. To znamená, že vždycky když posunete stránku dolů, URL by se měla změnit (například přidáním paginačních identifikátorů: ?page=2, ?page=3 atd.) a co je nejdůležitější, URL by se měla aktualizovat se správným obsahem, například za použití Historie API.
 
Určitě nezapomeňte přidat rel=“next“ markupy do čelní sekce, abyste indikovali sekvenci stránek.
 

Snímková generace a nastavení cache

Pokud jste se rozhodli vytvářet snímky pro procházeče internetových vyhledávačů, potřebujete monitorovat další věci.
 
Musíte vždycky kontrolovat, jestli snímek je přesnou kopií klientsky vykreslené verze stránky. Nemůžete načítat další obsah nebo odkazy, které nejsou viditelné standartnímu uživateli, protože by to mohlo být považováno za cloaking. Pokud proces vytváření snímků není efektivní, například vaše stránky jsou velmi těžké a váš server není tak rychlý, může to vyústit ve tvorbu špatných snímků. A jako výsledek budete dávat procházečům částečně vykreslené stránky.
 
Existují některé situace, kde vykreslovací infrastruktura musí fungovat ve vysoké rychlosti, jako je Black Friday, kdy chcete aktualizovat ceny velmi rychle. Měli byste testovat vykreslení v extrémních podmínkách, kde byste měli vidět, kolik času zabere aktualizace určitého čísla stránek.
 
Poslední věcí je caching. Nastavení cache správně je něco, co vám může pomoci udržet efektivitu, protože spousta stránek může být rychle nabízena přímo z paměti. Ale pokud neplánujete caching správně, Google může dostávat ustálený obsah.
 

Monitorování

Pozorování post-migrace je pouze přirozený krok. Ale v některých případech migrací na JS rámec se může při samotné migraci objevit věc, kterou bychom měli pozorovat a optimalizovat.
 
Přesun na JS rámec může ovlivnit výkon webové stránky. Ve spoustě případů datové části narůstají, což může vyústit v daleko delší dobu načítání, hlavně pro mobilní uživatele. Velmi dobrým způsobem je monitorování toho, jak vaši uživatele vnímají výkon vaší stránky a porovnávání těchto dat před a po migraci. Abyste tak učinili, používejte Chrome User Experience Report.

Poskytne vám to informaci, jestli se metrika skutečného uživatele nějak změnila za určitý časový úsek. Měli byste vždycky mířit k vylepšení a načítání stránky jak jen to nejrychleji půjde.
 

Závěr

Migrace jsou vždycky riskantní proces a nikdy si nemůžete být jisti výsledky. Rizika mohou být alespoň zmírněna tím, že budete plánovat všechno dopředu a velmi detailně. V případě všech typů migrací, plánování je stejně tak důležité jako samotné provedení. Pokud hrajete nějakou roli v migraci na JS rámec, potřebujete se zabývat ještě další komplexností. Musíte dělat více rozhodnutí a musíte ověřovat daleko více věcí. Ale jak trendy vývoje stránek míří k samotnému užívání JAvaScriptu více a více, měli byste být dříve nebo později připraveni na to, že budete muset čelit JS Migraci. Tak hodně štěstí!