Přesměrování URL s kotvou: rozdíl mezi fragmentem zdroje a cíle

V mapě máte dva zdroje: /poradna/#doprava a /poradna/#vraceni. Každý chcete poslat jinam. Tabulka vypadá logicky, server však část za mřížkou nedostává. Dvě taková pravidla proto nejsou běžným řešením rozdělení jedné stránky na dvě nové.

Fragment není další cesta na serveru. Je to část adresy, kterou zpracovává klient, například prohlížeč při přechodu na oddíl dokumentu. V tomto rozboru oddělíme chybný zdroj s fragmentem, legitimní cíl s kotvou a konflikt dvou různých cílových kotev. Na modelových datech si ukážeme, co rozpozná kontrola mapy přesměrování a co musíte ověřit přímo ve výsledné stránce.

Co z adresy skutečně dostane server

Rozložme si modelovou adresu https://example.com/poradna/?jazyk=cs#doprava. Doména určuje místo, cesta dokument, parametr předává další informaci a fragment označuje část výsledného zdroje. Mřížka tady není jen jiný oddělovač parametrů. Dotaz ?jazyk=cs a fragment #doprava mají odlišnou roli.

Při běžném požadavku na dokument server dostane cestu a dotaz, nikoli fragment. Nemůže tedy z takového požadavku rozlišit člověka, který otevřel dopravu, od člověka, který otevřel vrácení. Oba požadují stejný dokument. To vysvětluje, proč naše kontrola označuje fragment ve zdrojové URL jako chybu pravidla.

Máte-li potíže s dotazovými parametry, pokračujte samostatným rozborem parametrů URL v mapě. Odstranění všeho za otazníkem a odstranění všeho za mřížkou není jedna společná „normalizace adres“. Každý zásah potřebuje vlastní důvod a kontrolu výsledku.

Model A: dvě původní kotvy nejsou dvě serverové stránky

Představme si původní poradnu se dvěma sekcemi a nový web se dvěma samostatnými články. Následující CSV je záměrně chybné. Používá modelovou doménu, takže nic nenastavuje ani netestuje na skutečném webu.

source;target;status
https://example.com/poradna/#doprava;https://example.com/doprava/;301
https://example.com/poradna/#vraceni;https://example.com/vraceni/;301

Po vložení do kontroly oba záznamy dostanou chybu zdroje obsahujícího fragment. Zároveň se po odstranění fragmentů při porovnávání zdrojů potkají na stejné adrese poradny, ale mají různé cíle. Výsledek proto obsahuje také konflikt. Nejde o dva nezávislé problémy, které vyřešíte přejmenováním sloupců; oba vycházejí z neproveditelného rozlišení zdroje.

Nemažte mřížky a nenechávejte oba řádky. Dostali byste dvě pravidla pro jeden zdroj se dvěma cíli. A nezvolte náhodně první cíl jen proto, aby zmizela červená barva. Tím byste rozhodli za návštěvníky druhého oddílu, aniž byste jejich potřebu řešili.

• Zjistěte, zda původní poradna může zůstat jako rozcestník s původními identifikátory sekcí.
• Pokud se přesouvá celý dokument, určete jedno obsahově vhodné místo pro celý původní vstup.
• Odkazy, které ovládáte, upravte přímo na nový článek a případnou novou kotvu.
• Požadavek na rozlišení starých fragmentů předejte vývojáři jako samostatnou klientskou funkci, pokud je opravdu potřebná.

Poslední bod není pokyn přidat univerzální JavaScript nebo nový nástroj. Klientské řešení má vlastní chování a testy a tato CSV kontrola je neprověřuje. Pro menší poradnu může být udržení srozumitelného rozcestníku jednodušší a pro čtenáře předvídatelnější.

Model B: cíl s kotvou může být správně

Jiná situace nastane, když měl původní web samostatnou stránku dopravy a nový obsah ji sloučil do rozsáhlejší poradny. Zdroj je obyčejná dokumentová URL, cíl obsahuje kotvu konkrétního oddílu. Takový plán není automaticky chyba.

source;target;status
https://example.com/stara-doprava/;https://example.com/poradna/#doprava;301

Kontrola označí cílový fragment jako k prověření. Ve sloupci konce cesty v mapě pracuje s dokumentovou URL bez fragmentu. To umožňuje sledovat návaznosti dokumentů, ale zároveň to znamená, že nalezený konec cesty nepotvrzuje funkční skok na oddíl dopravy. Vstupní sloupec cíle s fragmentem si proto při interpretaci ponechte před očima.

Chybějící kotva může být nenápadná: stránka se načte, vrátí úspěšnou odpověď a návštěvník zůstane nahoře nad dlouhým obsahem. Kontrola HTTP odpovědi a kontrola chování kotvy proto odpovídají na dvě různé otázky. Nestačí napsat „cílová URL funguje“ bez uvedení, kterou z nich jste ověřili.

Model C: stejné dokumenty, různé cílové fragmenty

Do mapy se mohou dostat dva řádky se shodným zdrojem, které ukazují na stejnou poradnu, ale na odlišné oddíly. Na první pohled se zdá, že oba „vedou na stejnou stránku“. Pro znění přesměrovacího pravidla však mají odlišný cíl.

source;target;status
https://example.com/stara-pomoc/;https://example.com/poradna/#doprava;301
https://example.com/stara-pomoc/;https://example.com/poradna/#vraceni;301

Nástroj nahlásí konflikt, protože porovnává také fragment cílového pravidla. Je to užitečná pojistka proti sloučení dvou odlišných rozhodnutí. Oba řádky navíc nesou upozornění na kotvu. Nejprve určete jeden schválený cíl; teprve potom ověřujte jeho oddíl. Kontrola existujícího oddílu sama nevybere správnou variantu.

Jestliže původní pomoc obsahovala obě témata, může být přirozeným cílem rozcestník bez upřednostnění jedné sekce. To je obsahová volba, kterou má potvrdit člověk znalý původní stránky. Technická tabulka z názvu URL spolehlivě nevyčte, co čtenář původně hledal.

Jak kotvu prověřit v prohlížeči

Začněte na cílové stránce a ověřte přesný identifikátor požadovaného oddílu. Nadpis „Doprava“ ještě nezaručuje, že má v HTML id="doprava". Editor může identifikátor vygenerovat jinak nebo ho po přejmenování změnit. Při redakční změně názvu proto zvažte zachování již používané kotvy.

1. Otevřete celou cílovou adresu včetně fragmentu v novém načtení stránky.
2. Ověřte, že je viditelný správný nadpis i začátek relevantního obsahu.
3. Zkontrolujte mobilní zobrazení; pevné záhlaví může požadovaný nadpis zakrýt.
4. Po nasazení otevřete také původní zdroj a zaznamenejte skutečnou cestu na cíl.
5. Uložte úplnou použitou adresu, datum, prostředí a výsledek, nikoli pouze screenshot samotného odstavce.

U stránky, která obsah načítá dodatečně, testujte i první příchod bez předchozí návštěvy. Ruční kliknutí na obsah již načtené stránky nemusí odpovídat chování příchozího odkazu. Pokud se oddíl objeví až po otevření panelu nebo jiné akci, zaznamenejte tuto podmínku a neuzavírejte test jako běžnou funkční kotvu.

V evidenci SEO nálezů oddělte dva důkazy: „přesměrování vrací schválené Location“ a „cílový oddíl je po příchodu viditelný“. Při pozdější závadě pak poznáte, jestli se změnilo serverové pravidlo, identifikátor sekce nebo způsob vykreslení stránky.

Jak opravit mapu bez ztráty informace

Pracujte v kopii podkladu se zaznamenanou verzí. Zdroje s fragmenty si nejdřív odložte do pracovního seznamu původních odkazů. Uchováte tak informaci, na které sekce lidé odkazovali, i když z ní nevznikne samostatné serverové pravidlo. Tento seznam není CSV určené k automatickému nasazení.

Do výsledné mapy vraťte pouze jednoznačné dokumentové zdroje. Cílové fragmenty ponechte, pokud byly vědomě zvoleny a mají vlastní kontrolu. Následně spusťte znovu celou mapu, protože úprava cíle může odhalit návazný řetězec, konflikt nebo přesměrování dokumentu na sebe. Rozbor duplicit a konfliktů pomůže odlišit opakování stejného pravidla od dvou odlišných rozhodnutí.

Neuzavírejte upozornění pouhým odstraněním fragmentu z cíle. Zelenější výsledek může znamenat horší příchod uživatele. Jestliže kotva plní svůj účel, správným řešením je doložené prověření a zachování užitečného odkazu. Automatická kontrola nemá nahrazovat schválení obsahového záměru.

Předávací list pro redakci a vývoj

U dlouhodobě používané poradny připravte malý seznam důležitých příchodů. Jeden řádek bude obsahovat původní úplný odkaz, plánované dokumentové pravidlo, požadovaný oddíl a odpovědnou osobu. Samotný seznam nedávejte bez úpravy do serverového importu: kombinuje totiž informace o dokumentu a požadavky na klientské zobrazení.

Pro původní adresu dopravy tak může být serverovým požadavkem přesun na poradnu, zatímco požadavkem pro návštěvníka je viditelný oddíl dopravy. Tyto podmínky se dají ověřovat samostatně. Když jedna neprojde, kolega ví, komu úkol předat a kterou část znovu prověřit.

Do kontrolního vzorku zahrňte také odkaz bez fragmentu a odkaz s chybným nebo již zrušeným fragmentem. Neznamená to, že chybná kotva musí vždy automaticky přesměrovat na jiný oddíl. Potřebujete vědět, jak se stránka zachová, zda návštěvník nezůstane v nečitelném stavu a zda se původní dokument přesto načte s použitelnou navigací.

Kotvy jsou součástí redakční údržby. Pokud editor přejmenuje nadpis, nesmí se změna existujícího identifikátoru ztratit mezi úpravami formulací. Do zadání revize napište, které kotvy už používají interní odkazy, a po uložení ověřte jejich skutečnou funkci. Zkontrolujte také obsah článku, pokud se vytváří z těchto identifikátorů.

V přejímce uveďte přesnou testovanou adresu, typ zařízení a očekávaný oddíl. Věta „ověřeny odkazy“ je příliš neurčitá. Záznam „úplný odkaz otevřen po novém načtení, správný nadpis viditelný bez překrytí záhlavím“ dovoluje výsledek později zopakovat. Při změně šablony se pak nezkouší náhodný odstavec, ale stejný významný příchod.

Pokud cíl přidává ještě další serverové přesměrování, doplňte tento případ zvlášť. Kontrola tabulky nepředpovídá všechny kombinace skutečného serverového a klientského chování. Případnou další cestu zaznamenejte podle pozorování, nevydávejte ji za důsledek CSV, ve kterém dané pravidlo není.

Cvičení: co předáte vývojáři

Máte původní adresu /podminky/#reklamace a chcete ji přesměrovat na nový článek. V mapě současně existuje pravidlo z /podminky/#platba na jiný článek. Kolega navrhuje oba fragmenty smazat a ponechat dvě pravidla. Jaké zadání je použitelné?

Zobrazit řešení a důvod

Nejprve rozhodněte o jedné dokumentové adrese /podminky/. Dvě serverová pravidla odlišená pouze původním fragmentem běžný požadavek nerozliší. Zachovejte seznam historických kotev pro úpravu vlastních odkazů nebo samostatné posouzení klientského chování. Vývojář má dostat jednoznačné pravidlo pro dokument a oddělené požadavky na příchod ke konkrétním oddílům, včetně způsobu ověření.

Výsledkem práce tedy není jen CSV bez chyby. Je jím srozumitelné rozhodnutí o celém původním dokumentu, zachovaný přehled důležitých starých odkazů a prověřené chování nového příchodu. Další hranice automatické kontroly shrnuje článek co samotná mapa neověří.

Časté otázky

Lze na serveru rozlišit zdroje podle části za mřížkou?

Při běžném HTTP požadavku se fragment serveru neposílá. Zdroje lišící se jen kotvou proto nejsou dvě odlišitelné dokumentové adresy pro běžné serverové přesměrování. Je potřeba rozhodnout o celém dokumentu a odděleně o práci s odkazy.

Může být kotva v cíli přesměrování?

Ano, může být záměrně součástí cíle. Vedle skutečného Location ověřte, že úplný odkaz po příchodu zobrazí správný oddíl. Pouhá úspěšná odpověď dokumentu nepotvrzuje existenci ani viditelnost kotvy.

Proč po odstranění zdrojových kotev vznikne konflikt?

Z různých zápisů se může stát stejný dokumentový zdroj s několika cíli. Nestačí mřížky smazat a ponechat oba řádky. Potvrďte jednoznačnou náhradu dokumentu a zachovejte samostatnou evidenci důležitých starých odkazů.