Már közel egy éve átálltunk a thepitch.hu bloggal http-ről https protokollra. A https migráció során az összes szempontot összeírtam, amire oda kell figyelni. Beállítottam az átirányításokat, legeneráltam az új sitemapet, beküldtem Google Search Consoleba, de néhány http URL csak nem akart eltűnni a Google találati listáról. Ekkor indítottam hajtóvadászatot ellenük. Amiből a végén egy jó kis A/B teszt lett.

A kiindulópont

Sikeres domain migráció

Annak idején megtörtént a http-https átállás. A http verzión még voltak tag (címke) oldalak, de ezeket az új verzióra már nem hoztam át. Két okból:

1. a címkék nem jelentek meg a blog felületén vizuálisan, így nem segítették a tematikus csoportosítást / navigációt
2. Google Search Consoleban és analitikában azt láttam, hogy ezekre nagyjából zéró organikus forgalom jön

Innentől kezdve nem volt értelme megtartani őket. Ezért megszüntetésre kerültek. Az új sitemapbe már be se kerültek így, és nem is hoztam létre tag-sitemap.xml-t sem. Link sem mutatott rájuk, tehát nagyjából köddé váltak. És mint később kiderült, ez jelentette a fő gondot. De ne rohanjunk ennyire előre.

Beragadt URL-ek

Ha a domain migráció sikeres volt, akkor ezek mégis hogy ragadtak be? Igazából ez a kérdés egyrészt nagyon jó, másrészt utólag tök egyértelmű. Nézzük miért:

1. a migráció előtt leszedtem az összes http + thepitch.hu URL-t a Google találati listájából, Search Consoleból és Screaming Froggal is
2. ezeket megfelelően át is irányítottama https + thepitch.hu verzióra
3. mivel a tag (címke) oldalak megszűntek, ezeket a tematikusan legrelevánsabb oldalra küldtem 301 redirecttel
4. szóval a tag = seo-t egy SEO cikkre, a tag = analitika címkét az Analytics cikkre és így tovább

Amikor kész volt az egész, akkor futtattam egy response code tesztet az összes URL-re. Itt ugye azt akarom ellenőrizni, hogy a régi URL megfelelően át is irányít-e a redirect map-ben megadott URL-re. Ha 301-et kapok, akkor lehet örömködni. És ez így is történt minden esetben. (Ha 404-et dobna egy régi http URL, akkor biztosan elrontottál valamit.)

Egy dologgal viszont nem számoltam:

Ha egy URL-t megszüntetsz, nincs benne az új sitemapben, nincs rá belső (internal) link, akkor a Google (nagy valószínűséggel soha) nem fogja crawlolni. Vagyis a bot nem fog rá felmenni és megvizsgálni a tartalmát. Tehát hiába él az átirányítás, nem fogja felfedezni. Ezért nem is tudja, hogy te azt átirányítottad. Tehát már az új verziót kellene kiszolgálnia a találati listában (Google SERP).

Geez. Hónapokat vártam valamire, amire nagyjából nulla esély volt, hogy bekövetkezzen.

Mivel volt mind a két GSC fiókhoz hozzáférésem, ezért elkezdtem játszani.

A beragadt URL-ekre így bukkantam rá:

site:thepitch.hu -inurl:https

• vagyis kérem az összes URL-t egy domainről, de az URL ne tartalmazza a biztonságos protokollt

https://www.google.com/search?q=site:thepitch.hu+-inurl:https

Ezeket egyébként a http Search Console felületen is láttam felbukkani hónapokkal a migráció után is.

Ideális esetben itt semminek nem kéne lennie. Vagyis ezt kéne látnod:

De mint tudjuk itt nem ez történt. Hanem ez:

Google URL eltávolítás teszt

Itt egyértelmű volt, hogy akkor ezt most végig kell tesztelnem. Egy URL-t több módon is el lehet távolítani az indexből:

1. noindexeléssel
2. törlés, redirect és recrawl folyamattal
3. URL removal request segítségével Search Consoleból

Mindegyiknek van előnye és hátránya is, ezért különböző esetekben szokták ezeket használni.

Alkalom adtán még be lehet emelni 4. elemként azt, amikor robots.txt-ben disallow-ra raksz egy oldalt. Ezzel viszont csak azt gátlod, hogy a Google direkt módon felfedezze azt. Azt nem, hogy esetleg indexelje. Extrém esetben előfordulhat, hogy egy URL robots.txt-ben disallow-ra van rakva, de ha nincs az adott oldalon specifikusan rajta a „noindex” meta tag, akkor bekerülhet az indexbe. Ez akkor fordul elő, amikor az adott page-re van belső link, tehát a Google fel tudja fedezni egy internal linken keresztül, jön a crawler, és máris tolja be az indexing fázisba. Mert a robots.txt direktíva annyira régen volt, hogy teljesen ignorálja / „elfelejtette a tiltását” az adott URL-re vonatkozóan.

Ezt a lehetőség itt most nem is próbáltam ki emiatt, hanem a másik 3-ra koncentráltam.

1. Noindex

Ezzel az opcióval azért nem tudtam dolgozni, mert maga az URL és page már megszűnt. Töröltem és kész. Nem volt mit „noindex”-elni. Szóval ez itt nem játszott érdemben. Ráadásul azt is http protokollon kellett volna megtenni, úgyhogy ez itt instant skip lett. Mentem tovább.

2. Redirect + recrawl

A redirectek ugyebár működtek rendben. De mivel a crawler nem járt ezeken a http címke URL-eken, ezért nem történt semmi velük. Itt elkezdtem kicsit agyalni, hogy milyen tesztet kellene futtatni.

Először a http Google Search Console fiókot használtam. Az elképzelés az volt, hogyha ez a találat a http fiókban van beragadva, akkor ott kellene újra crawlolni, és egy sima Fetch megoldja a problémát. Logikusan hangzik. DE NEM!

Konkrétan semmi nem történt, mikor ezt a lépést csináltam. A beragadt találatok ugyanott maradtak. És kész.

Ez alapján már gyanús volt, hogy akkor a https Google Search Console fiókban keresni a megoldást. Itt a https + tag oldalt küldtem be az új Search Console felületén. Ugye itt az az érdekes, hogy https protokollon ez az URL soha nem is létezett. De mégis ezt kellett crawlolni a megoldáshoz az URL inspection menüpont segítségével.

Néhány másodpercig gondolkodik a rendszer, míg teszteli a live URL-t.

Majd ideális esetben egy ilyen üzenetet kapsz.

Itt azért érdemes néhány dolgot ellenőrizni. Itt például látható, hogy a blogot még mindig a desktop Googlebot crawlolja, tehát ez az oldal nem állt a mobile first indexingre.

1 napon belül eltűnt a beragadt URL a Google találati listából. Már csak ketten maradtak. A „startup pitch” tag eltűnt. Csak a SEO és a CMS maradtak, amiket ugyanígy el tudtam távolítani.

Mi okozta a különbséget a régi és az új GSC között? Csak tippelni tudok, de valószínűleg az, hogy itt egy redirect chain jön létre és az okozza a gondot. A http + tag oldal ugyanis nem létezik, ez redirectel egy szintén nem létező https + tag oldalra. Ami utána továbbvisz a https + végső URL-re. És ez a redirect chain nem tetszik a Google-nek.

Szóval hiába a http találat volt beragadva, azt a https protokollon belüli crawl segítségével tudtam csak feloldani.

3. URL removal request

Az URL eltávolítási kérelem során szimplán megadod az adott URL-t, amit el akarsz ideiglenesen tüntetni a Google találati listáról és vársz egy kicsit.

Az új Google Search Console felületen ezt egyelőre nem tudod megcsinálni, de a régin még ott van ez az opció. Idővel gondolom ezt is át fogják mozgatni.

Ez 1 napon belül át is szokott futni. Én december 12-én adtam be a requestet, és következő nap már nem volt ott a Google SERP-ben a találat. Majd utána ezt vissza is tudod vonni (Reinclude), vagyis újra meg tudod jeleníteni a találatot a Google felületén.

Így pedig visszakapod a találatot, ha kéred.

URL removal request előnye:

• napon belül működik az eltávolítás
• vissza tudod könnyen vonni az eltávolítást
• ez is működik napon belül

URL removal hátránya:

• manuális munka

Migrációs tanulságok

Hiába kivitelezel tökéletesen egy domain migrációt, mindig előbukkanhatnak extrém esetek. És olyanok, amikkel korábban nem találkoztál. A fenti eset nem volt egy kirívóan komoly probléma egyébként, de mégis érdekes volt látni, hogy több mint 7-8 hónapon keresztül volt a Google rendszerében több olyan URL, aminek nem kellett volna ott lennie. És ezeket folyamatosan kiszolgálta http protokollon keresztül, holott az átirányítások helyesen működtek. Itt most kis elemszámról és alacsony látogattságú URL-ekről volt szó, de ha sokkal több ilyen elem ragad be, akkor az komolyan torzíthatja az adataiadat, ami alapján döntést hozol.

A fenti eset azért is különösen érdekes, mert a többi címke URL-t probléma nélkül kivette az indexből és le tudta kezelni. De valami miatt ez a 3 beragadt nála. Azóta se jöttem rá, hogy miért.

Egy átirányítás és migráció esetében a Google SERP-ben az URL átállás a recrawl idejétől és rátától függ. Minél hamarabb és többször jár az oldalon a Googlebot, annál gyorsabb lesz az átállás.

Ezt elő tudod segíteni azzal, ha:

• megfelelően működnek a redirectek
• jó a sitemap-ed
• azt beküldöd a Google Search Consolebe

De ez néha nem elég. És mind a fenti példa mutatja, hiába van jól beállítva minden, mindig előbukkanhatnak érdekes és váratlan problémák. De legalább most már pontosan tudom, hogy milyen opcióval lehet hatékonyan kiszedni őket a Google találati listából. És azt, hogy mi az, ami tutira nem működik.

Az ilyen jellegű SEO tesztek azért hasznosak, mert egy-egy apró lépéssel mindig közelebb kerülünk a Google működésének a megértéséhez. Én legalábbis sokat tanultam ebből az apró tesztből. Remélem ti is a cikkből.

Tetszett a cikk? Szeretnél még több ilyet olvasni?

Akkor iratkozz fel és küldünk egy emailt, ha hasonló cikket írunk!

0% spam, 100% online marketing.