JavaScript SEO: zajistěte, aby odkazy přežily vykreslení

Google vykresluje JavaScript pomocí aktuálního Chromium. Problém obvykle nespočívá ve vykreslování samotném. Jde o odkazy, které nikdy nebudou kotvami, a stránky, které závisí na stavu, který crawler nemá.

Výzkumný tým ArchiLinks · Aktualizováno 2026-10-29

Most spojující kamenné základy se skleněnými strukturami reprezentující přežití odkazů

Co crawler vidí

Googlebot používá aktuální Chromium od května 2019. Tím vyřešil otázku, zda dokáže spustit moderní JavaScript.

Praktická rizika jsou starší: vykreslování probíhá po crawlování a může být zpožděno, obsah za kliknutím nebo přihlášením se nikdy neobjeví a odkaz vytvořený z obslužné rutiny onclick na divu není odkazem. Předtím, než zkontrolujete zpětné odkazy na stránkách webu, které jste nedávno přesunuli na React, ověřte, zda tyto stránky zobrazují svůj obsah v surové odpovědi nebo ve vykresleném HTML.

SSR, SSG, CSR: co se mění pro odkazy

Přístup	Obsah v první odpovědi	Interní odkazy jako kotvy	Vhodné pro
SSR (Next.js, Nuxt)	Ano	Ano, pokud používáte skutečné kotvy	Veřejné stránky s měnícími se daty
SSG nebo prerenderování	Ano	Ano	Dokumentace, blogy, marketingové stránky
CSR single-page aplikace	Ne, prázdná skořápka	Pouze po vykreslení	Dashboardy za přihlášením
Hybridní (SSR domovská stránka, CSR aplikace)	Podle trasy	Podle trasy	Většina produktů s veřejnou částí

Test 1: surové HTML versus vykreslené HTML

Pokud se klíčové odkazy objeví v první odpovědi, otázka je vyřešena. Pokud ne, porovnejte s headless vykreslením.

bash

# raw response: are the links there?
curl -s https://new-shop.com/guides/ | grep -o '<a [^>]*href="[^"]*"' | head -20

# rendered DOM with headless Chrome
chrome --headless --dump-dom https://new-shop.com/guides/ | grep -c '<a '

Zahradník kontrolující kořeny stromů reprezentující kontroly zdraví externích zpětných odkazů

Kde přicházejí externí odkazy

Chyba při vykreslování skryje váš obsah. Nemazává však odkazy, které vám již jiné stránky poskytly.

Po přesunu na Next.js, Vite nebo headless CMS spusťte toppages pro hostitele a otestujte 20 nejvíce odkazovaných URL na status, kanonickou adresu a viditelný obsah. Udělejte to jako první. Pokud stránka s 40 odkazujícími doménami vrací prázdnou skořápku nebo klientskou chybu 404, opravte ji před vším ostatním, protože tam dopadá vaše autorita. Stránka interní versus externí hodnota odkazů ukazuje, jak porovnat tento seznam s vašimi interními odkazy, a kontrolní seznam migrace zařadí test do plánu nasazení.

Rámce jsou méně důležité než disciplína. Express s šablonovacím engine, WordPress téma a Next.js app router mohou všechny poskytovat indexovatelné odkazy. Každý z nich také může selhat, pokud tým nasadí kotvy, které existují pouze po kliknutí.

Kontrolní seznam odkazů a vykreslování

Navigace a paginace používají <a href>, nikoliv obslužné rutiny kliknutí na jiné prvky.
Každá trasa vrací skutečný stavový kód. Měkké chyby 404 musí vracet 404.
Atributy noindex nebo kanonická URL vložená JavaScriptem odpovídají těm v odpovědi serveru.
Obsah náhradního řešení v první odpovědi je skutečná stránka, ne spinner, který by Google mohl indexovat.
Autentizační kód nepřesměrovává crawler na veřejných trasách.
Soubory CSS a JS potřebné pro vykreslení nejsou v robots.txt zablokované.
Líné načítání používá IntersectionObserver nebo nativní atributy načítání, nikoliv události posuvu.

Čtení důkazů z Search Console

Search Console odpoví na většinu otázek o vykreslování, pokud položíte správnou otázku. Použijte Inspektor URL, pak Zobrazit zcrawlovanou stránku.

Porovnejte tři věci: HTML, které Google stáhl, snímek obrazovky a zdroje stránky, které se nepodařilo načíst. Stránka, která vypadá kompletně ve vašem prohlížeči, ale je prázdná na snímku, je obvykle zablokovaná chybou skriptu nebo zakázaným zdrojem a řešení spočívá ve vašem buildu, ne v obsahu.

Pamatujte na zpoždění. Změnu, kterou dnes nasadíte, uvidíte v nástroji pro inspekci až po tom, co Google znovu zcrawluje URL, což může trvat dny.

Kdy se vyplatí SSR

Veřejné stránky, které musí cílit na organický traffic: ano. Dashboardy: ne.

Pokud trasa má přivádět organický traffic, poskytněte obsah v první odpovědi. Pokud je za přihlášením, vynechte složitost. Volte přístup podle trasy, ne podle projektu, a rozhodnutí zdokumentujte, aby ho další vývojář nevrátil zpět.

Použijte test Rich Results a URL Inspection pro porovnání vykresleného výstupu.
Testujte pomocí živého testu ve Search Console po každé aktualizaci frameworku.

Dva domy na kopci ukazující prerenderování versus klientské vykreslování

Je nutné serverové vykreslování, nebo stačí prerenderování?

Serverové vykreslování je volitelné. Je to způsob, jak zajistit, aby první odpověď obsahovala to, co crawler potřebuje. Mnoho veřejných stránek toho dosáhne prerenderováním, statickým buildem nebo serverovým vykreslením pro ty stránky, které mají význam, a ponechá přihlášené části stranou.

Řekněme, že vaše produktové stránky a dokumentace jsou veřejné, zatímco dashboard je za přihlášením. Prerenderujte první skupinu. Dashboard ponechte na klientské straně. Veřejné stránky tak v první odpovědi přinesou své odkazy a dashboard může zůstat tak složitý, jak potřebuje.

Prerenderování pouze domovské stránky

Prerenderování domovské stránky vyřeší první crawl, ale každá další trasa bude čekat na prohlížeč. Pokud domovská stránka odkazuje na klientsky vykreslované kategoriové stránky, odkazy na těchto stránkách stále závisí na vykreslení. Zkontrolujte každou šablonu, kterou vlastníte, nejen vstupní bránu.

Udržujte krátký seznam veřejných tras s jejich metodou vykreslování. Seznam odhalí mezery rychleji než report z crawlu.

Změní serverové vykreslování lokální viditelnost?

Serverové vykreslování může změnit rychlost, jakou se objeví první obsah, a čtenáři to poznají. Samotné to však nedělá stránku relevantní pro lokální dotaz. Tyto signály pocházejí z obsahu stránky, detailů firmy a odkazů, které na ni směřují.

Považujte vykreslování za způsob, jakým se tyto signály stanou čitelnými pro crawler, a měřte odkazy samostatně pomocí API.

Aplikace Vite a React, které poskytují jednu skořápku

Build Vite, který poskytuje jednu HTML skořápku pro každou cestu, přenese veškerou práci na klienta. Taková aplikace může stále cílit na některé dotazy, ale každá veřejná trasa potřebuje plán: prerenderujte ji, vykreslete na serveru nebo přijměte ztrátu a zapište si to.

Předtím, než zkontrolujete zpětné odkazy na trasách webu po rebuildu, rozhodněte se, jak každá veřejná trasa získá svůj obsah. Jinak data o odkazech ukážou externí odkazy směřující na stránky bez obsahu.

Testování, zda trasa zobrazuje své odkazy

Dva testy odpoví na většinu otázek. Surová odpověď ukazuje, co crawler dostane před spuštěním jakéhokoliv skriptu. Vykreslený DOM ukazuje, co prohlížeč následně sestaví. Odkaz, který se objeví pouze ve druhém případě, je stále odkaz, ale závisí na tom, že vykreslení proběhne dobře.

Čtení živého testu ve Search Console

Spusťte živý test z Inspektoru URL pro jednu trasu najednou. Podívejte se na vykreslené HTML, pak na seznam zdrojů, které se nepodařilo načíst. Zablokovaný skript může odstranit celý blok navigace a stránka bude vypadat tenká bez zobrazení jakékoliv viditelné chyby.

Zopakujte test po aktualizaci frameworku, protože nový výchozí stav může změnit, zda se odkazy vykreslí před nebo po spuštění skriptu. Průvodce stránky neindexované pokrývá, co dělat, když se vykreslená stránka stále neindexuje.

Kdy se trasa vykreslí, ale obsahem je spinner

Náhradní obsah v první odpovědi je důležitější, než si většina týmů myslí. Spinner nebo prázdný kontejner znamená, že stránka v daném okamžiku nemá pro crawler žádný text. Do první odpovědi dejte název, úvod a hlavní odkazy, i když se podrobný seznam načte později.

Náhradní řešení, které je skutečnou stránkou, může zůstat jednoduché. Jeho jediným úkolem je udržet obsah, dokud zbytek nedorazí.

Přesun klientského webu bez ztráty odkazů

Vypište trasy s externími odkazy

Spusťte toppages pro hostitele a poznamenejte si top 50 URL. Otestujte tyto trasy jako první, před změnami kódu, abyste věděli, co rebuild musí zachovat.

Porovnejte surový a vykreslený výstup

Pro každou trasu zkontrolujte surové HTML a vykreslený DOM ve starém i novém buildu. Poznamenejte si jakýkoliv odkaz, který existuje v jednom, ale ne v druhém.

Nahraďte obslužné rutiny kliknutí kotvami

Přeměňte navigaci na skutečné kotvy s příslušnou adresou. Optimalizace rychlosti může počkat na sprint, zatímco chybějící kotva stojí trasu její cestu do webu.

Zopakujte test po vydání

Týden po vydání spusťte živý test na stejných trasách a porovnejte výsledky s těmi předchozími. Rozdíly ukážou, kde rebuild změnil výstup.

Stavové kódy a přesměrování v klientské aplikaci

Single-page aplikace často zobrazí obrazovku „nenalezeno“, zatímco server vrací status 200. Google může takovou stránku považovat za měkkou 404 a externí odkazy směřující na chybějící URL vám pak moc nepomohou. Řešení patří na server.

Neznámé trasy, které stále vrací 200

Vraťte skutečnou 404 ze serveru pro jakoukoliv trasu, která neexistuje, a ponechte obrazovku „nenalezeno“ v aplikaci pro návštěvníky, kteří dorazí po klientské trase. Kde existuje náhrada, pošlete místo toho 301.

Po každém vydání zkontrolujte několik smyšlených adres na živém hostiteli. Čtěte stavový kód, ne stránku, kterou vidíte v prohlížeči.

Přesměrování, která běží v prohlížeči

Přesměrování, které se spustí po načtení stránky, například čtením parametru URL uvnitř komponenty, je něco jiného než serverové přesměrování. Crawler může indexovat první odpověď předtím, než přesměrování proběhne. Kde se trasa trvale přesunula, vraťte 301 ze serveru a zachovejte parametry, které mění obsah. Recept na mapu přesměrování ukazuje, jak tyto pravidla otestovat.