SEO optimalizácia webu: rýchlosť servera, HTTPS a technický základ

aktualizované 27. októbra 2026

SEO optimalizácia webu na úrovni servera znamená tri veci: každá adresa vracia správny stavový kód, stránky chodia cez HTTPS s presmerovaním na jednu podobu adresy a odpoveď príde dosť rýchlo, aby ju vyhľadávač aj návštevník dostali bez zdržania. Obsah a odkazy tým nenahradíte, ale chyba na serveri ich môže skryť. Podľa Googlu ani stavový kód 2xx nezaručuje indexáciu, takže tento základ je podmienka, nie záruka pozícií. Ďalej sú kontroly, ktoré administrátor zvládne z terminálu: stavové kódy, presmerovania, čas odozvy, súbory pre crawlery a logy.

Stavové kódy: čo z odpovede servera vyčíta Googlebot

Googlebot o adrese rozhoduje podľa stavového kódu skôr, než sa pozrie na obsah. Dokumentácia Google Search Central opisuje správanie takto:

Smernica error_page vie podľa dokumentácie nginx zmeniť kód odpovede, napríklad error_page 404 =200 /empty.gif;. Pri chybovej stránke by tým vznikol soft 404, preto k nej =200 nepridávajte. Ak treba web vypnúť na 1 až 2 dni, Google odporúča informačnú stránku s kódom 503 a hlavičku Retry-After s dátumom alebo trvaním. V nginx ju pridáte cez add_header Retry-After 3600 always;, lebo bez always nginx pridáva hlavičky len pri kódoch 200, 201, 204, 206, 301, 302, 303, 304, 307 a 308.

HTTPS a presmerovania na jednu adresu

Pri duplicitných adresách Google uprednostňuje HTTPS verziu ako kanonickú, ak signály nie sú v konflikte. Zvoľte jednu podobu adresy (protokol, www alebo bez, lomka na konci) a všetky ostatné presmerujte trvalo a priamo na ňu. Pri prechode z HTTP na HTTPS Google odporúča kódy 301 alebo 308, presmerovanie na konečný cieľ bez reťazenia a ponechať ho spravidla aspoň rok. Googlebot predvolene sleduje najviac 10 presmerovaní, no každý krok predlžuje odozvu: web.dev počíta čas presmerovaní do TTFB.

server {
    listen 80;
    server_name example.org www.example.org;
    return 301 https://example.org$request_uri;
}

Adresa v return smie podľa dokumentácie nginx obsahovať premenné a $request_uri je pôvodná adresa aj s argumentmi. Blok pre www.example.org na porte 443 urobí rovnaké return 301, takže z každej varianty vedie jediný krok. Firewall z článku Prvých tridsať minút na novom VPS musí pustiť porty 80 aj 443. Výsledok overíte príkazom:

curl -sL -o /dev/null -w '%{http_code} %{num_redirects} %{url_effective}\n' http://www.example.org/stranka

Správny výstup je 200 1 https://example.org/stranka. Dvojka a viac znamená reťaz presmerovaní.

Rýchlosť servera: TTFB a Core Web Vitals

Core Web Vitals majú tri metriky: LCP meria rýchlosť načítania, INP odozvu a CLS vizuálnu stabilitu. Hodnotí sa 75. percentil načítaní, zvlášť pre mobil a desktop. Prahové hodnoty podľa web.dev:

Google uvádza, že jeho systémy hodnotenia Core Web Vitals využívajú, a zároveň, že stránku so slabším zážitkom zobrazí, ak je najrelevantnejšia. Technický základ pozície nezaručuje. Hodnoty pre celú stránku zobrazuje správa Core Web Vitals v Search Console.

Server sa premieta do LCP, lebo doň patria aj presmerovania a TTFB, teda čas po prvý bajt odpovede. TTFB nie je Core Web Vital, web.dev však za dobrú hodnotu považuje 0,8 s a menej a za zlú viac než 1,8 s. Meranie z terminálu:

curl -s -o /dev/null -w 'TTFB %{time_starttransfer} s, spolu %{time_total} s\n' https://example.org/

Hodnota time_starttransfer je čas od začiatku operácie po prvý prijatý bajt. Do logu nginx pridajte $request_time, celkový čas spracovania požiadavky, a pri aplikácii za proxy aj $upstream_response_time, čas prijatia odpovede od aplikácie:

log_format seo '$remote_addr - $remote_user [$time_local] "$request" '
               '$status $body_bytes_sent "$http_referer" "$http_user_agent" '
               '$request_time $upstream_response_time';
access_log /var/log/nginx/access.log seo;

Ak je odozva vysoká, skontrolujte ďalšie nastavenia a to, čo o nich hovorí dokumentácia:

robots.txt, sitemap.xml a canonical

Súbor robots.txt patrí do koreňa stránky a Google z neho číta najviac 500 KiB. Dôležité je, ako server na súbor odpovedá. Pri chybe 4xx (okrem 429) sa Google správa, akoby súbor neexistoval. Pri chybe 5xx prvých 12 hodín crawlovanie stránky zastaví a ďalších 30 dní používa poslednú dobrú verziu súboru. Pri odstávke preto robots.txt nikdy nevracajte s kódom 503, Google upozorňuje, že to zablokuje všetko crawlovanie.

Jedna sitemap.xml smie mať najviac 50 MB bez kompresie alebo 50 000 adries, musí byť v UTF-8 a obsahovať absolútne adresy. Do robots.txt ju pridáte riadkom Sitemap: https://example.org/sitemap.xml, vždy s úplnou adresou vrátane protokolu a hostiteľa. Sitemap je pre Google len slabý signál kanonickej adresy, preto v nej uvádzajte len tie adresy, ktoré chcete ako kanonické. Silné signály sú presmerovanie a prvok <link rel="canonical" href="..."> v hlavičke stránky. Pri súboroch, ktoré nie sú HTML, napríklad PDF, ho nahrádza HTTP hlavička Link: <https://example.org/dokument.pdf>; rel="canonical", ktorú v nginx pridáte cez add_header.

Logy servera: čo Googlebot skutočne dostal

Access log ukáže, čo crawler naozaj dostal, nezávisle od toho, čo vidíte v prehliadači. V logu z predošlej časti je stavový kód deviatym poľom riadku, rovnako ako vo formáte combined. Postup:

1. Spočítajte kódy, ktoré dostal Googlebot: grep Googlebot /var/log/nginx/access.log | awk '{print $9}' | sort | uniq -c | sort -rn. Podiel 3xx a 4xx ukáže, koľko crawlovania sa míňa na adresy, ktoré nevedú na obsah.
2. Vypíšte adresy s chybou: grep Googlebot /var/log/nginx/access.log | awk '$9 >= 400 {print $9, $7}' | sort | uniq -c | sort -rn | head.
3. Overte pôvod. Reťazec Googlebot v hlavičke User-Agent môže poslať ktokoľvek. Google radí urobiť reverzné DNS vyhľadanie IP adresy z logu príkazom host 66.249.66.1, skontrolovať, že doména je googlebot.com, google.com alebo googleusercontent.com, a spätným vyhľadaním domény overiť, že vráti pôvodnú IP. Google zverejňuje aj zoznamy IP rozsahov vo formáte JSON.
4. Pri adresách, ktoré Googlebot žiada najčastejšie, pozrite posledné dve polia, $request_time a $upstream_response_time. Pomalé odpovede na často žiadané adresy riešte ako prvé.

Časté otázky

Ďalšie návody

Nginx: inštalácia, nastavenie webu a reverzný proxy krok za krokom

Nginx na Linuxe: čo je, inštalácia z balíčkov, štruktúra nginx.conf, statický web, reverzný proxy, kontrola nginx -t a riešenie chýb 502 a 403.

Vypratávanie Bratislava: čo so servermi a diskami, kým sa kancelária vyprázdni

Vypratávanie Bratislava z pohľadu IT: inventúra techniky, overená záloha, vymazanie disku (shred, nwipe, secure erase SSD) a odovzdanie elektroodpadu.

Písanie bakalárskych prác z informatiky: praktická časť na serveri

Písanie bakalárskych prác z informatiky: rozsah a náležitosti podľa usmernenia 56/2011, praktická časť na serveri, dokumentácia, citovanie a originalita.