Tämän ohjeen avulla luot ja ylläpidät AI Commerce‑kaupan URL‑uudelleenohjauksia. Redirect Manager mahdollistaa yksittäiset sekä massana tuodut (CSV) ohjaukset, joita tarvitset esimerkiksi migraatiossa tai sivuston rakenne­muutoksissa. Oikein tehdyt redirectit säilyttävät hakukonenäkyvyyden ja asiakkaiden linkit toimivina.

Mikä on URL‑uudelleenohjaus ja mitä sen pitäisi tehdä

URL‑uudelleenohjaus (redirect) ohjaa käyttäjän ja hakukoneen vanhasta polusta uuteen polkuun. Redirect on hyödyllinen silloin, kun URL on pakko muuttaa, mutta haluat säilyttää vanhojen linkkien toimivuuden (asiakkaiden tallennetut linkit, hakukoneiden indeksit, ulkoiset linkitykset ja markkinointikanavat).

• Hyvä redirect ohjaa aina sisällöllisesti vastaavaan kohteeseen (ei “sinne päin” tai kaikkia vanhoja URL:eja etusivulle).
• Hyvä redirect on mahdollisimman suoraviivainen: vanha → uusi (ei usean hypyn ketjua).
• Redirect on kompromissi: se pelastaa vanhan URL:n, mutta jokainen ohjaus on ylimääräinen välietappi. Siksi redirecteja tehdään vain, kun URL todella muuttuu.
• Redirect ei ole tarkoitettu “sisäisen navigaation työkaluksi”: kun URL on vaihdettu, pyri päivittämään myös kaupan omat linkit (valikot, nostot, sisäiset linkitykset), jotta asiakkaat eivät kierrä redirectien kautta.

Käytännössä SEO‑mielessä pysyvä uudelleenohjaus (yleisesti HTTP 301) on tavallisin valinta pysyville muutoksille, ja tilapäinen ohjaus (esim. HTTP 302) tilapäisille tilanteille. AI Commerce‑kaupassa Redirect Managerin kautta luodut ohjaukset kannattaa aina varmistaa pistokokeella selaimessa, jotta näet käytännössä, että ohjaus vie oikeaan paikkaan.

URL‑vakaus ennen kaikkea

Tärkein periaate on, että tuotteen nimen muuttaminen ei automaattisesti tarkoita URL‑osoitteen muuttamista. SEO‑näkökulmasta URL‑osoitteet pyritään pitämään vakaina mahdollisimman pitkään, ja URL muutetaan vain silloin, kun siihen on selkeä liiketoiminnallinen tai tekninen syy (esim. harhaanjohtava tai virheellinen osoite).

• Tuotteen URL on käytännössä “kovempi” tunniste kuin nimi.
• URL‑muutokset kannattaa tehdä harkiten ja mieluiten kerran (tai ei lainkaan).
• E‑commerce‑reititys pidetään kanonisena: tuotteiden URL:it eivät lähtökohtaisesti elä kategoriasiirtojen mukana.
• Nimi, markkinointitermit ja kuvaukset voivat elää ajan myötä, mutta slug/URL‑polku kannattaa pitää mahdollisimman vakaana, jotta vältyt redirect‑ketjuilta ja linkkien pirstoutumiselta.
• URL‑muutosta kannattaa ajatella “viimeisenä keinona”: jos muutat URL:n usein, redirecteja kertyy paljon ja niiden optimointi muuttuu nopeasti ylläpitotyöksi.

Taustalla on käytännön todellisuus: URL‑polku voi olla linkitetty hakukoneissa, uutiskirjeissä, somepostauksissa, kumppanien sivuilla ja asiakkaiden omissa kirjanmerkeissä. Mitä vakaampi URL‑strategia, sitä vähemmän tarvitset redirectejä ja sitä pienempi on riski, että redirectit muodostavat ketjuja tai silmukoita.

Milloin URL‑muutos on perusteltu

• URL on selvästi virheellinen tai harhaanjohtava (esim. väärä tuotenimi, kirjoitusvirhe, väärä kieli).
• Rakenneuudistus tai migraatio, jossa URL‑polut muuttuvat hallitusti ja suunnitellusti.
• Tekninen pakko, esimerkiksi jos vanha polkurakenne ei enää ole yhteensopiva uuden reitityksen tai sisällön kanssa.

Kun URL on pakko vaihtaa

1. Suunnittele uusi polku niin, että se on mahdollisimman pysyvä (et joudu muuttamaan sitä uudelleen pian).
2. Toteuta ohjaus vanhasta polusta uuteen (Redirect Managerilla tai automaation kautta URL‑muutoksen yhteydessä).
3. Varmista, ettei synny ketjua (A → B → C), vaan ohjaus menee suoraan uusimpaan kohteeseen.
4. Päivitä kaupan omat linkit ja mahdolliset markkinointilinkit uuteen osoitteeseen, jotta redirecteja ei käytetä turhaan.
5. Seuraa vaikutuksia (esim. Google Search Console) ja tee tarvittaessa korjauksia Redirect Managerissa.

Mistä editoidaan Redirect Manager

1. Avaa Hallintapaneeli.
2. Valitse Tools > Redirect Manager.

Uuden uudelleenohjauksen luominen

1. Napsauta Create Redirect.
2. Syötä url_old (vanha polku) ja url_new (uusi polku). Riittää, että polku alkaa kauttamerkillä (/) tai ilman, kunhan käytät samaa logiikkaa kuin muissa ohjauksissa.
3. Tallenna ohjaus.
4. Tee pistokoe selaimessa ja varmista, että ohjaus toimii.

Konsultatiivinen tarkistuslista ennen tallennusta:

• Varmista, että url_old on juuri se polku, johon liikennettä oikeasti tulee (muista mahdolliset kirjainkoot, erikoismerkit ja vaihtoehtoiset muodot).
• Varmista, että url_new on sisällöllisesti paras vastine. Redirectin tarkoitus ei ole “piilottaa” puuttuvaa sisältöä, vaan ohjata järkevästi.
• Jos samaa sisältöä on muutettu useaan kertaan, pyri oikaisemaan mahdollinen ketju: ohjaa vanhin URL suoraan uusimpaan.
• Tee pistokoe sekä selaimella että (tarvittaessa) useammalla vanhalla URL‑variantilla, jotta näet, ettei synny yllättäviä ketjuja tai silmukoita.

Massauudelleenohjaukset CSV:llä

1. Valitse CSV Export Redirect, jotta saat nykyiset redirectit Excel/CSV‑muotoon.
2. Muokkaa tai lisää rivejä paikallisesti. Käytä sarakkeita url_old ja url_new.
3. Tuo tiedosto takaisin Import-toiminnolla. CSV tuo ja ylikirjoittaa, mutta ei poista ohjauksia.
4. Varmista muutosten toimivuus avaamalla muutama tärkeä URL selaimessa.

Hyvät käytännöt massamuutoksissa

• Tee ensin pieni testierä ja varmista toiminta ennen kuin tuot tuotantoon tuhansia rivejä.
• Pidä huoli, että jokaiselle vanhalle URL:lle on selkeä vastine. Migraatiossa tai rakenneuudistuksessa kannattaa tehdä etukäteen listaus “vanha → uusi” ja varmistaa, ettei ohjauksia synny päällekkäin tai ristiin.
• Vältä muuttamasta samoja URL‑kohteita useita kertoja lyhyen ajan sisällä: tämä kasvattaa riskiä, että syntyy redirect‑ketjuja (A → B → C) tai jopa silmukoita.
• Huomioi, että redirectien rakentuminen voi kestää hetken, erityisesti jos taustalla muodostuu automaattisia ohjauksia (katso “Tausta‑ajo” ja läpäisyrajat). Suunnittele massamuutokset niin, että järjestelmällä on aikaa käsitellä pending‑rivit.
• Säilytä aina CSV‑export varmuuskopiona, jotta pystyt palaamaan tarvittaessa edelliseen redirect‑karttaan.

Esimerkkidata CSV:stä

Automaatiikan toiminta (tarkennettu koodista)

AI Commerce tekee osan URL‑uudelleenohjauksista automaattisesti silloin, kun tuotteiden tai kategorioiden URL‑polut oikeasti muuttuvat. Automaatiot on tarkoituksella rajattu varovaisesti: tavoitteena on estää tilanteet, joissa esimerkiksi massapäivitykset tai toistuvat URL‑muutokset synnyttävät tahattomia “redirect‑myrskyjä” ja pitkiä ketjuja.

UI‑muokkaukset (categories.php)

• Tuote: redirect merkitään (redirect_status = 1) vain, kun vanha URL ja uusi URL ovat molemmat ei‑tyhjiä ja eri arvoisia.
• Tuote: kun URL oikeasti muuttuu, nykyinen URL siirretään kenttään products_url_old.
• Tuotteen nimen muutos yksin ei automaattisesti tee redirectiä, jos URL pidetään ennallaan (tämä on tarkoituksellista URL‑vakauden kannalta).
• Tuote: jos tuotteen URL‑kenttä on tyhjä ja URL muodostetaan järjestelmässä nimestä (tai muusta automaatiosta), nimen muutos voi johtaa uuden URL‑polun muodostumiseen. Tällöin redirect syntyy URL‑muutoksen perusteella (ei pelkän nimen muutoksen vuoksi).
• Kategoria: vastaavasti redirect merkitään, kun vanha ja uusi kategoriapolku/URL eroavat; tällöin vanha polku talletetaan categories_path_old‑kenttään.

CSV‑tuonnit

• Tuotteet: jos CSV‑rivillä on products_name tai products_url ja arvo muuttuu, järjestelmä merkitsee rivin pending‑tilaan (redirect_status = 1) ja kopioi nykyisen URL:n kenttään products_url_old.
• Kategoriat: jos categories_name muuttuu CSV‑päivityksessä, järjestelmä merkitsee pending‑tilan ja kopioi nykyisen polun kenttään categories_path_old.
• Pending‑merkintä ei tarkoita automaattisesti sitä, että redirect syntyy välittömästi: redirect rakennetaan taustalla vasta, kun uusi polku/URL on tiedossa ja se on eri kuin vanha (old==new voidaan ohittaa käsittelyssä).
• Jos URL‑polku on tarkoituksella pidetty vakaana, suositus on, että CSV‑päivityksissä keskityt nimen ja sisällön muutoksiin ilman URL‑muutoksia. Tämä vähentää riskiä, että massapäivityksistä syntyy suuri määrä redirectejä.

Monikieliset polut ja polun nollaaminen

Monikielisessä kaupassa URL‑polkuja voi syntyä ja päivittyä myös kielikohtaisesti. Tämän vuoksi järjestelmä käsittelee tietyt muutokset hallitusti: redirectiä ei voi luoda ennen kuin järjestelmä tietää varmasti, mikä on uusi kohdepolku.

• Jos vieraskielinen polku nollataan (huom: polku, ei pelkkä tuotteen nimi), järjestelmä voi merkitä URL:n muuttuneeksi/pending‑tilaan.
• Redirect astuu voimaan vasta, kun käännöspalvelu (tai vastaava taustaprosessi) on muodostanut uuden polun. Pelkkä polun nollaaminen ei vielä riitä, koska kohde‑URL:ia ei ole silloin vielä olemassa.
• Tämä on tarkoituksellinen suojaus: se vähentää riskiä, että syntyy ohjauksia “tyhjään” tai väärään kohteeseen. Käytännössä tämä voi tarkoittaa sitä, että muutoksissa on viivettä ennen kuin ohjaus näkyy ulospäin.

Tausta-ajo (RedirectsCron)

• Tausta-ajo käsittelee vain pending‑rivit (redirect_status = 1).
• Käsittelyjärjestys: ensin kategoriat, sitten tuotteet.
• Maksimi on 100 riviä per ajo (ei kiinteästi “100/min”).
• Läpäisy riippuu ajotiheydestä (esim. 2 min välein ajettaessa enintään ~50 riviä/min).
• Redirectit kirjoitetaan S3:een yksi kerrallaan.
• Onnistuneen käsittelyn (tai old==new‑skipin) jälkeen rivi merkitään valmiiksi (redirect_status = 0).
• Suurissa massamuutoksissa redirectien valmistuminen voi kestää useita ajoja. Tämä on odotettua, koska ohjaukset kirjoitetaan S3:een yksitellen ja käsittelyä on rajattu hallittavuuden vuoksi.
• Jos samaa URL:ia muutetaan useaan kertaan ennen kuin tausta-ajo ehtii käsitellä edellisen pending‑tilan, riski redirect‑ketjuille kasvaa. Siksi suositus on tehdä URL‑muutokset vaiheittain ja varmistaa tulokset ennen seuraavaa erää.

Miksi Redirect Manager on edelleen tärkein työkalu

• Automaatiot eivät optimoi redirect‑ketjuja liiketoiminnan puolesta.
• Redirect Managerilla voit poistaa turhat ohjaukset ja oikaista ketjut (vanhin URL suoraan uusimpaan).
• Tämä ehkäisee “redirect‑myrskyjä” ja pitkiä ketjuja, jotka heikentävät ylläpidettävyyttä ja SEO‑laatua.
• Suositus säilyy: vältä URL‑muutoksia, tee redirectit harkiten, ja tarkista vaikutukset esim. Search Consolesta.
• Redirect Manager on käytännössä “konsultatiivinen työpöytä”: kun ohjauksia on kertynyt paljon (esim. useiden CSV‑ajojen jälkeen), Redirect Managerilla voit siivota tilanteen — oikaista ketjut, poistaa tarpeettomat ohjaukset ja varmistaa, että vanhimmat URL:t ohjaavat suoraan uusimpiin.
• Automaatiot tekevät ohjauksia varovaisesti ja vain tietyissä olosuhteissa. Redirect Managerilla käsittelet poikkeustilanteet ja varmistat, että redirect‑kartta vastaa kaupan todellista tavoitetta.

Redirect‑ketjut ja silmukat: miksi niitä kannattaa välttää

Redirect‑ketju syntyy, kun URL:ia muutetaan useampaan kertaan ja ohjaukset jäävät “päällekkäin” (esim. A → B ja myöhemmin B → C). Silmukka syntyy, jos ohjaus palaa takaisin aiempaan osoitteeseen (esim. A → B → A) tai ohjaa käytännössä itseensä.

• Ketjut lisäävät latausviivettä ja kuluttavat hakukoneiden crawl‑budjettia.
• Ketjut voivat heikentää SEO‑signaalien siirtymistä (ja tekevät vianetsinnästä hankalampaa).
• Silmukat voivat estää sivun avautumisen kokonaan, mikä näkyy asiakaskokemuksessa sekä hakukoneiden virheraporteissa.

Paras käytäntö on oikaista ketjut: ohjaa aina vanhin URL suoraan uusimpaan. Tämä on myös keskeinen syy, miksi Redirect Manager on tärkeä työkalu automaation rinnalla.

PIM ja ulkoiset järjestelmät (esim. Akeneo)

URL‑osoitteet kuuluvat kaupan routing‑ ja SEO‑logiikkaan. Siksi PIM‑järjestelmien ei yleensä pidä ohjata URL‑hallintaa automaattisesti. Tämä vähentää riskiä, että massamuutoksista syntyy tahattomia redirect‑ketjuja.

Käytännön hyöty: tuotteita voidaan nimetä uudelleen ulkoisissa järjestelmissä ilman, että URL‑strategia rikkoutuu automaattisesti.

Tämä on ennen kaikkea käytännön rajoite, ei pelkästään tekninen: ulkoinen järjestelmä ei tunne kaupan URL‑strategiaa, reitityssääntöjä, kielikohtaisia polkuja tai sitä, milloin URL‑muutos on liiketoiminnallisesti perusteltu. Jos ulkoinen järjestelmä alkaisi muuttaa URL‑polkuja käyttäjän selän takana, seurauksena voi olla “redirect‑myrsky”, jossa ohjauksia syntyy kymmeniä tuhansia ja niistä muodostuu ketjuja.

• Suositus integraatioissa: PIM hallinnoi tuotteen nimeä ja attribuutteja, mutta kauppa hallinnoi URL‑polkua/slugia.
• Jos URL‑muutoksia on pakko synkronoida ulkoisesta järjestelmästä, tee se hallitusti ja erissä, ja seuraa vaikutuksia (esim. Search Console) sekä siivoa ketjut tarvittaessa Redirect Managerissa.

Lisävinkit

• Kaikki nimi‑ tai sisältömuutokset eivät tarkoita URL‑muutosta; pidä slugit vakaina aina kun mahdollista.
• CSV ei voi poistaa redirectejä; poista tarpeettomat ohjaukset käyttöliittymässä.
• Cross‑domain‑ohjaukset eivät ole sallittuja (esim. boeing.com → airbus.com).
• Käytä yhtenäistä polkumuotoa (esim. kaikki polut alkavat /‑merkillä) kuten CSV Exportissa.
• Tee aina pistokokeet muutosten jälkeen varmistaaksesi, että ohjaukset toimivat odotetusti.
• Vältä “kaikki etusivulle” ‑ohjauksia: jos vanhalle URL:lle ei ole järkevää sisällöllistä vastinetta, redirect ei välttämättä ole paras ratkaisu. Tällöin voi olla parempi, että sivu palauttaa 404/410 (tämä riippuu tilanteesta ja strategiasta).
• Jos sinulla on paljon ohjauksia, tarkista säännöllisesti mahdolliset ketjut ja oikaise ne: tavoitteena on, että jokainen vanha URL ohjaa suoraan lopulliseen kohteeseen.
• Huomioi erikoismerkit ja eri kirjoitusmuodot (esim. bj%c3%b6rn vs björn). Tarvittaessa ohjaa erikseen ne muodot, joita oikeasti esiintyy liikenteessä.
• Seuraa redirectien vaikutuksia ja virheitä esimerkiksi Google Search Consolessa (uudelleenohjaukset, 404‑löydökset, indeksointivirheet) ja tee siivous/optimointi Redirect Managerissa tarpeen mukaan.

Yhteenveto

Redirect Manager on ensisijainen työkalu uudelleenohjausten hallintaan. Automaatiot auttavat, mutta niitä käytetään tarkoituksella varovaisesti: URL‑muutoksia vältetään, pending‑redirectit rakennetaan taustalla hallitussa tahdissa, ja ketjujen optimointi tehdään tarvittaessa Redirect Managerissa.

Kokonaisstrategia on yksinkertainen: pidä URL:t vakaina, tee URL‑muutoksia vain perustellusti, ja kun redirecteja syntyy, pidä ne tarkoituksenmukaisina, suorina ja siisteinä (ei ketjuja, ei silmukoita). Näin varmistat sekä hyvän asiakaskokemuksen että parhaan mahdollisen SEO‑laadun.