Komerční web a SEO - JQuery a PHP?

[registrovany123]

Mám rozdělaný takový web, který bych chtěl, aby se do budoucna  ubíral cestou možné monetizace, takže už teď ze začíátku bych měl myslet na dobré SEO.

Původně jsem ho udělal ve Vue.js, ale teď kvůli SEO zjišťuju, že to možná není nejlepší volba.

Snažím se zorientovat v tom, jak web udělat s dobrým SEO v client side rendering technologii, a vychází mi z toho, že javascript podporuje zatím jen Google.

Čím více informací si zjišťuju, tím víc mi z toho vychází, že nejlíp udělám, když použiju "oldschool" technologie, jako je PHP a k tomu jQuery.

Přijde mi to smysluplnější, než třeba Next.js.

[Reklama]

[Filip Jirsák (forum)]

K použití jQuery neexistuje žádný smysluplný důvod. I s JavaScriptem lze dělat server-side renderování, třeba právě ten Next.js. Osobně bych ale použil něco jiného, než Next.js, to už je příliš velký moloch.

[martyd420]

Abys udělal opravdu funkční web ve Vue, nebo Nextu s ohledem na seo, tak potřebuješ top skill (dlouhé roky praxe před vue a dlouhé roky s ním) a musíš přesně vědět co a jak vevnitř toho js frameworku funguje a kdy použít server side renderninig (ano, server side renderning v js frameworku, po letech už i frontendové frameworky přišly na to, co php (a všichni i ve zvláštních školách) vědělo v době svého vzniku - vytváření většiny struktury html na serveru prostě s ohledem na webové technologie dává velký smysl.) A renderovat nextem html na serveru je jako rovnák na ohejbák. Jako zatloukat hřebík vrtačkou - jako jo, je to technicky možné. Chlupatí mi z toho nehty na patách.
A i když dnes boti používají headless prohlížeče, aby tím javascriptovým peklem prošly, zdaleka to není 100% pravidlo a porazit takové weby v pozici v serp je opravdu maličkost.  Dobrých webů v reactu/vue jsou na světě jednotky. (já vím o jednom funkčním)
Takže naprostý základ je renderovat obsah na serveru (php je na weby ideální, ale až tolik na tom nezáleží) a teprve pak s rozumem používat ajax na interakce s uživatelem. (taky je jedno, jestli to bude jquery, htmx, nebo vanilla js)
Naprostá většina react/vue webů z posledních let je odpoad zejména proto, že ti lidi skočili z nuly ronovu do reactu a nechápou souvislosti, nechápou k čemu je html a nevědí, že react je js framework a ne programovací jazyk   Vue / react používám jen v aplikacích v electronu, apod., kde to (možná, trochu, ..) dává smysl.

[registrovany123]

Technicky vzato, cokoliv udělám ve Vue nebo v Reactu, tak můžu velkou část toho udělat i v jQuery, pokud se budu držet pravidla Keep it simple.

Pointa je, že pro React je tzv. "Model" jsony, které mám někde v JS properties.

JQuery funguje podobně, ale jeho "Modelem" je ta vykreslená HTML stránka a jednotlivé tagy.

Navíc, nemám v plánu používat Store - to vnímám jako zbytečnou komplikaci, raději udělám rychlý backend v AWS, než se trápit se store. Nepotřebuju nutně single page web aplikaci - ta je dobrá vesměs jen pro store a pro router, ale na router mi stačí backend. Store komplikuje vývoj.

Díval jsem se, jak funguje Next.js, a nevidím tu pointu, v čem mi to zase tak pomůže oproti Server side a k tomu JQuery.

Nějaký tým v korporátu nebo firmě to s jQuery zmastí - ale já jsem jednotlivec a jsem schopen si v tom udržovat pořádek.

[Standa Blábol]

Podivej se na Nuxt3, pokud mas neco rozdelaneho ve vue, prvni volba.
Umi to i hybrid rendering, kde si jenom SEO important casti nechas udelat serversice a ostatni jako klasicke clientside vue komponenty.
Jako prvni pokus klidne jenom spravne nastavovat title a meta tagy.

[Reklama]

[hknmtt]

Mozes spravit SPA vo Vue a Google ti to zaindexuje(viem z vlastnej skusenosti). Avsak ak spravis SPA ktora taha data z backendu, tak tam budes mat problem(taktiez viem z vlastnej skusenosti). Navyse Yandex, Bing,.. su za opicami stale, ak ide o JS. Takze zalezi o aky typ webu sa jedna.

Co sa jQuery tyka, je to uplne v pohode. Ak nepotrebujes stav na klientovi, jQuery moze byt dobra volba. Ale zase dnes uz sa da robit s CSS mnoho veci, na ktore uz JS nie je potrebny(rozne animacie, skryvanie/zobrazovanie, tranzicie, transformacie...). Takze si musis zistit, co od webu ocakavas a pozriet na moznosti podpory a kolko JS realne, ak vobec, budes potrebovat.

Ak chces SPA ale chces mat stale lahko indexovatelne HTML, pozri sa na https://data-star.dev/ je to take HTMX 2.0.

[RDa]

Se vam musim smat, mate X technologii, aby jste byli frikuulini, ale je vam to celkem k prdu

.. a pak se kruh uzavrel, a developeri zjistili, co je to HTTP a HTML, a ze k tomu nepotrebuji deset mega skriptu

[registrovany123]

Je fakt, že když použiju třeba tohle měření:

https://pagespeed.web.dev/analysis/https-seznam-cz/wafr6g6dpj?form_factor=desktop

Aby mi to změřilo SEO, tak je tomu úplně fuk, že to běží ve Vue.js, zjevně to vůbec nemá na SEO u Google vliv. Dívá se to na jiné věci.

[Filip Jirsák (forum)]

Avsak ak spravis SPA ktora taha data z backendu, tak tam budes mat problem(taktiez viem z vlastnej skusenosti).

Problém není v tahání dat z backendu. Google ten web vykresluje v prohlížeči (nebo s pomocí jádra prohlížeče), počká nějakou dobu na zobrazení stránky a výsledek pak zaindexuje. Tj. problém není v načítání dat z backendu, ale v tom, že trvá dlouho, než se stránka plnohodnotně zobrazí.

Co sa jQuery tyka, je to uplne v pohode.

Není. Neexistuje žádný důvod, proč dnes v nových aplikacích používat jQuery. I když chcete programovat v JavaScriptu, bez frameworků, pořád jsou lepší možnosti. Zejména nativní API prohlížečů.

[registrovany123]

Pořád je tady dilema, jestli použít SSR nebo ne. Ten web co dělám jde rozdělit na web, a na webovou aplikaci. Mám ten dojem, že bývá populární mít na webu Blog kvůli zvýšení zaindexování v browserech:

blog.mujweb.cz

Ten by se udělal s SSR.

Potom technicky vzato landing page by mohla být SSR a z ní odkaz do SPA webové aplikace, ale moc se mi to nelíbí, protože už n té landing page bych chtěl mít udělané věci z té webové aplikace... Kdybych se vydal touto cestou, tak bych do robotx.txt a sitemap.xml dal jen SSR stránky a na zbytek bych se vyprdnul.

[Kit]

Mám rozdělaný takový web, který bych chtěl, aby se do budoucna  ubíral cestou možné monetizace, takže už teď ze začíátku bych měl myslet na dobré SEO.

Původně jsem ho udělal ve Vue.js, ale teď kvůli SEO zjišťuju, že to možná není nejlepší volba.

SPA není zrovna přátelské k SEO. Pokud stránka má sloužit jako e-shop, tak určitě SSR. Podstatné je, aby návštěvník, který si cokoli najde ve vyhledávači, se na ten objekt dostal hned na ten první klik a aby si odkaz na tu stránku mohl uložit, resp. aby ho mohl přeposlat.

[Filip Jirsák]

Podstatné je, aby návštěvník, který si cokoli najde ve vyhledávači, se na ten objekt dostal hned na ten první klik a aby si odkaz na tu stránku mohl uložit, resp. aby ho mohl přeposlat.

Ani jedno není s SPA vůbec žádný problém.

Problémy SPA renderovaných jen na klientovi jsou z hlediska SEO dva:

• Některé vyhledávače a jiní roboti si s takovými stránkami neporadí nebo je „vidí“ velmi špatně – nevidí obsah renderovaný až na klientovi.
• Stránka se vyrenderuje teprve po té, co se stáhnou potřebné skripty.

Existuje spousta dobrých možností, jak řešit webové stránky přátelské k SEO i k uživatelům.

SPA se SSR je z tohoto pohledu vůbec nejlepší přístup, protože první vyrenderování je rychlé, přechody mezi stránkami jsou ještě rychlejší, a i hloupí roboti vidí obsah stránky.

Dále je možné používat multi-page aplikace, které se vyrenderují na serveru (ať už v JavaScriptu, v PHP, v Javě nebo v něčem jiném) a na klientovi je možné je obohatit JavaScriptem. Záleží na tom, jak moc klientského kódu je tam potřeba. Dá se tam použít čistý JavaScript, případně s nějakými moderními knihovnami (kam v žádném případě nespadá jQuery). Nebo je možné použít ostrovní architekturu (island architecture), kdy je framework (React, Preact, Vue, …) použitý pouze v dynamických částech stránky.

V e-shopu se mění velká část obsahu, takže největší smysl dává SPA se SSR. Pokud se vám nechce to řešit, šel bych cestou klasické MPA aplikace, tedy plné renderování na serveru.

[registrovany123]

Když se nad tím tak zamýšlím, směrodatné je pro mě to, jestli search engine bude zcela respektovat sitemap.xml, který vytvořím.

Jsem schopný vygenerovat SSR stránky pro všechno potřebné a dát je do sitemap. Ale podmínka je, že potřebuju mít už tu landing page udělanou jako SPA.

Tu si sice engine typu Yandex nepřečte, ale uvidí v ní Titulek a uvidí v ní meta s Description stránky - z toho bude schopný vygenerovat záznam do vyhledávače. Taky načte Favicon.

Nepotřebuju, aby něco víc na té landing page načetl. Co ale potřebuju je, aby si otevřel sitemap.xml, a na té budu mít odkaz na všechno - tzn. veškeré blogové články, stránky s vyrenderovanými "itemy" (nechci tady říkat co přesně budu dělat, ať někdo nedá jisté firmě echo) a další věci.

Já už si zařídím, že když se nějaký user dostane na můj web vyhledávačem na nějakou SSR page (Na Blog, nebo na Item), tak si ho navedu do SPA aplikace.

Takže směrodatné pro mě je, aby nějaký ruský Yandex, co mi bude chroustat můj web, se na to "nevykašlal" protože už na landing page to bude mít javascript, ale hezky vlezl do toho sitemap.xml - a tam já už jsem schopný udělat hodně slušného pavouka, že když user zadá do search enginu jistý názez "itemu", tak by to mohlo můj web vrátit.

Dneska je populární mít kvůli popularitě webu na tom webu Blog. Pro mě je Blog jenom balast, ale prostě je to populární. Odkaz na Blog bude schovaný někde v SPA, takže search engine jako Yandex se na něj nedostane, ale půjde se na něj dostat přes sitemap.xml. A o to jde.

[to_je_jedno]

Co prese ja Next.js "moloch"? Ty moznosti ktere to ted ma, dobra dostupnost konektoru pro ruzny CMS apod je v pohode. A to jsem primarne backend, ale weby v Nextu clovek nachysta fakt rychle a efektivne. Samo se ti to vytvori jako typescript projekt, nahodi ti to tam rovnou Tailwind apod. Pro SEO idealka v tom, ze mu serviruju v podstate pripraveny staticky html.

[lazywriter]

Jak to psali přede mnou, jQuery v dnešní době už není potřeba. Byť v něm dělám posledních 15 let, tak v moderních prohlížečích (resp. méně než nějakých 5 let  starých) už lze většinu věcí dosáhnout stejně pohodlně (tj. bez nutnosti nějakých polyfillu apod.) i ve vanilla Javaskriptu. Takže na one-man show bohatě stačí něco na server side/API (PHP, Python, resp. nějaký lehký framework - v Pythonu třeba Flask, který se bude starat právě o navigaci a podobné věci) a čistý Javaskript.