Blog Redirect audit nagy site-ok esetében Wayback Machine API segítségével
írta:

Redirect audit nagy site-ok esetében Wayback Machine API segítségével

Már többször futottam bele abba, hogy amikor egy évek óta meglévő weboldalon kell dolgozni, akkor mindenféle turpisságok jönnek elő. Gyakran előfordul, hogy komoly hibákat görgetnek maguk előtt, de ezekre nem mindig derül fény. Most egy olyan megoldásról írtam, ami ezeket segíthet részben felgöngyölíteni.

Tegyük fel, hogy van egy nagy site, ami több design váltáson és migráción is átesett már. Hogy lehet itt hatékonyan auditot csinálni?

Ráadásul sokszor fogalmunk sincs az oldal előéletéről, mert a migráció (legyen az domain, design, tartalom vagy épp CMS migráció) az előtt történik, hogy mi a cégnél lettünk volna. Vagy más szakértő dolgozott a projekten.

Fontos megemlíteni, hogy ez a technika főként ott működik hatékonyan, ahol:

  • legalább egy, de akár több migráció is volt az évek során
  • már létező, nagyobb oldalakról van szó.

Ennek ellenére kisebb és újabb oldalaknál is lehet használni, de a potenciális hatás sokkal kisebb.

Miről szól ez a megoldás?

Ellenőrizzük a WayBack Machine által logolt korábbi tartalmakat és URL-eket egy audit során. Majd fixáljuk azokat az elemeket (főként redirect problémákat), amikre szükségünk van.

Konkrét példa

A thepitch.hu 2013-ban indult útnak. Majd átesett 2015 végén egy design és tartalom migráción. Majd 2018-ban egy https / domain migráción.

Menet közben több URL megszűnt, sokat átirányítottunk, de azért 5 év alatt bőven követhettünk el hibákat.

Gyakori hibák

  • Nem lett minden URL megfelelően átirányítva (404-es oldalba futunk)
  • Nem a megfelelő URL-re irányít át valamilyen tartalom
  • Redirect chainek jöttek létre (ahol A átirányít B-re, majd B átirányít C-re és így tovább, ahelyett hogy A egyből C-re irányítana át mondjuk)
  • Redirect loop jön létre (A redirectel B-re, majd B átirányít A-ra)
  • 302 redirectet használtunk 301 helyett

És így tovább.

De ezeket nem szükséges manuálisan végignézni, lehet automatizálni. Ehhez a következő lépéseket kell tenni.

1. WayBack Machine API

A WayBack Machine API-t használva le tudjuk gyűjteni egy adott domainhez kapcsolódó összes URI-t (Uniform Resource Identifier-t), amik között ott lesznek a számunkra szükséges URL-ek is.

A WayBack Machine CDX Server API dokumentációját itt találod. Nekünk jelen esetben az alábbi URL-re van szükségünk, hogy kinyerjük a thepitch.hu adatait.

https://web.archive.org/cdx/search/cdx?url=thepitch.hu&matchType=domain&fl=original&collapse=urlkey&limit=100000

Így néz ki az output a böngészőben.

Néhány modifier és paramatér, amit érdemes használni:

  • &matchType=domain: visszaadja az összes találatot a domainről és subdomainről (nem csak az adott URL-t)
  • &fl=original: csak az URI-kat kapom vissza, a többi infot tartalmazó oszlopot kiszűri
  • &collapse=urlkey: kiszűri a duplikált URI-ket
  • &limit=100000: limitálja a listát 100,000 sorra

Az utolsó paraméterre jelen esetben nincs szükség, mert a The Pitch nem volt soha ekkora oldal, de jó tudni ezt a paramétert is, ha óriási weboldallal van dolgunk.

2. URI Cleanup

Az URI egy nagyobb halmaz, mint az URL (Uniform Resource Locator). Minden URL URI, de nem minden URI URL.

Nekünk jelen esetben elég csak annyit tudni, hogy az API-ból megkapott adatokat érdemes egy kicsit tisztítani. Ebben ugyanis lesznek javascript file-ok, hibás URL-ek, stb. Ezektől meg kell tisztítani a listát, hogy csak a hasznos URL-eket kapjuk vissza. Ez ideális esetben pár perces munka.

Erre azért van szükség, mert felesleges és hibás adatot nincs értelme tovább vinni a folyamatban.

A tisztítást Excelben, Google Sheetben is el lehet végezni, nem szükséges hozzá semmilyen komolyabb eszköz.

3. Screaming Frog Setup (follow redirects)

A tisztított listát a Screaming Frogban fogjuk majd elemezni. Itt először be kell állítani egy fontos dolgot. Azt akarjuk, hogy az URL-ek elemzése során a redirecteket nézze végig a rendszer. Ezért a Configuration / Search / Advanced fül alatt be kell állítani az “Always Follow Redirects” pontot.

4. Screaming Frog List Crawl

Lista módra állunk át.

Feltöltjük a tisztított URL táblát.

Majd elindítjuk a crawlert.

Lista elemszámtól függően pár másodperc vagy pár perc alatt végez is a rendszer.

5. Redirect Chain Check

A redirect chain reportot a Reports / Redirect Chains fül alatt talájuk. Ha vannak ilyenek az oldalon, akkor azokat érdemes javítani.

A gyakorlatban itt az történik, hogy A url átirányít B-re, majd B a C-re és akár így tovább. Azt kell kibogozni, hogy melyik a kiinduló URL (start url) és a cél URL (destination URL). Ha ezt megtettük, akkor köztük lévő átirányítást kell beállítani, és a többit meg kell szüntetni.

6. Redirect Fixek

Ezen felül persze más hibák is előfordulhatnak:

  • 404-es hibakód: itt 301 redirectet kell beállítani egy megfelelő oldalra
  • 302-es státuszkód: felül kell vizsgálni, hogy nem 301-et érdemes-e használni (valószínűleg igen)
  • 301-es státuszkód: valóban jó oldalra visz át az átirányítás?
  • 500-as státuszkód: szerverhiba, ellenőrizni kell, hogy mi itt a probléma

És így tovább.

Nálam így nézett ki ezeknek az oldalaknak a megoszlása.

Ezzel a megoldással viszonylag gyorsan és hatékonyan lehet auditálni korábbi migrációkat. Ez azért is különösen jó, mert anélkül tudunk információt szerezni az adott domainről, hogy dolgoztunk volna a cégnél vagy a cégnek, amikor a korábbi weboldal verzió volt életben.

Akár évekre visszamenőleg is javítani lehet olyan elemeket, amikre korábban nem figyeltek kellően oda.

Ahogy a cikk elején is írtam, ez a megoldás inkább több, de legalább egy migráción átesett oldal esetében igazán hasznos. És minél nagyobb egy oldal, annál több hasznos információt tudunk kinyerni ebből az elemzésből és auditból.

De mint a példa mutatja, egy The Pitch méretű oldalnál is lehet bőven javításra szoruló elemeket találni.


Hozzászolások

Moderáld magad – vagy mi fogunk. :)
Na jó, nem fogunk, szóval csak ésszel!