Přesměrování URL s parametry: co zachovat a co lze odstranit

V exportu starého webu vidíte stovky adres s otazníkem. Chcete mapu zpřehlednit, a proto z každé URL odstraníte parametry. Tím ale můžete sloučit modrou a červenou variantu produktu do jedné adresy, která najednou potřebuje dva různé cíle. Část za otazníkem není automaticky technický odpad.

Na modelové migraci produktových adres ukážeme, jak rozlišit význam jednotlivých parametrů, připravit pravidla pro různé varianty a odhalit chybějící rozhodnutí kvůli jinému pořadí zápisu. Nejde o obecný návod vypnout nebo přesměrovat všechny parametry webu. Cílem je správně připravit konkrétní mapu a doložit, proč se některá hodnota zachovává a jiná může zůstat mimo cílovou URL.

Stejná cesta může označovat různé produkty

Modelový starší e-shop používá adresu /produkt a produkt vybírá pomocí parametru id. Další parametr barva určuje konkrétní provedení. Nový web má pro modrý a červený hrnek samostatné adresy a obecný detail hrnku nabízí výběr variant. Tyto vlastnosti jsou zadáním modelu, nikoli úsudkem podle názvů URL.

Parametr id vybírá produkt, barva jeho provedení a utm_source v tomto zadání označuje původ návštěvy. Kdybyste odstranili celou query, ze všech tří vstupů vznikne /produkt. Ztratíte informaci, která rozhoduje o cíli. Přehlednější tabulka by přestala popisovat původní situaci.

Google ve své dokumentaci doporučuje zkracovat URL odstraňováním nepotřebných parametrů, které nemění obsah. Rozhodující je právě tato podmínka. Z doporučení nelze odvodit, že každý parametr na libovolném starém webu může zmizet ještě před sestavením migrační mapy.

Rozdělte parametry podle účelu, ne podle dojmu

Připravte krátký seznam používaných parametrů a u každého zapište, kdo vysvětlil jeho význam. Pomoci může vlastník aplikace, dokumentace starého systému a konkrétní porovnání dostupného obsahu. Samotný název sort, ref nebo variant není spolehlivý důkaz chování všech aplikací.

• Identita obsahu: výběr produktu, článku, jazykové verze nebo konkrétní varianty.
• Stav zobrazení: řazení, filtr, stránkování či jiný výběr uvnitř seznamu; i zde může být význam pro návštěvníka odlišný.
• Měření a původ návštěvy: údaj používaný pro atribuci nebo označení kampaně; jeho odstranění potřebuje sladit očekávání měření.
• Citlivé nebo dočasné hodnoty: relace, přístupové tokeny a jiné údaje, které nepatří do veřejného pracovního příkladu.

Rozdělení není automatický přepisovací algoritmus. U každé skupiny potřebujete konkrétní rozhodnutí, jak se zachová zdroj, co dostane návštěvník na novém webu a co se má stát s případnou měřicí informací. Pokud odpověď neznáte, označte položku k doplnění. Není vhodné ji tiše vymazat už při čištění exportu.

Zkontrolujte úplné adresy v modelové mapě

Do kontroly mapy přesměrování vložte následující CSV. Naše kontrola zachovává query jako součást porovnávané adresy. V tomto modelu jsou tři zdroje odlišné a každý má jediný cíl. Výsledkem budou tři záznamy bez nálezu.

source;target;status
https://example.com/produkt?id=10&barva=modra;https://example.com/hrnek-modry/;301
https://example.com/produkt?id=10&barva=cervena;https://example.com/hrnek-cerveny/;301
https://example.com/produkt?id=10&utm_source=model;https://example.com/hrnek/;301

V textovém vstupu mají být mezi parametry běžné znaky &. Pokud někdo kopíruje zdrojový HTML kód místo zobrazeného textu, může si omylem přinést zápis ampersandu jako entity. Při předání kontrolujte skutečnou hodnotu buňky nebo textového řádku. HTML zápis odkazu není vždy totožný s textovým CSV.

Výsledek bez nálezu nepotvrzuje význam parametrů. Potvrzuje pouze vlastnosti dodaných pravidel, které nástroj kontroluje. Kdybyste modré variantě zadali červený cíl, struktura by mohla zůstat stejně čistá. Obsahovou náhradu proto dál potřebuje schválit odpovědná osoba.

Co se stane po smazání všeho za otazníkem

Pro názorné porovnání použijte chybnou variantu. Zachováme cíle, ale ze zdrojů odstraníme všechny parametry. Takto očištěná mapa obsahuje třikrát stejný zdroj se třemi různými cíli. Kontrola označí všechny tři řádky jako konflikt. Není to chyba nástroje ani důvod vybrat poslední řádek.

source;target;status
https://example.com/produkt;https://example.com/hrnek-modry/;301
https://example.com/produkt;https://example.com/hrnek-cerveny/;301
https://example.com/produkt;https://example.com/hrnek/;301

Vraťte se k původním úplným zdrojům. Smazáním dvou konfliktních řádků byste sice odstranili hlášení, ale současně byste ztratili rozhodnutí o zbývajících variantách. Správná oprava obnovuje informace potřebné k rozlišení požadavků. Mechanické odebrání duplicit tento typ ztráty nenahradí.

Pokud má cílový systém obsluhovat obecné pravidlo podle parametrů, jde o samostatný implementační úkol. Musí popsat rozpoznání hodnot, případné další parametry, jejich pořadí a výjimky. Prostá CSV kontrola zdroj–cíl takové serverové podmínky nesimuluje a neměla by být za jejich test vydávaná.

Jiné pořadí parametrů může odhalit mezeru v inventáři

Do původního inventáře přidejte ještě adresu /produkt?barva=modra&id=10. Podle zadání modelové aplikace zobrazuje stejnou modrou variantu jako první řádek mapy. V textu URL však mají dvojice jiné pořadí. Naše nástroje tento zápis automaticky nepřerovnávají.

V kontrole pokrytí migrace zadejte jako původní seznam všechny čtyři úplné adresy. Nový seznam obsahuje tři cíle z první tabulky a mapa původní tři pravidla. Výsledkem jsou tři adresy pokryté mapou a jedno chybějící rozhodnutí pro obrácenou variantu query.

Tento nález neznamená, že nástroj objevil čtvrtý produkt. Upozorňuje na čtvrtý konkrétní zápis vstupu, který není pokrytý dodaným plánem. Proto nejdřív potvrďte, zda ho má migrace obsloužit, a zda skutečně označuje stejný obsah. Z pouhé podobnosti znaků to obecně neplyne.

V našem zadání je shoda potvrzená, proto doplníme čtvrté přesné pravidlo. Všechny čtyři vstupy tak mají doloženou náhradu. Toto řešení ukazuje zamýšlený výsledek v mapě; vývojář může podle prostředí zvolit jinou implementaci se stejnými ověřenými případy.

source;target;status
https://example.com/produkt?id=10&barva=modra;https://example.com/hrnek-modry/;301
https://example.com/produkt?id=10&barva=cervena;https://example.com/hrnek-cerveny/;301
https://example.com/produkt?id=10&utm_source=model;https://example.com/hrnek/;301
https://example.com/produkt?barva=modra&id=10;https://example.com/hrnek-modry/;301

Normalizace není pouze přerovnání viditelných znaků

Při práci s URL můžete narazit na odlišné zápisy mezer, kódování znaků a opakované názvy parametrů. Dokumentace URLSearchParams ukazuje, že zpracování a následná serializace query mohou změnit její zápis. Proto není rozumné nahrazovat všechny řetězce vlastním odhadem ještě před zjištěním pravidel aplikace.

Například dvě hodnoty stejného parametru nemusí znamenat totéž co jedna poslední hodnota. Aplikace může seznam zpracovat jako více voleb, první hodnotu nebo jiným způsobem. Nezjednodušujte takový případ podle toho, co je nejpohodlnější v tabulkovém programu. Předlohou má být potvrzené chování, které chcete při migraci zachovat nebo vědomě změnit.

Původní zápis a schválené rozhodnutí evidujte odděleně. Vedle zdrojové URL můžete mít poznámku o významu parametrů a skupině podobných variant. Tím získáte přehled bez ztráty přesného vstupu. Není nutné ničit původní řetězec, abyste dokázali adresy pracovně seskupit.

Připravte testovací případy místo neurčitého „parametry zahodit“

Předání vývojáři má určit očekávané chování pro reprezentativní kombinace. U modelového hrnku nestačí příklad s jedinou modrou URL. Zahrňte červenou variantu, obecný detail, obrácené pořadí i nepodporovanou hodnotu. Pro poslední případ nejprve rozhodněte, co má uživatel dostat; článek univerzální náhradu nevymýšlí.

Pro evidenci můžete použít postup zápisu SEO nálezů a pracovní šablony. Ke každé výjimce připojte konkrétní příklad, osobu potvrzující význam a očekávaný výsledek. Neoznačujte implementaci za ověřenou pouze podle toho, že bylo nahrané nové CSV.

Hodnotu parametru nerozdělujte podle toho, jak vypadá na první pohled

Při ruční práci se hodí rozlišovat oddělovač mezi parametry a zakódovaný znak uvnitř hodnoty. Zápis %26 může představovat ampersand jako součást hodnoty. Pokud ho bez znalosti kontextu nahradíte běžným znakem &, může se z jedné hodnoty stát další část query. Podobný zásah už není kosmetické čištění tabulky, ale změna popisu požadavku.

Nemusíte kvůli tomu napsat vlastní parser. Uchovejte původní URL, použijte standardní nástroje k jejímu rozebrání a výsledek porovnejte s očekáváním aplikace. Při nejasnosti předejte konkrétní vstup technikovi. Ruční nahrazování všech podobných znaků v celém sloupci snadno zasáhne i případy, které jste při přípravě vůbec nezamýšleli řešit.

Další vrstvou je formát CSV. Je-li oddělovačem čárka a hodnota ji obsahuje také, musí export zajistit odpovídající uvozovky. Vlastní příklady článku používají středník, takže obyčejný ampersand uvnitř URL nový sloupec nevytváří. Po exportu si přesto otevřete několik konkrétních řádků a zkontrolujte, že zdroj, cíl a kód zůstaly ve správných polích.

Co porovnat po opětovném otevření souboru

Vyberte si několik citlivých případů ještě před předáním: obrácené pořadí parametrů, hodnotu s kódovaným znakem a známou produktovou variantu. Po exportu a opětovném otevření porovnejte celý řetězec se schváleným podkladem. Souhlas názvu produktu nestačí, pokud se změnila hodnota vybírající jeho provedení.

Pokud se nález objeví až po převodu tabulky, zaznamenejte, ve kterém kroku se hodnota změnila. Můžete mít správné obsahové rozhodnutí a současně poškozený předávaný soubor. Oprava potom patří do exportního postupu, ne do nového výběru cílové stránky. Tato informace pomůže zabránit návratu stejné chyby při další aktualizaci mapy.

Do pracovních podkladů nepřenášejte přístupové hodnoty

Skutečná query může obsahovat osobní údaje nebo hodnotu, která umožňuje přístup k neveřejné stránce. Pro veřejný příklad takový údaj nepoužívejte. Interní postup má určit, kdo může původní podklad vidět a jak vytvořit potřebný bezpečný testovací případ bez zveřejnění jeho hodnoty.

Naše nástroje zpracovávají vložené texty v prohlížeči a nekontaktují cílové adresy. Přesto to není důvod kopírovat do každé poznámky celé provozní URL bez rozmyslu. Do veřejně sdíleného zadání obvykle stačí modelový příklad a popsaný význam; přesný citlivý podklad může zůstat v odpovídajícím interním prostředí.

Cvičení: parametr vypadá měřicí. Může automaticky zmizet?

Najdete dvě adresy lišící se jen parametrem ref. Můžete je bez další kontroly sloučit?

Samotný název nestačí. Zjistěte, zda ref pouze označuje zdroj návštěvy, nebo zda aplikace podle něj vybírá obsah, partnera či jiný stav. Potom rozhodněte o cílové URL a měření. Pokud je shoda potvrzená, lze ji promítnout do konkrétního zadání. Nástroj takové rozhodnutí z názvu parametru neodvodí.

U dalšího exportu nejprve zachovejte úplné adresy, rozdělte parametry podle doloženého významu a připravte reprezentativní případy. Až potom sestavujte pravidla a případné sjednocování variant. Výsledek má být přehledný díky popsaným rozhodnutím, nikoli díky odstranění informací, které byly pro správné přesměrování potřebné.

Časté otázky

Mohu z mapy odstranit vše za otazníkem?

Jen pokud máte doloženo, že tím neztratíte význam rozhodující pro cíl. Parametry mohou vybírat produkt, variantu, jazyk nebo stav seznamu. Měřicí označení posuzujte zvlášť a sladěte také očekávání měření.

Považuje nástroj jiné pořadí parametrů za stejnou URL?

Neprovádí vlastní přerovnání query. Dva zápisy s odlišným pořadím proto mohou vyžadovat samostatné rozhodnutí v inventáři. Jejich obsahovou shodu musí potvrdit chování konkrétní aplikace, nikoli podobnost textu.

Jaké případy předat k testu parametrů?

Zahrňte známé odlišné varianty, obrácené pořadí, chybějící či neznámou hodnotu a případné měřicí označení. U každého nejprve stanovte očekávaný výsledek. Prosté CSV nesimuluje podmínky implementované na serveru.