ugrás a tartalomhoz

Making AJAX Applications Crawlable

Kevlar · 2010. Már. 5. (P), 13.00
Hogyan indexeli a Google az AJAX alapú oldalakat?
 ■
1

Forrás

Kevlar · 2010. Már. 4. (Cs), 18.02
http://longhand.hu/keresooptimalizalas_/ajax-url-googlebot.php
2

Miért jobb, mint a hagyományos diszkrét JS?

erenon · 2010. Már. 5. (P), 21.14
A cikkben leírt megoldás miért jobb, mint a hagyományos "diszkrét" JS? Tehát például alapesetben a linkek egy másik oldalra mutatnak (amit a cikk HTML snapshotként emleget), de a megfelelő javascript betöltődése után a linkek lecserélésre kerülnek, a JS által használt formátumra.
3

Ez egy jó kérdés

butcher51 · 2010. Már. 6. (Szo), 10.25
Ez egy jó kérdés
4

Ez is lehet diszkrét

yaanno · 2010. Már. 7. (V), 22.04
A diszkrét js attól diszkrét, hogy nem teszed rá a html forrásban a link onclick eseményére a függvényhívást :) Ahogyan te is írod, a link alapesetben egy erőforrásra mutat (nem feltétlenül másik dokumentumra) - ha újratöltés nélkül akarsz erőforrást átadni és egyúttal azt elérhetővé tenni a kereső számára is, ez a megoldás jól jöhet.
5

Nem értem

erenon · 2010. Már. 7. (V), 22.40
Nem értem. Célok:
* Ha van JS, az oldal egyes részei újratöltés nélkül változzanak
* Ha nincs JS, a linkekre kattintva töltődjön újra az egész oldal, kiegészítve a kívánt tartalommal
* Ha crawler jön... az ugyan az az eset, mint a 2.

Vagyis miért jobb az, ha bűvészkedünk olyan megoldásokkal amit csak a crawler ért, és a linx pl. nem, ahelyett, hogy 2 ágra bontjuk a problémákat. Tehát: A linkek alapesetben egy másik oldalra mutatnak, JS betöltés után pedig leszedi a linkeket és onclick eseményeket rak a helyükre. (Egyszerüsítve a dolgokat)

Nem vagyok én semmi ellen, csupán nem értem a cikkben ismertetett technika létjogosultságát.
6

+1

Joó Ádám · 2010. Már. 7. (V), 22.56
Nem vagyok én semmi ellen, csupán nem értem a cikkben ismertetett technika létjogosultságát.


És ezzel nem vagy egyedül.
7

+1

Ustak · 2010. Már. 7. (V), 23.00
Nem vagyok én semmi ellen, csupán nem értem a cikkben ismertetett technika létjogosultságát.

Ha mondat lennék, ilyen lennék.
9

A 4. cél pedig kezdeni azzal

Török Gábor · 2010. Már. 8. (H), 09.18
A 4. cél pedig kezdeni azzal az esettel is valamit, ha a crawler a weboldaladra egy külső, ajaxos erőforrás-hivatkozás útján kerül.
8

Nem jobb, kiegészíti azt

Török Gábor · 2010. Már. 8. (H), 09.15
Nem jobb, kiegészíti azt. Az ajaxos oldalak/alkalmazások állapota célszerűen az URL-ben tükröződik. A jelenlegi ajánlás célja, hogy ezt az erőforrást olyan formában tálald, hogy a keresőrobot tudjon mit kezdeni vele. Példa: Facebookról kimásolod a http://www.facebook.com/#!/pages/budapest-js/333922122483 URL-t, és hivatkozol rá a blogodban.
10

Megértettem

erenon · 2010. Már. 8. (H), 17.18
Zseniális, értem, köszönöm.
Akkor ezek szerint úgy kell kialakítani a hivatkozásokat, hogy kezdetben a 
http://foo.bar/index.php?_escaped_fragment_=page/5
oldalra mutassanak, a javascript pedig 
http://foo.bar/#!/page/5
-re cserél.
11

Nem

Török Gábor · 2010. Már. 8. (H), 18.08
Az én olvasatomban nem. Legalábbis isten őrizz, hogy elszabaduljanak ezek az escaped_frament-es URL-ek. A fenti példánál maradva a Facebook oldalán belül a budapest.js csoport oldalára mutató erőforrás a /pages/budapest-js/. Ha JS-képes kliens látogatja meg az oldalt, ő a hash mintás /#!/pages/budapest-js/333922122483 változatot fogja követni (a diszkrét JS jegyében). Mindezen felül pedig a /pages/budapest-js/ címedet fel kell tudni oldani /?_escaped_fragment_=/pages/budapest-js/ címen is. URL-enként egy aliassal bővül a router táblád.

A Google szempontjából nyilván nem a fenti scenárió az érdekes, hiszen ő a „JS-képtelen” kliensek számára fenntartott URL-szerkezetet amúgy is látja. A cél inkább az lehetett, hogy a JS-sel erősen terhelt (netán csak JS támogatás mellett elérhető) felületekhez is hozzá tudjon szagolni, a találati listában így ajaxos erőforrásokat is kiadhasson lehetséges, releváns találatként.
12

Tartalom duplikáció

erenon · 2010. Már. 8. (H), 18.32
Rendben, majdnem erre gondoltam előbb is, csak én nem szívesen bővítem a router táblát. (Nyilván ha kell, kell) Így viszont figyelni kell arra is, hogy valahol (célszerű a fragment címen) ki kell adni a megfelelő headereket és meta tageket, amelyek figyelmeztetnek a szándékos tartalomduplikációra. (több url->egy tartalom)
13

Ha elfogadjuk, hogy az én

Török Gábor · 2010. Már. 9. (K), 10.40
Ha elfogadjuk, hogy az én koncepcióm helyes, akkor igen, a megfelelő átirányításokról gondoskodni szükséges. Várhatóan a képlet nem ennyire egyszerű, és a Google tálalási javaslatát inkább az a tapasztalat szülte, hogy van egy halom ajaxos app, ami 1) JS nélkül használhatatlan, és 2) az állapotát sem feltétlenül közli az URL-ben, és így legalább valami képet kaphatnak az alkalmazás egyes mozzanatairól a keresőrobotok is.
14

„diszkrét js” v0.5

presidento · 2010. Már. 9. (K), 16.32
Jól értem, hogy ez szinte diszkrét JS azzal a fontos különbséggel, hogy diszkrét JS esetén a link egy teljes(en funkcionáló) oldalra mutat, míg ha nincs (kedved a) diszkrét JS(-sel bajlódni), ezzel a módszerrel mégiscsak „elérhetővé” teszed az AJAX-szal betöltött tartalmat a'la nature?
15

Részben igen, részben nem.

Török Gábor · 2010. Már. 10. (Sze), 10.37
Részben igen, részben nem. Egyfelől megoldás arra, hogy egy JS-only appról képet kapjon a kereső, másfelől lefedi azt a kérdést, hogy egy ajaxos erőforrás-hivatkozással mit kezdjen a robot, amire önmagában a diszkrét JS nem ad választ.
16

Örülök neki, hogy nem csak nekem nem világos ez a dolog..

nevemrock · 2010. Már. 18. (Cs), 18.49
Ha valaki tudná a választ legyen kedves felhomályosítani.

Ajax:
Linkem href attr-je: #!pages/hu/page_1.html

PHP:
index.php?_escaped_fragment_=pages/hu/page_1.html
Ez így akkor jó, vagy benéztem a dolgot?

Még egy érdekes észrevételem van a dologgal kapcsolatban. Ha már ajánlás és az ajánló böngészője a Chrome. Akkor miért nem támogatja az anchor alapú navigációt? Vagy ez a jelenség csak nálam van Ubuntun?

document.location.pathname+="#!#!pages/hu/page_1.html";
Erre a Chrome elnavigál Kenyába, illetve % formába alakítja a #-teget.
17

window.location

Török Gábor · 2010. Már. 18. (Cs), 19.34
document.location was originally a read-only property, although Gecko browsers allow you to assign to it as well. For cross-browser safety, use window.location instead.


Hash állításra pedig ne a pathname, hanem a hash tulajdonságot használd.
18

Link kezelése

Török Gábor · 2010. Már. 18. (Cs), 19.38
Linkem href attr-je: #!pages/hu/page_1.html

A JS-képtelen kliensek ezt nem tudják követni. A diszkrét JS jegyében csak JS-képes kliensek felé szolgáld ki ezeket, a href-ben továbbra is a /pages/hu/page_1.html szerepeljen.
19

Köszi a választ!

nevemrock · 2010. Már. 18. (Cs), 20.09
Gábor köszi a tippeket.

Elfelejtettem leírni, hogy JS képtelen kliensek át vannak irányítva kapásból az index.php-fájl-ra ahol megy tovább a móka mintha mi se történt volna. Csak az URL-be el kezdi cuccolni a paramétereket. str_replace("#!", ...

<noscript><meta http-equiv="refresh" content="0; URL=./index.php"></noscript>
Bár ez nem szép, de van benne valami visszataszító.


a href-ben továbbra is a /pages/hu/page_1.html szerepeljen.


Ez tényleg jó volna, de ez egy egyszerű kísérlet és igyekszem mellőzni minden .htaccess mod_rewrite vagy URI Routing dolgot. Bár szebb lenne az URL ez tény.
20

meta refresh

Poetro · 2010. Már. 18. (Cs), 21.08
Már ha a böngésző ismeri, és nincs letiltva benne a meta refresh. Szöveges alapú böngészők nagy része nem ismeri, grafikus böngészők egy részében meg könnyű letiltani.