Přesměrování v PrestaShopu: změna link-rewrite, 301 redirecty a dopad na SEO

Jak funguje směrování URL v PrestaShopu, kdy použít 301 přesměrování, jaké jsou limity nativního řešení a na co si dát pozor při migraci nebo hromadných úpravách katalogu.

Publikováno: 15.10.2023

Úvod: Po změně URL mi klesla návštěvnost – proč?

Změníte názvy produktů, upravíte strukturu kategorií nebo migrujete na novější verzi PrestaShopu. Vše technicky funguje. O několik týdnů později ale:

  • roste počet 404 chyb,
  • některé URL mizí z indexu,
  • organická návštěvnost klesá.

Ve většině případů není problém v samotné změně URL, ale v tom, jak bylo (nebo nebylo) řešeno přesměrování.

Tento článek vysvětluje technické pozadí směrování URL v PrestaShopu, rozdíly mezi verzemi, limity nativního řešení i rizika kombinace aplikačních a serverových redirectů.

Co se technicky stane při změně URL

Vyhledávače indexují konkrétní URL. Pokud adresu změníte, vzniká z jejich pohledu nová stránka.

Bez správně nastaveného 301 přesměrování:

  • původní URL vrací 404,
  • externí odkazy přestávají přenášet hodnotu,
  • dochází k opětovnému zpracování a vyhodnocení nové URL,
  • může dojít k dočasné nebo trvalejší ztrátě pozic.

Ve většině případů je při trvalé změně URL vhodné použít 301 přesměrování. Existují však výjimky – například při konsolidaci duplicitních variant, kde může hrát roli canonical strategie.

Jak PrestaShop interně směruje URL

Role Dispatcheru

PrestaShop používá interní router (Dispatcher), který na základě pravidel vygenerovaných při zapnutých „Friendly URL“ mapuje URL na konkrétní controller a ID objektu.

Typická URL: /123-cervene-boty.html

  • 123 = ID produktu
  • cervene-boty = link_rewrite

Dispatcher primárně pracuje s ID. link_rewrite slouží k validaci a SEO čitelnosti.

Co znamená „ID fallback“

Pokud je ID součástí URL a přátelské URL jsou zapnuté:

  • systém dokáže produkt dohledat podle ID,
  • nesoulad v link_rewrite obvykle nevede okamžitě na 404.

Pokud však:

  • ID z URL odstraníte,
  • používáte modul generující jinou strukturu,
  • nebo dojde ke konfliktu pravidel,

směrování probíhá pouze podle SEO části a změna link_rewrite bez přesměrování může vést k 404.

Rozdíly mezi verzemi 1.6 a 1.7/8

Při migraci je důležité si uvědomit:

  • Verze 1.6 používala jinou strukturu šablon a často i jiné SEO moduly.
  • Ve verzích 1.7/8 došlo k přepracování části architektury a routingu.
  • Některé moduly generují odlišné URL schéma.

Migrace mezi major verzemi tedy často znamená změnu URL struktury – a tím i nutnost systematického přesměrování.

Jak funguje nativní přesměrování v PrestaShopu

V administraci (Shop Parameters → Traffic & SEO) lze zapnout automatické přesměrování při změně URL.

Technicky:

  • PrestaShop ukládá přesměrování do databáze,
  • při požadavku je redirect vyhodnocen na úrovni aplikace,
  • redirect probíhá až po inicializaci aplikace.

Limity:

  • vhodné pro jednotlivé změny,
  • nevhodné pro hromadné migrace,
  • neřeší změnu domény,
  • může zatěžovat aplikaci při velkém množství pravidel.

Serverové přesměrování (.htaccess / Nginx)

Příklad pro Apache:

Redirect 301 /stara-url.html https://www.domena.cz/nova-url.html

Výhody:

  • vyhodnocení probíhá před spuštěním aplikace,
  • nižší aplikační zátěž.

Nevýhody:

  • Apache vyhodnocuje pravidla postupně (lineárně),
  • tisíce pravidel mohou zpomalit zpracování požadavku.

U Nginx je přístup odlišný (pravidla jsou součástí konfigurace serveru), což může mít jiné výkonové dopady.

Možný konflikt: aplikace vs server

Pokud kombinujete:

  • nativní redirecty v PrestaShopu,
  • pravidla v .htaccess,
  • přesměrování generovaná modulem,

může dojít k:

  • přesměrovacím řetězcům (A → B → C),
  • přesměrovacím smyčkám,
  • nebo k přepisování pravidel při regeneraci .htaccess.

Proto je důležité mít jednotnou strategii a jasně definovat, kde se přesměrování spravují.

Praktický scénář z praxe

E-shop provede hromadný import z ERP, který:

  • změní názvy produktů,
  • přepíše link_rewrite,
  • ale nevytvoří 301 přesměrování.

Výsledek:

  • stovky až tisíce URL zmizí,
  • Google začne indexovat nové adresy,
  • dočasně se propadnou pozice,
  • roste počet 404.

Tento scénář je běžný u větších katalogů bez kontrolního procesu.

301 vs 302 – technický kontext

301 (trvalé přesměrování)

Používá se při:

  • změně struktury URL,
  • migraci domény,
  • trvalé změně link_rewrite.

Vyhledávače postupně přesunou indexaci a signály na novou URL.

302 (dočasné přesměrování)

Pouze při:

  • dočasném přesunu,
  • testování.

Použití 302 místo 301 při trvalé změně může zpomalit přenos signálů.

Dopad na výkon

Každé přesměrování znamená další HTTP požadavek.

Výkon může být ovlivněn:

  • řetězením přesměrování,
  • velkým množstvím pravidel v Apache,
  • kombinací aplikačních a serverových redirectů.

U rozsáhlých e-shopů je vhodné pravidelně:

  • auditovat přesměrování,
  • kontrolovat délku redirect chain,
  • odstraňovat nevyužívaná pravidla.

Checklist při změně URL

Před změnou:

  • Export aktuálních URL.
  • Identifikace nejnavštěvovanějších stránek.
  • Analýza zpětných odkazů.

Po změně:

  • Implementace 301.
  • Kontrola HTTP status.
  • Monitoring 404.
  • Kontrola indexace.

FAQ

Musím vždy použít 301?

Ve většině případů trvalé změny ano. Výjimkou může být konsolidace duplicitních variant, kde hraje roli canonical strategie.

Je odstranění ID z URL bezpečné?

Ano, ale pouze pokud je připravena kompletní přesměrovací strategie a testování.

Může kombinace serverového a aplikačního redirectu způsobit problém?

Ano. Bez koordinace může vzniknout redirect chain nebo smyčka.

Závěr

Přesměrování v PrestaShopu je součást architektury e-shopu.

Důležité principy:

  • Rozumět tomu, jak funguje Dispatcher a ID v URL.
  • Při migraci mezi major verzemi počítat se změnou struktury.
  • Používat 301 ve většině trvalých změn, ale chápat kontext výjimek.
  • Mít jednotnou strategii pro aplikaci i server.
  • Pravidelně auditovat výkon i SEO dopady.

Systematický přístup k přesměrování chrání dlouhodobý výkon e-shopu.