Ověřte celý proces pokladny od začátku do konce, v reálných podmínkách
Proveďte kompletní nákup sami na živém webu — ne na testovacím prostředí — a projděte cesty, které zákazníci skutečně používají: pokladnu jako host i pokladnu po přihlášení, alespoň jeden produkt s variantami a jakékoli aktuálně platné slevové kódy nebo akce. Zkontrolujte, že se e-maily s potvrzením objednávky odesílají správně a že se objednávka poté správně zobrazí ve vaší administraci/systému objednávek.
Nepředpokládejte, že se pokrytí z testovacího prostředí automaticky přenese. Živé platební brány, živé daňové služby a živá API pro dopravní sazby se někdy chovají jinak než jejich testovací nebo sandboxové obdoby, a přesně proto je potřeba skutečná kontrola v živých podmínkách, ne spoléhání na to, co prošlo na testovacím prostředí.
Potvrďte, že platební brány jsou plně živé a správně nakonfigurované
Ověřte, že zpracování plateb běží v živém (ne testovacím/sandboxovém) režimu, že jsou zapnuté a funkční všechny platební metody, které obchod dřív podporoval, a že se skutečná transakce od začátku do konce správně vypořádá — že peníze skutečně dorazí, ne že se jen změní stav objednávky. Zkontrolujte i funkčnost vratek, protože se používá méně často než pokladna a snadno se na ni zapomene.
Pokud podporujete více platebních metod nebo měn, otestujte každou zvlášť, místo abyste předpokládali, že když funguje jedna metoda, ostatní jsou nastavené stejně.
Zkontrolujte pravidla daní a dopravy na skutečných objednávkách
Logika daní a dopravy se při migraci snadno jemně pokazí, protože obojí často závisí na konfiguraci, která se mezi platformami nemapuje čistě. Zadejte testovací objednávky do svých nejběžnějších destinací dopravy a potvrďte, že se daň počítá správně a že sazby a dostupné metody dopravy odpovídají tomu, co jste zamýšleli — ne jen tomu, co nová platforma nastavila jako výchozí.
Zvláštní pozornost věnujte jakýmkoli speciálním případům, na kterých váš byznys závisí: daňovým výjimkám, prahům pro dopravu zdarma, regionálně specifickým pravidlům nebo omezením dopravy u určitých produktů. Přesně tyto detaily konfigurace se při migraci nejsnáze ztratí nebo nastaví na výchozí hodnotu nesprávně.
Namátkově zkontrolujte přesměrování, ne jen ta, na která si vzpomenete
I s kompletní mapou přesměrování sestavenou před spuštěním po přechodu namátkově zkontrolujte skutečný vzorek URL adres: vaše stránky s nejvyšší návštěvností, hrstku s nižší návštěvností a několik záměrných výjimek (ukončené produkty, sloučené kategorie). Potvrďte, že se každá přesměrovává na správný cíl jedním skokem, bez řetězení nebo smyček.
Zkontrolujte také vzorek URL adres, které by na starém webu neměly existovat — překlepy, staré URL adresy založené na parametrech, cokoli, co mohl prohledávač náhodně zaindexovat —, abyste se ujistili, že se rozlišují rozumně, ne s chybou, která by vypadala jako širší problém.
Potvrďte kontinuitu analytiky a sledování
Ověřte, že vaše analytická platforma, sledování konverzí a jakékoli reklamní pixely na novém webu správně odesílají data — zadaná testovací objednávka by se měla objevit ve vaší analytice a reportech reklamní platformy stejně jako dřív. Sledovací kód se při změně platformy snadno potichu ztratí, protože chybějící nebo špatně nastavený pixel nevyvolá chybovou hlášku; jen přestane odesílat data.
Porovnávejte první čísla z analytiky po spuštění s výchozím stavem před migrací pro stejný typ dne (všední den vs. víkend, podobné zdroje návštěvnosti), ne s hrubým porovnáním před/po, protože normální výkyvy návštěvnosti jinak mohou skutečný problém se sledováním zamaskovat nebo napodobit.
Zkontrolujte přístup k zákaznickým účtům a historii objednávek
Nechte pár skutečných (nebo testovacích) zákaznických účtů potvrdit, že se dokážou přihlásit, vidí správnou historii objednávek a mají přístup ke všem funkcím účtu, na které byli zvyklí — uložené adresy, uložené platební metody tam, kde jsou relevantní, věrnostní nebo bodové zůstatky, pokud je váš obchod má. Problémy s přístupem k účtu jsou pro zákazníky, kteří na ně narazí, velmi viditelné a přímo ovlivňují důvěru, takže stojí za záměrné ověření, ne za předpoklad, že migrace účtů „asi fungovala“.
Pokud migrace hesel nebyla součástí technického přenosu (běžné, když platformy používají nekompatibilní hashování hesel), ujistěte se, že zákazníci mají jasnou cestu k obnovení hesla a že je o ní informujete, ne že je jen technicky dostupná.
Sledujte pokrytí v Search Console i v následujících týdnech
Sledujte Search Console (nebo obdobu pro jiné vyhledávače) i dlouho po dni spuštění — chyby procházení, stav indexace a jakýkoli nárůst hlášených chyb 404 jsou nejranější signály problému s přesměrováním nebo kanonickou značkou, který testování nezachytilo. Porovnávejte to s výchozím stavem před migrací, abyste dokázali rozlišit skutečnou regresi od normálního krátkodobého výkyvu po změně webu.
Toto sledovací období je také chvíle, kdy stojí za to znovu odeslat mapu webu, pokud jste to ještě neudělali, a potvrdit, že stránky, u nichž očekáváte indexaci, se v následujících týdnech skutečně objevují ve výsledcích vyhledávání, ne jen že jsou procházené.
Časté otázky
Jak dlouho by mělo pokračovat testování po spuštění?
Aktivní, denní kontrola obvykle záleží nejvíc první jeden až dva týdny, kdy vyplave většina problémů s konfigurací a přesměrováním. Opětovná indexace vyhledávači a stabilizace vzorců návštěvnosti trvá déle, takže lehčí sledování (Search Console, trendy v analytice) se vyplatí udržovat déle — běžné je několik týdnů — místo aby se zastavilo, jakmile první týden vypadá čistě.
Co je jednoznačně nejdůležitější zkontrolovat hned po spuštění?
Skutečný, živý test pokladny a plateb, protože přímo ovlivňuje tržby a je to jediný proces, kterého se dotkne úplně každý zákazník. Na problémech s přesměrováním a sledováním také záleží, ale rozbitá pokladna je nejnákladnější problém, který lze nechat neodhalený i jen na pár hodin.
Je normální, že pozice ve vyhledávání hned po migraci lehce poklesnou?
Určitý krátkodobý výkyv je běžný i u dobře provedené migrace, protože vyhledávače potřebují čas na opětovné procházení a vyhodnocení nových URL adres. Co normální není, je trvalý pokles nebo nárůst chyb procházení — to je signál zkontrolovat mapu přesměrování a kanonické značky kvůli skutečné chybě, ne to jen vyčkat.
Kdo v týmu by měl mít testování po spuštění na starosti?
Ideálně někdo s přehledem napříč celým obchodem, ne jen technický migrační tým — protože u několika z těchto kontrol (jestli daňová pravidla sedí, chování zákaznického účtu, jestli čísla ve sledování vypadají normálně) pomáhá byznysový kontext, ne jen technické ověření, že daná funkce existuje.