Signály – co SEO a tak?

Ondřej Mirtes

Nikdo na to v mém threadu nereagoval a je to pro mě fakt vážný problém, takže zakládám nový a snad se tu ta diskuse rozvine :)

Nikde jsem nenašel, jestli se dá ovlivnit podoba URL, pokud na ni vede signál nějaké komponenty. Např. budu mít výpis nějakého archivu článků, co když ho zpracuji celý jako komponentu? (tzn. nebude to presenter volaný s různými parametry view, ale komponenta, jejíž vykreslený obsah se bude ovlivňovat signálem). Řeším takhle archiv článků – mám ho v Ajaxu, nahoře lišta s výběrem měsíců, po nakliknutí měsíce se bez znovunačtení stránky zobrazí články z jiného měsíce. V šabloně >ArticleArchive:default je jen kód {?$articleArchive->renderArchive()}.

Nevím, jak v routách ovlivnit tvar té URL, na které se ten výsledek bude zobrazovat a také nevím, jak to podstrčit vyhledávači (možná skrytými odkazy na jednotlivé měsíce?), když na ty podstránky vede cesta přes nakliknutí měsíce v selectboxu (viz ten link v minulém odstavci).

Navrhnul jsem to celé blbě nebo se to dá nějak vyřešit? :)

EDIT: Když nad tím tak přemýšlím, měl bych se jako vývojář vždy rozhodovat, zda poslat data presenteru jako argument view (parametru funkce renderView) anebo jako signál presenteru či komponentě. Jak to rozlišit a kdy co použít? Signál je méně praktický – router nejspíš neumožňuje upravit tvar URL, který vede na presenter ovlivněný signálem, neumožňuje mi zakázat přístup na něj pro roboty (např. hlasování v anketě) a je tak horší pro SEO…

Jde o to, že se stalo přesně to, co jsem čekal – když mám na každé stránce webu nějakou komponentu, co využívá AJAX (jmenovitě hlasování v anketě a browser mezi krátkými zprávami), tak vyhledávač zaregistruje spoustu duplicit k té jedné stránce, viz Google.
Kamarád mi říkal, že to tak David udělal schválně, že signály mohou být jen v části za otazníkem, že vyhledávače mají poznat duplicitní obsah a dát přednost kanonickému tvaru (bez části se signálem). Jenže to tak nefunguje – už mám dvakrát zaindexovaný Download a článek „hratelnost“ k tomu také spěje.

Co s tím?

Etch

Jen k té tvé anketě možná by nebylo od věci udělat, aby při neajaxovém requestu na hlasování proběhl redirect.

Honza Marek

Ono jde třeba i o stránkovaný výpis článků udělaných jako komponenta. Pokud ta má být soběstačná, co nejméně závislá na presenteru, fungovat s ajaxem i bez, tak to moc nejde udělat s hezkou adresou.

David Grudl

Za tou volbou musí jednoznačně následovat redirect. To je akce, která mění stav serveru, nikoliv pohled. Pokud dodržíš tuto konvenci, vyřeší se i problém s duplicitou stránek v Google.

David Grudl

Honza M. napsal(a):

Ono jde třeba i o stránkovaný výpis článků udělaných jako komponenta. Pokud ta má být soběstačná, co nejméně závislá na presenteru, fungovat s ajaxem i bez, tak to moc nejde udělat s hezkou adresou.

Stránkování často měnících se dat (například chatu) je SEO problém, beze ohledu na použitý framework. U málo se měnících dat (např. blogu) by tam žádný zádrhel být neměl. Z hlediska komponent Nette stačí buď používat parametry komponent, nebo signály + redirect.

Ondřej Mirtes

OK, dobře, všiml jsem si, že u ankety se to indexuje víckrát, ale co se týče těch short newsek, tak ne.
Otázka je, jak mám provést redirect? Vím o metodě isAjax() i o redirect(…), ale zpracování signálů probíhá až po fázi, ke které je redirect určen…

LM

Redirect můžeš provést třeba i v render fázi nevidím v tom problém.

Ondřej Mirtes

LM napsal(a):

Redirect můžeš provést třeba i v render fázi nevidím v tom problém.

„Životní cyklus presenteru“ tvrdí, že klíčový moment pro redirect je po action{View}, tak nevím, jestli tím něco nenabourám :)

Dotaz: Jakým postupem dostanu do metody redirect přesně tu cestu, jakou potřebuji, tj. cesta na aktuální presenter, view a případné parametry, akorátže bez signálu? Skládat to z getName, getView a getParams mi nepřijde obratné…

LM

Tuším že $presenter->redirect('this') to přesměruje sám na sebe, bez signálu.

Jod

JJ. A myslím, že tým presmerovaním v životnom cykle sa myslí na iný action/view pred jeho spracovaním.

Ondřej Mirtes

Super, 'this' mě fakt nenapadlo :) Takže problém je asi vyřešen – na změny na serveru budu dávat redirect a pokud se budou indexovat stránky, u kterých je nějakým způsobem změněný pohled (řazení apod.), detekuju poslaný signál a v hlavičce dám do „robots“ noindex.

Napadá vás lepší řešení?

David Grudl

LastHunter napsal(a):

OK, dobře, všiml jsem si, že u ankety se to indexuje víckrát, ale co se týče těch short newsek, tak ne.
Otázka je, jak mám provést redirect? Vím o metodě isAjax() i o redirect(…), ale zpracování signálů probíhá až po fázi, ke které je redirect určen…

Ten životní cyklus je poměrně volný (a klidně i připustím, že nedokonalý, ale jak jej udělat líp?), takže přesměrovat lze v podstatě kdykoliv. Ta zmíněná fáze „pro redirect“ je v obrázku spíš myšlena jako okamžik, kdy může dojít k automatickému redirectu na kanonický tvar URL.

David Grudl

LastHunter napsal(a):

Super, 'this' mě fakt nenapadlo :) Takže problém je asi vyřešen – na změny na serveru budu dávat redirect a pokud se budou indexovat stránky, u kterých je nějakým způsobem změněný pohled (řazení apod.), detekuju poslaný signál a v hlavičce dám do „robots“ noindex.

Napadá vás lepší řešení?

Ano, to je šikovné řešení. Asi před měsícem se objevilo ještě další řešení pomocí značky link (více informací)

<link rel="canonical" href="http://www.example.cz/cesta/ke/kanonickemu/url/">

Ondřej Mirtes

Co prepsat podporu signalu tak, ze by se parametry ovlivnujici aktualni stav URL umistovaly za znak #? Delaji to takhle napr. mapy.cz a prijde mi to prakticke – jednak se uchova stav aplikace i v pripade AJAX pozadavku (ktery nyni adresni radek nijak neovlivni) a jednak by to vyresilo i tento problem s vyhledavaci.

stpnkcrk

Obávám se, že to nepůjde. Část za #, tzv. fragment, se na server vůbec nedostane. https://forum.nette.org/…iewtopic.php?…

_Martin_

LastHunter napsal(a):

Co prepsat podporu signalu tak, ze by se parametry ovlivnujici aktualni stav URL umistovaly za znak #? Delaji to takhle napr. mapy.cz a prijde mi to prakticke – jednak se uchova stav aplikace i v pripade AJAX pozadavku (ktery nyni adresni radek nijak neovlivni) a jednak by to vyresilo i tento problem s vyhledavaci.

Zrovna mapy.cz fungují vícero způsoby:

požadavky řeší AJAXově a adresu změní na mapy.cz#… JavaScriptově po dokončení požadavku
požadavek řeší neAJAXxově (pokud by nebyl podporován), parametry pošlou formou požadavku GET (tj. mapy.cz?query=Praha) a na adresu mapy.cz# přesměrují (aby JavaScript věděl)

Zhruba tak nějak to asi bude, zkoumaje chování té aplikace. Takže v závěru lze říci, že # se používá jen pro zpětnou komunikaci s JavaScriptem, zatímco pro serverovou stranu se požadavky posílají normálně.

Jod

Buď som sprostý, ale ja keď vypnem JS tak mi mapy nejdú vôbec. Vyskočí len červená hláška, že ho musím mať zapnutý.

_Martin_

Jod napsal(a):

Buď som sprostý, ale ja keď vypnem JS tak mi mapy nejdú vôbec. Vyskočí len červená hláška, že ho musím mať zapnutý.

No fajn, ale já přeci nemluvil o tom, že mapy fungují bez JavaScriptu…? V druhém bodě jsem psal o tom, že nefunguje AJAX (čili není podporována ona komponenta k tomu sloužící), nikoliv celý JavaScript.

Ovšem i s vypnutým JS si lze onu funkčnost ověřit – stačí v prohlížeči vypnout automatické přesměrování a zkusit něco vyhledat:

www.mapy.cz
napíšu Praha do políčka a dám Hledej
adresní řádek se změní na http://www.mapy.cz/?query=praha, na stránce bude Moved Permanently: The document has moved here.
pod odkazem here je adresa http://www.mapy.cz/#st=s@sss=1@ssq=praha@@