Form + Javascript = Duplicate Content?

Érdemes óvatosan bánnunk azokkal a formokkal, select elemekkel, amelyek nem tényleges formok, csak javascript-tel dolgozzuk fel őket. A keresőrobotok fejlesztői a formokat nem éppen megfelelően kezelik, emiatt könnyen indexelésre kerülhet néhány (vagy néhány ezer) oldalunkból több „másolat” is.

Hol jelentkezik a probléma?

Tegyük fel van az oldalunkon egy alábbihoz hasonló form, benne egyetlen select, amit mondjuk egy javascript függvénnyel kezelünk. Legyen mondjuk egy mezei, betűméretet módosító kódunk, amely az alábbi formot használja.

<form>
  <select id="fontsize" name="fontsize">
    <option value="1">Kicsi</option>
    <option value="1.5">Közepes</option>
    <option value="2">Nagy</option>
  </select>
</form>

Gondolom kitaláljátok, hogy mi lesz az eredmény. Nem? A kedvenc keresőink robotjai lekérik ezeket felhasználva is az adott oldalt.

  1. http://lapom.com/
  2. http://lapom.com/?fontsize=1
  3. http://lapom.com/?fontsize=1.5
  4. http://lapom.com/?fontsize=2

A lapunkon megfelelő canonical jelölést és 301 redirect átirányítást alkalmazunk a duplikátumok elkerülése érdekében. Az indexben mégis megjelennek sorban a 2., 3. és 4. verziók, a duplikációk miatt ezzel a találati listában hátrébb sorolva a lapunkat.

A fenti csak egy példa volt. Akár úgy is ráfuthatunk hasonló problémára, hogy nem is tudunk róla. Jó példa néhány WP téma, amelynek a mobilra optimalizált lapján egy ilyen FORM valósítja meg a lenyíló menü lehetőségét. Nem nézzük mobilon, nem látjuk sosem, és csak lesünk, hogy miért csúszik egyre hátrább a lapunk a keresők találati listájában…

Ennek nem így kellene működnie, de ma (2013. 08. 03.) biztosan így működik. Akár tetszik, akár nem.

Mit tehetünk?

Ha már ráfutottunk az indexelésre egy fake-form kapcsán, akkor keveset, ezért lehetőség szerint előzzük meg a bajt. Tudjunk róla, hogy 2008 óta a robotok a formokat is megpróbálják linkekhez hasonlóan végigjárni.

Amit NEM javaslok.

Különböző fórumokon több megoldási javaslatot terjesztenek a pórul jártak, de ezek között kevés a valóban használható. Ezt mondjuk megszokhattuk, a webes fejlesztés kb. olyan mint a foci, mindenki ért hozzá … vagy mégsem?

  1. Ne próbálkozz olyan action beállításával, ami 4xx hibakódot ad vissza. Ezzel csak azt érnéd el, hogy az oldaladon megnő a detektált (fals) 404-es hibák száma, ami negatívan hat az oldal helyezésére a keresőkben.
  2. Olyan action bállítása sem célszerű, amely robots.txt által tiltott URL-re mutat. Legyünk tisztában vele, hogy egyrészt a robotok nem minden tiltást vesznek figyelembe, másrészt a nem bejárható részekre mutató linkeket sem díjazzák.

Néhány dolog, ami jó ötletnek tűnik, működnie kellene, de mégsem segít.

Az alábbi megoldásoknak működniük kellene, de a keresőrobotok fejlesztői is csak olyan programozók, akiket a szabványok és a saját cégük ajánlásai is hidegen hagynak.

  1. 301-es átirányítás arra az URL-re, amely nem tartalmazza a fel sem dolgozott URL paramétert. Elvileg ennek meg kellene oldania a problémát, de a robotok egyszerűen nem úgy kezelik, ahogy a dokumentációjuk sejteti (és ahogy kellene). Ez nem vita témája, hanem személyes tapasztalat.
  2. A „canonical” jelölés beállítása ma már a legtöbb oldalnál szükséges és célszerű, de ez sem gátolja meg önmagában a robotokat a (vélt) duplikátumok indexelésében.

Néhány lehetőség maradt.

Aggódni nem kell, maradt 1-2 járható út is, hogy a problémát elkerüljük vagy orvosoljuk.

  1. Kerüljük el a csak kliens oldalon, javascript által kezelt formokat.
  2. Az elkerülhetetlen fake-formokat javascript kóddal adjuk hozzá az oldalhoz, ha nincs JS, akkor ezek úgyis értelmüket veszítik.
  3. Jelenleg csak a GET lehetőségre ugranak rá a robotok, egyelőre(!) még nem POST-olnak. A fake formok esetén a method=”post” attribútum beállítása tehát segíthet.

A 3. pont megoldása alkalmazható leggyorsabban és a legkevesebb munkával.

<form method="post">
  <select id="fontsize" name="fontsize">
    <option value="1">Kicsi</option>
    <option value="1.5">Közepes</option>
    <option value="2">Nagy</option>
  </select>
</form>

A már beindexelt fals duplikátumok esetén csak abban bízhatunk, hogy azok idővel kiürülnek a keresők indexeiből.

Programozó
Inkább nem írom ide a véleményem a nagyon nagy cégek programozóiról, hátha 18 év alattiak is megnyitják ezt az oldalt…

Update 1. /2013. 08. 06./

A fentinél biztosabb, szebb, jobb megoldás, ha inkább egy action=”javascript:void(0)” attribútummal bővítjük a formot.

<form action="javascript:void(0)">
  <select id="fontsize" name="fontsize">
    <option value="1">Kicsi</option>
    <option value="1.5">Közepes</option>
    <option value="2">Nagy</option>
  </select>
</form>

Tisztább, jobb, szárazabb érzés…

3 hozzászólás “Form + Javascript = Duplicate Content?” bejegyzéshez

  1. Üdv,

    én történetesen robotot programozok. (Ez állásokat keres, menet közben másféle oldalakra is rátéved, főleg sitemap/főoldal etc).

    Én a probléma másik oldalával szoktam találkozni. Az oldalon kint van pl. egy nyelv-választó form, vagy nyelv választó url, ami úgy épül fel, hogy az éppen megcímzett urlhez adja hozzá az új url paramétert. Ilyenkor az történik, hogy a robot rámegy arra hogy
    akarmi.hu?nyelv=hu
    majd ezen állva összerakja az oldal a nyelvválasztó url-eket hogy:
    akarmi.hu?nyelv=hu&nyelv=de
    akarmi.hu?nyelv=hu&nyelv=en etc
    ezekről kiindulva a „nyelv” paraméter újra ismétlődik, minden lehetséges permutációban, és gyakorlatilag a végtelenig növeli az url hosszát

    a fenti eset, hogy a GET formnak vannak selecttel kiválasztható értékei, ez lehet valós duplikáció forrása, a POST form ezt akkor oldja meg, ha a weboldal eltárolja session-ben vagy cookie-ban a font értékét, különben a következő GET request már nem fogja megkapni a font paramétert

    szerintem egy robots.txt bejegyzés, ami a font paramétert tartalmazó urleket kiszűri, meg kéne oldja a duplikációkat – ott ahol számít, a nagy keresők ezeket betartják

    Attila

  2. Az URL-ek felderítésével nem lenne gond, de nekem magas, hogy egy GET form alapján összerakott URL miért kerül be a kereső indexébe adott körülmények között.

    A GET változóval kiegészített URL-re a webszerver 301-es átirányítást ad, amely olyan oldalra mutat, amiben az érvényes URL-re mutató rel=”canonical” link tag van. Ennek ellenére most ott van legnagyobb kereső indexében a robot által tákolt és a valós URL is. A 301 és a canonical link külön-külön is elejét kellene vegye a kettősen indexelt tartalomnak.

    Tudom, hogy weblapok fejlesztői között is sok kutyaütő van, de számomra ott elfogadhatóbb, mint a web alapját adó keresők fejlesztő között.

    MadAdmin

  3. A 301 el kéne tüntesse… de nem látok bele én sem a legnagyobb kereső lelkivilágába. Esetleg link mutat valahol ezekre a GET url-ekre, és azért marad bent az indexben.

    A google webmaster tools alkalmazáson belül, a feltérképezés/url-paraméterek alatt elvileg lehet szabályozni, hogy milyen paramétereket indexeljen. Persze ezt leginkább úgy kell érteni, hogy új oldalak indexelésekor veszi figyelembe. Régi oldalakat nem dob ki az indexből.

    A.

A hozzászólások jelenleg nem engedélyezettek ezen a részen.