Mobile-first indexing

Mobile-first indexing není novinka — Google s ním začal už v roce 2016 a v roce 2024 přepnul i poslední weby. V roce 2026 to ale znamená jednu nepříjemnou věc: pokud má vaše mobilní verze méně obsahu než desktopová, Google s ní pracuje, jako by ten zbylý obsah neexistoval. A platí to i pro rankování v desktopových výsledcích.

V tomto článku se dozvíte, co mobile-first indexing v roce 2026 reálně znamená, jaké chyby srážejí weby v rankingu nejčastěji a jaký konkrétní postup vám zajistí, že Googlebot Smartphone uvidí celý váš obsah.

Co je mobile-first indexing a proč na něm v roce 2026 záleží

Mobile-first indexing je princip, kdy Google používá mobilní verzi vašeho webu jako primární zdroj pro indexaci a rankování. Crawler Googlebot Smartphone procházejí stránky tak, jak by je viděl uživatel na telefonu, a obsah z této verze pak rozhoduje o pozicích ve vyhledávání — i když výsledky nakonec ukazuje uživateli na desktopu.

Důvod je čistě praktický. V prvním kvartálu 2026 tvořilo mobilní zařízení podle StatCounteru 52,27 % globálního webového provozu, podle dalších měření (mid-2026) až 62–64 %. V některých regionech, jako Afrika nebo Asie, je mobilní podíl přes 70 %. Google jednoduše indexuje to, jak většina lidí web reálně používá.

V říjnu 2023 Google oznámil, že přechod na mobile-first indexing je u funkčních webů hotový. V červenci 2024 přestal v Search Console zobrazovat informaci o tom, jakým crawlerem byl web procházen — protože všechny weby jsou už crawlovány mobilním botem. Desktopový crawler Google používá jen u úzkého výběru webů, které na mobilu nefungují vůbec, a postupně i tato množina mizí.

Mobile-friendly vs. mobile-first: zásadní rozdíl

Tyto pojmy se často zaměňují, ale neznamenají totéž.

• Mobile-friendly znamená, že web vypadá a funguje na telefonu (čitelný text, velké tlačítka, žádné horizontální scrollování).
• Mobile-first indexing jde o krok dál — Google ignoruje vaši desktopovou verzi a hodnotí web pouze podle toho, co najde na mobilu.

Praktický důsledek: i krásně udělaný responzivní web může v rankingu propadnout, pokud má v mobilní verzi schované klíčové informace, blokované zdroje nebo chybějící strukturovaná data.

Jak Googlebot Smartphone reálně vidí váš web

Googlebot Smartphone není „prohlížeč na telefonu se zmenšeným rozlišením“. Jde o headless Chromium, který simuluje mobilní zařízení (typicky Pixel) a běží v omezeném výpočetním prostředí. To má dva důsledky, které spousta webů podceňuje.

Render Budget: Google nečeká na váš JavaScript navždy

Renderování JavaScriptu je pro Google podle veřejných odhadů zhruba 20× dražší než klasický textový crawl. Proto má každá stránka „compute budget“ — pokud váš web musí stáhnout megabajty skriptů a teprve pak vyrenderovat hlavní obsah, bot může „odejít“ dřív, než se obsah objeví v DOM.

Výsledek? Stránka se sice zaindexuje, ale bez klíčových sémantických prvků. Google ji prostě nezná tak dobře, jak si myslíte. Řešení leží v server-side renderingu (SSR) nebo prerenderingu — chcete, aby HTML s hlavním obsahem dorazilo crawleru hned, ne až po hydrationu na klientu.

Mobilní viewport a responzivní breakpointy

Bot simuluje úzký mobilní viewport (~360 × 800 px). Pokud váš responzivní design v tomto rozlišení skrývá části textu, navigaci nebo schovává recenze do tabů s lazy-loadem na klik, Google to nezaindexuje.

Content parity: pravidlo číslo jedna pro mobile-first indexing

Content parity znamená, že mobilní a desktopová verze obsahují identický obsah — stejný text, obrázky, video, interní odkazy, metadata i strukturovaná data. Vizuální prezentace se může lišit, obsah ne. Toto je oficiální doporučení Googlu, ne něčí teorie.

Google dokumentace k tomu uvádí jasně: pokud má mobilní verze méně obsahu než desktopová, je to ten mobilní, kdo se zaindexuje a pošle do rankingu. Ten zbylý desktopový obsah Google v praxi ignoruje.

Co konkrétně musí být na mobilu shodné s desktopem

• Hlavní textový obsah — všechny odstavce, popisy, nadpisy, CTA texty
• Strukturovaná data (schema markup) — Article, Product, Review, FAQPage, LocalBusiness, jakékoli, která máte
• Meta tagy — title, description, robots, Open Graph, Twitter Cards
• Hierarchie nadpisů — H1, H2, H3 musejí být na mobilu stejné jako na desktopu
• Interní odkazy — navigace, související články, breadcrumbs, footer odkazy
• Obrázky a alt texty — stejné obrázky, stejný alt text (obrázky můžou být v mobilní verzi přizpůsobené velikostí, ale ne počtem nebo informacemi)

Akordeony, taby a „Read more“: jak to dělat správně

Dobrá zpráva: Google v roce 2026 chápe běžné UI patterny. Pokud máte text v akordeonu, tabu nebo expandable sekci, ale celý je v iniciálním HTML, crawler ho přečte a zaindexuje, i když je vizuálně skrytý. Display: none nebo CSS toggle jsou v pořádku.

Špatná zpráva: pokud se obsah načítá až po kliknutí na „Načíst více“ přes JavaScript, který musí udělat fetch, Google ho s vysokou pravděpodobností nezaindexuje. Nemůže ten event simulovat. Stejný problém má lazy-loading hlavního obsahu závislý na scrollu nebo touchi.

Praktický fix: pro skládací sekce používejte sémantické HTML5 tagy <details> a <summary> místo JavaScriptových přepínačů. Google je čte přímo z HTML.

Core Web Vitals 2026: tři metriky, které rozhodují o pozici

Mobile-first indexing nestojí jen na obsahu, ale i na výkonu. Google používá tři Core Web Vitals jako rankingový signál a měří je primárně na mobilních zařízeních — váš desktopový Lighthouse score je mu jedno.

Aktuální prahy (data z roku 2026):

Metrika	Co měří	Dobrý práh
LCP (Largest Contentful Paint)	Rychlost načtení největšího viditelného prvku	≤ 2,5 s
INP (Interaction to Next Paint)	Responzivita stránky na všechny interakce uživatele	≤ 200 ms
CLS (Cumulative Layout Shift)	Vizuální stabilita — kolik se obsah „skáče“ během načítání	≤ 0,1

INP nahradilo metriku FID v březnu 2024 a v roce 2026 je to nejčastěji propadávaná metrika — neuspěje na ní cca 43 % webů. Důvod? Zatímco FID měřilo jen první interakci, INP sleduje úplně všechny kliky, tapy a klávesové vstupy během návštěvy a bere ten nejhorší případ.

Podle Web Almanacu projde všemi třemi Core Web Vitals jen 48 % mobilních stránek a 56 % desktopových. Více než polovina webu na mobilu propadá. Pokud jste mezi nimi, máte před konkurencí, která to zvládne, automatickou nevýhodu.

Proč jsou CWV tvrdší na mobilu než na desktopu

Google sbírá data z reálných uživatelů (Chrome User Experience Report) na mediánových zařízeních a běžných sítích. Mobilní procesor je slabší než notebook, mobilní 4G/5G síť pomalejší než kabelové připojení. Pokud máte web testovaný jen na vlastním MacBooku přes Wi-Fi, vaše čísla nemají s realitou nic společného.

Zaměřte se na metrické hodnoty na 75. percentilu — Google posuzuje výkon podle pomalejších 25 % vašich uživatelů, ne podle průměru. Test dělejte na mid-range Androidu na 4G, ne na flagship modelech.

Nejčastější chyby, které srážejí weby v mobile-first indexingu

Když auditujeme weby, narážíme pořád na stejné chyby. Tady jsou ty nejdražší — všechny mají rychlou diagnostiku v Google Search Console nebo Lighthouse.

1. Mobilní verze má méně obsahu než desktopová

Klasika: aby web na mobilu nepůsobil přeplněně, designér zkrátí popisky produktů, schová sekci „časté otázky“ a nahradí dlouhý úvodní text krátkým shrnutím. Google ten zkrácený obsah pak používá jako základ pro ranking — a vy nechápete, proč jste přišli o pozice na klíčová slova z původního textu.

Test: vezměte stejnou URL, otevřete si ji v desktopovém i mobilním prohlížeči (DevTools → Device Toolbar) a postavte je vedle sebe. Cokoli, co je jen na desktopu, je pro Google v praxi neviditelné.

2. Robots.txt blokuje na mobilu CSS, JS nebo obrázky

Pokud váš robots.txt zakazuje crawlerům přístup ke statickým souborům (typicky kvůli „úspoře crawl budgetu“), Google nemůže stránku vyrenderovat, jak ji vidí uživatel. Výsledek = chybějící layout, chybějící data, špatný ranking.

Zkontrolujte v Search Console nástroj URL Inspection → View Tested Page → záložka More Info. Pokud Google hlásí nějaké blokované zdroje, opravte robots.txt.

3. Lazy-loading hlavního obsahu závislý na interakci

Google nedokáže simulovat klik, swipe nebo „načíst další“. Pokud váš e-shop načítá popisy produktů až po kliknutí na záložku „Detail“, crawler ten popis prostě nikdy neuvidí. Stejně tak FAQ, recenze, srovnávací tabulky.

Řešení: hlavní obsah dejte do iniciálního HTML. Lazy-loading používejte jen na obrázky níže ve stránce a na nepodstatné widgety.

4. Rozdílná strukturovaná data na mobilu a desktopu

Často to vzniká neúmyslně — frontendová šablona pro mobil opomenutím vynechá schema.org markup pro Product nebo Review. Google pak na mobilu nevidí cenu, hodnocení ani ostatní rich snippet data, a vy přicházíte o hvězdičky a viditelnost ve výsledcích.

5. INP propadá kvůli third-party skriptům

Analytika, chat widget, marketingové pixely, A/B testovací nástroj, embedovaný formulář, cookie banner — každý další třetí-stranový skript blokuje main thread a zhoršuje INP. Audit udělejte rychle: vypněte v DevTools všechny third-party skripty a změřte rozdíl ve skóre.

Co zlikvidovat nebo odložit: hover-only menu (na touch zařízeních ani nefunguje), těžké animace, dekorativní stock fotky, komplexní interaktivní widgety bez konverzního přínosu.

Krok za krokem: jak optimalizovat web pro mobile-first indexing v 8 krocích

Tady je konkrétní postup, který funguje na malých webech i na e-shopech s desetitisíci URL. Začněte odshora a postupujte dolů — pořadí je úmyslné a jde po nejvyšším dopadu na ranking.

1. Otevřete Google Search Console a zkontrolujte report Page Experience a Core Web Vitals. Tady uvidíte, kolik URL je v zóně Good, Needs Improvement a Poor — a které metriky propadají nejčastěji.
2. V URL Inspection toolu zkontrolujte 5–10 vašich nejvýdělečnějších stránek. V detailu „View tested page“ porovnejte vyrenderovaný HTML s tím, co vidíte v desktopovém prohlížeči. Hledejte mezery v obsahu.
3. Auditujte content parity — používáte responzivní design? Pokud ano, je content parity automatická. Pokud máte separátní mobilní URL (m.example.com) nebo dynamic serving, projděte hlavní šablony manuálně.
4. Otestujte si rychlost na realistickém zařízení. Použijte PageSpeed Insights s mobilní volbou, ne jenom desktop. Sledujte field data (data od reálných uživatelů z CrUX), ne jen lab data.
5. Zkontrolujte robots.txt — žádné Disallow na .css, .js nebo na složky s obrázky. Crawler musí mít přístup ke všemu, co potřebuje k vyrenderování stránky.
6. Ověřte, že strukturovaná data jsou identická na obou verzích. Použijte Rich Results Test nebo Schema Markup Validator a otestujte stejnou URL v desktopovém i mobilním režimu.
7. Snižte INP — auditujte third-party skripty, zvažte defer/async u nepodstatných, rozdělte dlouhé JavaScript tasky a yieldujte main thread (např. setTimeout 0, scheduler.yield).
8. Nastavte si průběžný monitoring. Search Console kontrolujte týdně, RUM (Real User Monitoring) přes Web Vitals JS knihovnu napojte na GA4 a vytvořte alerty pro propad jakékoli z metrik.

Speciální případy: e-shopy, lokální business, JavaScriptové weby

E-shopy

Mobil v roce 2026 generuje 78 % traffic na retail weby a 73 % nákupů. Desktop už není vaše hlavní platforma, ať si to admini myslí, jak chtějí. Klíčové fixy pro e-shop:

• Popisky produktů musejí být celé v iniciálním HTML, ne v záložce „Detail“ načítané JavaScriptem
• Recenze (vč. schema markupu) zobrazte na produktové stránce nativně, ne přes externí widget načítaný po scrollu
• Filtrované kategorie — pokud filtr generuje novou URL přes JavaScript bez SSR, Google ji nezaindexuje. Použijte facetové URL s SSR.
• Click-to-call a kontakty mějte v HTML, ne v JS-rendered komponentě, hlavně u lokálních e-shopů

Lokální podnikání (restaurace, služby, řemeslo)

Podle Googlu 76 % lokálních mobilních hledání vede k návštěvě obchodu do 24 hodin, a 88 % „near me“ hledání se odehrává na mobilu. Pokud máte fyzickou provozovnu, mobilní optimalizace není volba.

• Click-to-call telefon nahoře nad fold (href=”tel:+420…”) přímo v HTML
• Adresa, otevírací hodiny a embed mapy v iniciálním HTML
• LocalBusiness schema markup s opening hours, geo coordinates, telefonem
• Aktuální profil na Google Business — informace musí souhlasit s webem (NAP konzistence)

JavaScriptové weby (React, Vue, Next.js)

Single-page applications jsou pro mobile-first indexing nejriskantnější. Pokud spoléháte na client-side rendering, potřebujete SSR nebo prerendering. Bez toho hraje Google ruletu, jestli stihne stáhnout, vyrenderovat a zaindexovat váš obsah dřív, než vyprší render budget.

Frameworky to dnes řeší elegantně: Next.js a Nuxt mají SSR a SSG nativně, Astro nabízí island architecture s minimem JS. Pokud máte starší React app bez SSR, zvažte přechod nebo aspoň nasazení prerendering služby (Prerender.io, Rendertron).

Co se v mobile-first indexingu změnilo v roce 2026

Pár věcí, které jsou nové oproti starším návodům.

Search Console už crawler info nezobrazuje

Po dokončení přechodu Google z Search Console odstranil informaci o tom, kterým crawlerem byl web procházen — všechny weby jsou crawlovány mobilním botem. Pokud jste si zvyklí tu informaci kontrolovat, už ji tam nenajdete.

INP je oficiální metrika a tlačí na změny v JS architektuře

Od března 2024 INP nahradil FID. V roce 2026 propadá na INP cca 43 % webů — opravit to nejde tím, že zkomprimujete obrázek, jde o JavaScript architekturu. Teď je dobrý čas auditovat, kolik balastu máte v bundle, a zda nemáte zbytečně velké third-party závislosti.

Mobile-only signály jsou silnější

Google posiluje váhu mobilních signálů i pro desktopové výsledky. Stránka pomalá na mobilu může propadnout v desktopovém SERPu, i když na desktopu samotném běhá rychle. Optimalizace pro mobil přestala být „mobil-only otázka“ a stala se centrální SEO disciplínou.

AI Overviews mění význam mobilní rychlosti

S nástupem AI Overviews v Google se část mobilního trafficu posouvá k webům, které jsou citovány v AI generovaných odpovědích. Citované stránky musejí být dostatečně rychlé, aby je Google mohl spolehlivě parsovat — pomalý JS-heavy web má menší šanci se do AI Overview dostat. Mobile-first indexing a optimalizace pro AI search jsou v roce 2026 dvě strany téže mince.

Nejčastější otázky

Jaký je rozdíl mezi mobile-friendly a mobile-first indexing?

Mobile-friendly znamená, že web na mobilu vypadá a funguje (čitelné písmo, klikatelná tlačítka). Mobile-first indexing je princip, kdy Google používá mobilní verzi vašeho webu jako primární zdroj pro indexaci a rankování — a desktop ignoruje. Můžete mít web mobile-friendly a přesto u mobile-first indexingu propadnout, pokud má mobilní verze méně obsahu nebo blokované zdroje.

Jak zjistím, zda Google indexuje můj web mobilním crawlerem?

V roce 2026 už to platí pro všechny funkční weby. Google v červenci 2024 odstranil v Search Console informaci o tom, jakým crawlerem je web procházen, protože všechno je už mobilní. Pokud váš web na mobilu funguje, je crawlován Googlebot Smartphone.

Můžu skrývat obsah na mobilu v akordeonech a tabech bez ztráty rankingu?

Ano, pokud je celý obsah v iniciálním HTML a je skrytý jen vizuálně přes CSS (display: none, height: 0). Google v roce 2026 chápe běžné UI patterny. Problém nastává, když se obsah načítá až po interakci přes JavaScript — to bot nezvládne odhalit. Doporučení: pro skládací sekce používejte sémantické tagy <details> a <summary>.

Proč moje desktopová verze ztratila pozice, i když je obsah pořád stejný?

Velmi pravděpodobně proto, že vaše mobilní verze má méně obsahu nebo horší výkon (Core Web Vitals). Google používá mobilní verzi pro ranking i v desktopových výsledcích. Otevřete si stejnou URL na mobilu a desktopu vedle sebe a hledejte mezery v textu, schema markupu a interních odkazech.

Co je INP a proč je v roce 2026 tak důležité?

Interaction to Next Paint je jedna ze tří Core Web Vitals a měří, jak rychle stránka reaguje na všechny interakce uživatele (kliky, tapy, klávesové vstupy). Dobrá hodnota je pod 200 ms. INP nahradilo metriku FID v březnu 2024 a v roce 2026 na něm propadá cca 43 % webů. Hlavní příčina: nadbytek third-party skriptů a špatná JS architektura.

Stačí mít responzivní design pro mobile-first indexing?

Responzivní design je nejjednodušší cesta k content parity (jeden HTML kód pro všechna zařízení), ale nestačí. Web musí být zároveň rychlý na mobilu (Core Web Vitals), nesmí blokovat zdroje v robots.txt, musí mít validní strukturovaná data a hlavní obsah v iniciálním HTML, ne v JS-rendered komponentě závislé na interakci.

Shrnutí: mobile-first indexing je v roce 2026 jediný indexing

Pokud z článku odejdete s jednou věcí, ať je to tahle: Google už nemá desktopový a mobilní index. Má jen jeden index, postavený na tom, co vidí na mobilu. Vaše desktopová verze pro něj v praxi neexistuje, ať vypadá jak vypadá.

Akční plán na příštích 30 dní: zkontrolujte Page Experience report v Search Console, projděte 10 nejvýdělečnějších URL přes URL Inspection a porovnejte mobilní a desktopový obsah. Auditujte third-party skripty a opravte to, co propadá v Core Web Vitals. Pokud máte JavaScriptový web bez SSR, vyřešte to před tím, než se pustíte do dalších SEO aktivit — všechno ostatní stojí na téhle základně.

Mobilní web už není vaše „druhá verze“. Je vaše jediná verze, kterou Google reálně vidí. A když to ví on, měli byste to vědět i vy.

Další zdroje:

1. Mobile-first Indexing Best Practices – Google Search Central [online]. [cit. 10. 5. 2026]. Dostupné z: https://developers.google.com/search/docs/crawling-indexing/mobile/mobile-sites-mobile-first-indexing
2. Mobile-first indexing has landed – thanks for all your support – Google Search Central Blog [online]. [cit. 10. 5. 2026]. Dostupné z: https://developers.google.com/search/blog/2023/10/mobile-first-is-here
3. Share of web traffic from mobile devices worldwide Q1 2026 – StatCounter / Statista [online]. [cit. 10. 5. 2026]. Dostupné z: https://www.statista.com/statistics/277125/share-of-website-traffic-coming-from-mobile-devices/
4. Mobile SEO 2026: Mobile-First Indexing Practices – Digital Applied [online]. [cit. 10. 5. 2026]. Dostupné z: https://www.digitalapplied.com/blog/mobile-seo-2026-mobile-first-indexing-guide
5. Core Web Vitals 2026: INP, LCP, CLS Optimization Guide – Senorit [online]. [cit. 10. 5. 2026]. Dostupné z: https://senorit.de/en/blog/core-web-vitals-2026
6. Mobile-First Indexing: Best Practices + Tips for Ecommerce – Shopify [online]. [cit. 10. 5. 2026]. Dostupné z: https://www.shopify.com/blog/mobile-first-indexing
7. What Are the Core Web Vitals? LCP, INP & CLS Explained 2026 – CoreWebVitals.io [online]. [cit. 10. 5. 2026]. Dostupné z: https://www.corewebvitals.io/core-web-vitals
8. How Mobile First Indexing Affects Google Rankings In Modern SEO – Search Engine Zine [online]. [cit. 10. 5. 2026]. Dostupné z: https://searchenginezine.com/technical/mobile/mobile-first-indexing/