ugrás a tartalomhoz

JS, AJAX módszerek hatása a keresőhelyezésekre

Edit · 2006. Jan. 3. (K), 13.50
Az ajaxos jellegű, desktop felületet utánzó megoldások gyakori eleme, hogy bizonyos tartalmakat klikkelésre megjelenít/eltüntet. Azt hiszem, "toggling" a technika becsületes neve. Display: none, majd display: block. De ha ezek a tartalmak első körben rejtettek, akkor az rossz pont a keresőknél. Van valakinek ezzel kapcsolatban tapasztalata?

Egyáltalán, hogyan befolyásolják az ajaxos megoldások a kereső-helyezésünket?
‹ Google indexelő követi a láthatatlan linkeket? Kereső intranetre? ›
 ■
1

Diszkrét JavaScript

attlad · 2006. Jan. 3. (K), 13.57
Ezt úgy kéne, hogy alapból látszodik, mert akkor kikapcsolt JavaScripttel is látszodik és ondomload eseményre tünteted el JavaScripttel.
2

Alapból csukva

Fekete Ferenc GDA · 2006. Jan. 3. (K), 14.01
Ezzel viszotn az a baj,h amikor lassan betöltődik az odlal, akkor látszik, majd amikor lefut a JS ,akkor becsukódik. Ezért kell alapból csukva tartani.



Online 2.0
5

Attól függ

attlad · 2006. Jan. 3. (K), 14.12
Hát ez attól függ, mi az az elem amit csukogatunk (mennyire fontos ha nem látszik), sima weboldalról vagy webalkalmazásról van-e szó, meg mekkora az oldal mérete, egy átlagos HTML fájl szerintem 1-3 másodperc alatt lejön még modemmel is, majd csinálok egy tesztet egyszer.
7

Villan

Jano · 2006. Jan. 3. (K), 14.26
Én az onloadra eltüntetést nem szeretem, mert ha lassan töltődik az oldal, akkor a user elkezdheti olvasni azt a tartalmat, ami pár másodperc múlva eltűnik, ha közepesen gyorsan töltődik az oldal, akkor meg "villodzik".

Inkább headben scripttel generalok meg egy css szabalyt, linkelo sort scripttel amiben az eltunteto szabaly van.
10

ondomload

attlad · 2006. Jan. 3. (K), 14.59
Nem onload, hanem ondomload. De ez a generált CSS megoldás érdekes, majd kipróbálom, bár ha jól tudom document.write nincs real XHTML-ben.
14

writeon kívüli élet.

connor · 2006. Jan. 3. (K), 15.11
Ugyan úgy lehet szerkeszteni DOM szinten a css szabályokat is. (DOM inspectorban nézz szét)

--
connor
15

Igen

attlad · 2006. Jan. 3. (K), 15.17
De arra tippeltem, hogy ahhoz célszerű megvárni még betöltödik a DOM, nem? Ha ondomload megvan akkor már egyszerűbb máshogy állítani.
3

<Nincs cím>

Fekete Ferenc GDA · 2006. Jan. 3. (K), 14.03
Attól,h a tartalom egy része rejtett, az még nem rossz pont a keresőknél.
Például a navigációnál használt FIR módszer sem rossz pont.

Az igazán rossz pont az, ha az eltüntetett div-ben keyword stuffing-ot talál a google/yahoo, stb.

Online 2.0
4

CSS értelmező

Bártházi András · 2006. Jan. 3. (K), 14.05
Szerintem Google-nél még nem írtak CSS és JavaScript értelmezőt. Ergo nem rossz pont a keresőknél. Tapasztalat az nincs, de nem hinném, hogy képesek minden egyes oldalhoz tartozó CSS-t értelmezni, megnézni, hogy milyen HTML elemeket befolyásol, stb. Szerintem. Nem lehetetlen feladat, de viszonylag számításigényes lehet.

-boogie-
6

Google is pretty smart (?)

Edit · 2006. Jan. 3. (K), 14.21
Google is pretty smart, and often can
detect hidden text. A lot of people use hidden text to spam the search
engine with irrelevant terms. This resulted in a 30-Day “no listing”
penalty being enforced for any hidden text found.


http://answers.google.com/answers/threadview?id=248512
8

Nem arra gondol

Fekete Ferenc GDA · 2006. Jan. 3. (K), 14.26
Itt inkább arra gondol,h pl fehér háttér előtt fehér text, vagy pl ez a link.
A display: none;-al nem lehet baja. miért? : fir, css menü, css dropdown, stb.

Online 2.0
9

<Nincs cím>

connor · 2006. Jan. 3. (K), 14.29
Na igen, nem lehet kategorikusan kimondani, hogy csal az aki a display: none formázást használja egy elemre.

--
connor
35

Statkódok

suexID · 2006. Jan. 3. (K), 22.54
Én is használok ilyet a nem kívánatos statisztika ikonok eltűntetésére. Ettől függetlenül nem csalok, tehát ott a pont! :)
36

Stat policy ellenes

Jano · 2006. Jan. 3. (K), 22.59
Viszont valoszinuleg a statisztika eloirasoknak nem teszel eleget!
11

<Nincs cím>

Edit · 2006. Jan. 3. (K), 15.01
Pont azért kérdezem, mert olyan érzésem van, hogy pl. egyes image replacement technikákra a Google allergiás (a Yahoo nem). Például erre:
h1 {margin-left: -5000px}

Meg a display: none-ra is. Tudományosan persze nem tudom bizonyítani, mivel nem lehet a kísérletet kontrollálni (az összes többi rangsor-befolyásoló tényezőt fixen tartani). Szóval maradnak a megérzések.
12

<Nincs cím>

Fekete Ferenc GDA · 2006. Jan. 3. (K), 15.05
Amit említettél, az nem image replacement technika, hanem offscreen positioning, azaz spam.

Ez viszont már image replacement technika és NEM spam.

Online 2.0
16

Phark Method

Edit · 2006. Jan. 3. (K), 15.21
h1 {margin-left: -5000px; background: url(akarmi.gif) no-repeat;}


Margin-left helyett lehet text-indent is.
17

<Nincs cím>

Fekete Ferenc GDA · 2006. Jan. 3. (K), 15.31
mondom,h ez nem image replacement technika, amit írsz. Ez spam! Egyébként meg háttérképpel együtt kipozícionálod a képernyőből.


Online 2.0
18

Phark, 3. felvonás

Edit · 2006. Jan. 3. (K), 15.49
http://phark.typepad.com/phark/2003/08/accessible_imag.html

Now, what this does, is move the text 9000 pixels to the left (or "before", depending on in which direction your text is written), such that is it no longer viewable in the parent container.

The text is "still there", however you cannot see it. The background image shines through proudly, and the screen reader will happily read your extremely negatively-indented text, disregarding the background!
20

<Nincs cím>

Fekete Ferenc GDA · 2006. Jan. 3. (K), 15.58
text-indent-el ne mpróbáltam, de amit Te írtál(margin-left) azzal a kép nem látszik, tehát az ne mmegfelelő.

A léyneg,h a keresők ne mszeretik az ennyire offscreen tartalmakat. Talán 1-2 szó belefér, de komplex keyword stuffing kizárt.

Online 2.0
22

CSS igen, képek tiltva

Jano · 2006. Jan. 3. (K), 16.05
Az összes olyan technikánál ahol a szöveg nem marad az eredeti helyén mind az a baj, hogy ha CSS be van kapcsolva, a képek viszont le vannak tiltva akkor nem látszik semmi! Én ezért mindig a plusz 1 span elemes megoldást alkalmazom, ahol a plusz spannak megadott háttérkép takarja el a szöveget. Igen a plusz elem programozói oldalon nem szép, de inkább ez a hátrány mint a felhasználói oldalon a kezelhetetlenség.

Neve: Gilder/Levin Method
19

Még jobb leírás

Edit · 2006. Jan. 3. (K), 15.57
http://www.mezzoblue.com/tests/revised-image-replacement/#phark
13

Bizonyítás

attlad · 2006. Jan. 3. (K), 15.06
Elég ha megnézed logba, hogy CSS-t letöltötte-e a Googlebot, szerintem nem tölti le.
21

ez nem AJAX

Hodicska Gergely · 2006. Jan. 3. (K), 16.04
Az ajaxos jellegű, desktop felületet utánzó megoldások gyakori eleme, hogy bizonyos tartalmakat klikkelésre megjelenít/eltüntet. Azt hiszem, "toggling" a technika becsületes neve. Display: none, majd display: block.

Ennek nem sok köze van az AJAX-hoz, a J betűt leszámítva.


Felhő
23

Ajaxos JELLEGŰ

Edit · 2006. Jan. 3. (K), 16.33
Ez a csiki-csuki szinte minden AJAX könyvtárban benne van, standard tartozék. A legtöbb (és legszebb) ilyen megoldást a Backbase könyvtárában találtam:
http://www.backbase.com/demos/explorer/#intro.xml[0]

Sajna fizetős, plusz itt ez a kis bizonytalansági tényező a keresők vonatkozásában.
25

szerintem kevered

Hodicska Gergely · 2006. Jan. 3. (K), 19.31
Ezeknek a "csiki-csukiknak" semmi közük nincs az AJAX-hoz. Megnézheted pl. JPSpan, PAjax, SAjax, nincs bennük ilyesmi. Ezeknek a kommunikációt kell megvalósítaniuk.


Felhő
27

Könyvtár

Edit · 2006. Jan. 3. (K), 20.16
Nem azt mondom, hogy AJAX, hanem hogy több AJAX-könyvtár is tartalmaz ilyen megoldásokat, pl. a http://script.aculo.us/, vagy a korábban említett Backbase. Kinyílik, becsukódik, felcsúszik, leesik, stb. És szeretném őket használni, de nem azon az áron, hogy a keresők rejtett spamnek nézik az éppen nem látható tartalmat.
29

nem kötekedés

Hodicska Gergely · 2006. Jan. 3. (K), 20.31
De amiket te említesz, azok inkább effekt könyvtárak, amik esetlegesen felhasználnak AJAX könyvtárat is. Ez fordítva nem jellemző.


Felhő
30

Félreértés

Jano · 2006. Jan. 3. (K), 20.54
Szerintem itt a fórum jellegből adodó csak 2 mondatos bejegyzés miatt van "félreértés" köztetek. Hogy mi minek a részhalmaza az meg teljesen mindegy és nézőpont kérdése csak.
Lényeg, hogy ki-be csukogatást lehet Ajax nélkül és vele együtt is alkalmazni, és talán gyorsabb megírni, mint effekt könyvtárat keresni rá.

Régebben a display:none és a háttérszínnel megegyező betűszín egyértelműen spam jellegű megoldás volt. De akkor ezeket könnyű volt észrevenni, mert ott volt a HTML kódban a FONT tag. Manapság egyrészt ezeket megjelenítésbeli dolgok kikerültek külső fájlba amit Googlebot nem tölt le, másrészt valós funkcióknak is alapja.

Szerintem megegyezhetünk abban, hogy a Google a csikicsukis kód miatt nem fogja ignorálni az oldalt.

Sokkal fontosabb az, hogy ne használjuk olyan funkcionalitás megvalósítására ami idegen a weblapoktól. Tehát egy teljes néhány lapbó álló weboldal megvalósítható egyetlen fájlban, amennyiben a menü nem új lapokat hív be, csak az adott fájl megfeleő részeit teszi láthatóvá és rejti el. Ekkor azonban a felhasználónak elvész az a lehetősége, hogy a megfelelő aloldalt bookmarkolja, küldje el emialben stb.

És megegy szempont: ha már a ki-be csukokgatassal nem is sima információ közlő hagyományos weblapon játszunk, hanem inkább egy webalkalmazás jellegű dolgon, akkor igazából nem is baj, ha a Google nem tudja leindexelni...
33

Ezt miért nekem írod?

Hodicska Gergely · 2006. Jan. 3. (K), 21.55
Lényeg, hogy ki-be csukogatást lehet Ajax nélkül és vele együtt is alkalmazni, és talán gyorsabb megírni, mint effekt könyvtárat keresni rá.

Nem értem, hogy ezt mire írod, félre érthettél. Én midössze annyit mondtam, hogy az eredeti hozzászólásban említett módszer nem AJAX. Illetve hogy egy AJAX könyvtárban nincs csiki-csuki általában.


Felhő
37

meg fogalmazatlan fogalmak...

connor · 2006. Jan. 4. (Sze), 01.16
Meg kéne már fogalmazni, hogy minek mi a hatásköre (hatóköre?).
xmlhttprequest, ajax, dinamikus html...

A gond abból ered, hogy ezek "egymásba ágyazott" technikák.

--
connor
38

ajax = kommunikáció

Hodicska Gergely · 2006. Jan. 4. (Sze), 11.01
Az AJAX jelenleg minden XmlHttpRequest-et használó kommunikációt jelent. Igazából az első A meg az X sok esetben nem A és nem X, sok megoldás szinkron kommunikációt használ, és a válasz nem XML formátumú.

DHTML meg kb. minden, amiben JS van és DOM-ot manipulál. Azt mondjuk nem tudom, hogy a "hivatalos" álláspont szerint pl. egy űrlap ellenőrző JS DHTML-nek számít-e, szerintem nem.


Felhő
24

Részben

Jano · 2006. Jan. 3. (K), 18.13
Akkor Ajax-os, ha a kinyitaskor tolti bele a tartalmat es alapbol nincsen benne az oldal kodjaban.
26

skip to content

Hojtsy Gábor · 2006. Jan. 3. (K), 19.45
A skip to content szövegre keresve rengeteg olyan oldalt fogsz találni, ami ezt rejtetten tartalmazza. Ha ez büntetett lenne, akkor ezek nem jelennének meg. Szerintem nem mondható ki kategórikusan, hogy az elrejtett dolgok miatt büntetés jár.
28

Nagy cégek?

Edit · 2006. Jan. 3. (K), 20.24
Én nem emlékszem olyan nagyobb cég honlapjára, ahol AJAX-ot használnának. Pedig amikor betört a köztudatba - 2005 eleje-közepe - akkor azt hittem, két héten belül mindenhol használni fogják. De valamiért elég lassan terjed. Lehet, hogy aki használja, mindjárt csődbe is megy?

Emlékszem rá, az első kelet-európai Amazon vásárlók között voltam, és egyszer jött egy email Jeff Bezos-tól, hogy tegyünk javaslatokat. Akkor én drag-and-drop bevásárlókocsit kértem - azóta sem kaptam meg. Pedig gyerekjáték, már én is meg tudnám csinálni...:-)

Ui.: Kivéve persze Google Mail, stb.
31

Nagy cégek

attlad · 2006. Jan. 3. (K), 20.57
Google, Microsoft, Yahoo!, Amazon használ ilyen megoldásokat. Természetesen csak ahol értelme van. Ezek szerintem elég nagy cégek.
32

Béna cégek

Bártházi András · 2006. Jan. 3. (K), 21.18
A nagy cégek oldalát ha megnézed, kevés (egyre több) állt át CSS alapú oldalkialakításra. Ez nem abból adódik, hogy rossz, hanem hogy még csak pár éves technológia. A kis cégek gyorsabban mozdulnak, mint a nagyobbak, ennyi az egész (pl. nem fogják a weblapjukat megújítani évente, az éppen aktuáls trend szerint sok pénzt "kidobva" rá - más az életciklusa egy megoldásnak).

-boogie-
34

A Backbase tanácsai

Edit · 2006. Jan. 3. (K), 22.19
Designing Rich Internet Applications For Search Engine Accessibility:

http://www.backbase.com/download/articles/DesigningRIAsForSearchEngineAccessibility.pdf

Ui.:

De ezek sokkal jobb tanácsok. NE készítsünk alternatív honlapot.