Javascript frontend

В 6 сутринта... даже не помня да съм го писал, върнах се леко подпийнал :D . Имам предвид, че спа приложенията са доста специфични, и като цяло ако подобряваш ux/ ui с тях, съсипваш seo-to. Кофти се оптимизират такива страници, сравнение с html, просто е повече работа да нагласяш нещата.
 
В 6 сутринта... даже не помня да съм го писал, върнах се леко подпийнал :D . Имам предвид, че спа приложенията са доста специфични, и като цяло ако подобряваш ux/ ui с тях, съсипваш seo-to. Кофти се оптимизират такива страници, сравнение с html, просто е повече работа да нагласяш нещата.
Хахха .. не бях погледнал часа на писане.
Какво имаш предвид, че трябва да се нагласи повече ?
пс: Не се заяждам, любопитно ми е.
 
html си е html! Така че дали ще го правиш като уеб сървъра сервира html файлове, дали някоя backend технология ще output-ва html или пък JS ще го "рисува" то пак си остава html.
 
Ами това, което съм пипал, въобще не ставаше за seo, нямаше почти контент, 80% от сайта беше недостъпен поради login неща, имаше проблеми с # урл-ите, имаше и проблеми с back бутона, беше angularjs , сега доколкото знам angular cli, react се оправят много добре с back / forward бутоните и както каза някой ползва се #! .
 
Ако зарежда контента асинхронно, Гугъл и другите паяци не го обхождат.

Асинхронно ще рече да зареди интерфейса/рамката (ХТМЛ-а) и каквито останали статични асети има веднага, а съдържанието (динамичния контент) - след едиколко си милисекунди. Обикновено се вижда някакъв спинър да върти докато дойде резултата от базата данни. Та каквото дойде със закъснение, ботовете го пропускат.

СПА-тата обикновено са на тоя принцип, но може да са направени да пакетират интерфейс+ съдържание и на сървъра, преди да го изпратят до браузъра. В тоя случай ботовете виждат съдържанието.
 
Ако зарежда контента асинхронно, Гугъл и другите паяци не го обхождат.

Асинхронно ще рече да зареди интерфейса/рамката (ХТМЛ-а) и каквито останали статични асети има веднага, а съдържанието (динамичния контент) - след едиколко си милисекунди. Обикновено се вижда някакъв спинър да върти докато дойде резултата от базата данни. Та каквото дойде със закъснение, ботовете го пропускат.

СПА-тата обикновено са на тоя принцип, но може и да са направени да пакетират интерфейс+ съдържание и на сървъра, преди да го изпратят до браузъра. В тоя случай ботовете виждат съдържанието.
Да прав си, но това беше така преди 5-6-7-8 години.
Вече ги обхождат и всичко е наред, както и писах по-горе.
 
@Blossy дай да я видим тази практика, защото реалността казва нещо съвсем различно.
 
Не е вярно. Казаха че уж да, ама на практика не.

Server-side rendering е по-актуален топик от всякога.

https://medium.com/@gajus/pre-rende...ved-perceived-page-loading-speed-47075aa16d24
И мен как ме индексира гугъл ? Аз имам single page app и всичко идва от ajax requests.
В webmasters tools когато му дам Извличане като Google и го извлича както трябва.

А в година, когато SPA's frameworks са по-актуални от всякога, не смятам, че най-голямата търсачка в света ще не може да се справи с този проблем. Въобще звучи ли ти сериозно ? Те правят неща, които хората дори и не предполагат, че са възможни, а да не могат да заредят един javascript на своя сървър ? Come on .. srsly ?
 
При все че ангулар е дело на Гугъл и се опитват да го развиват, смятате ли, че не са си оправили търсачката, така че да работи поне с него?

Според мен отдавна са ги адресирали тия проблеми с четенето. Въпроса е, дали смятат за редно да класирйт напред такива страници. Ама това вече е друга тема.
 
Не е вярно. Казаха че уж да, ама на практика не.

Server-side rendering е по-актуален топик от всякога.

https://medium.com/@gajus/pre-rende...ved-perceived-page-loading-speed-47075aa16d24
Всъщност прочетох статията и е добре написана, типично за medium де. Което ме провокира да потърся още малко по темата.
Започнах с това - https://developers.google.com/webmasters/ajax-crawling/docs/learn-more
След това с https://developers.google.com/webmasters/ajax-crawling/docs/specification

И в край на сметка - https://searchengineland.com/google-will-stop-crawling-old-ajax-crawling-scheme-q2-2018-287653

Малко по-рано в темата се дискутираше pushState. В крайна сметка го имплементирах и сега адресите ми са example.com/blog вместо example.com/#!blog . Имам да правя още един куп промени и да сменям релативни с абсолютни пътища и сигурно ще стане чак утре. Като кача промените и има резултат в Конзолата, ще пиша да видим как е.

EDIT:
Но проблемът с Facebook остава. Когато споделя блог статия, мета таговете които взима са като на началната страница. За този случай, мисля че варианта е html snapshot ...
 
Последно редактирано:
Проблема с # е от незнание. Това е служебен символ, така че как очаквате като го имате да работи каквото и да било както ви се иска? Google си го разбират, но само те защото са решили така да бъде по подразбиране в angular (даже май вече го промениха).

@Svetliooo за мета данните: както променяш другите данни така променяй и тях.
 
Искам да се извиня на Biossy за тона ми в първото ми съобщение към него. Ако не беше писал, нямаше да направя този research и да разбера как всъщност стоят нещата. Трябва да има повече дискусии, и е хубаво когато са подкрепени с аргументи :)

@AMitrev Да, служебен е, просто в моят framework беше по подразбиране и реших да продължа с него, без да обръщам внимание дали това всъщност ще е проблем. Вероятно са го използвали заради събитието window.on('hashChange'), при pushState просто използват друго събитие и всичко работи.

Ами при SPA е малко по-различно. Преди <body> и след </body> е еднакво съдържанието на всички страници. А когато заредя някой модул имам контрол само в неговият контекст. Разбира се мога да достъп с js мета таговете, но FB не обръща внимание на това. Явно не изпълнява javascript и не вижда промените.
А съдържанието на страницата го виждам чак след като се зареди модула и изпрати заявка към сървъра.
Т.е. това, което "вижда" FB crawler-a е г/д това
HTML:
<html>
<head><!-- some meta tags here -->
<body>
<div id="content"><!-- insert module's html when the module is loaded --!></div>
</body>
</html>
Т.е. една страница с 10 реда html, която има попълнени мета тагове по подразбиране.

Варианта, който се сещам сега, е да направя от backend-a когато страницата е отворена от FB Crawler-a и е блог статия, то тогава да я заредя и да попълня мета данните с тази информация. Така ще си спестя да правя html snapshot, но ще правя две заявки за едно и също нещо.
Ще опитам този вариант и ще споделя резултат. Но не се ангажирам със срок ... имам доста булшит на главата в момента.
 
Имаш доста да учиш. Попълни дупките в знанията си.

Ще ти дам малко hint-ове:
JS
DOM
onload
 
Така направих следните промени
Гледам дали страницата се отваря от Crawler-a на ФБ
Код:
public static function detectFacebookCrawler() {
        return strpos($_SERVER["HTTP_USER_AGENT"], "facebookexternalhit/") !== false ||
            strpos($_SERVER["HTTP_USER_AGENT"], "Facebot") !== false;
    }
И след това дали страницата е например Блог, за да мога да изкарам някакво съдържание. И ако е, правя заявка за да взема статията и основната снимка.

Много нерви загубих с og:url таг-а. Адресът трябва да е същият, като този на статията, докато при мен си беше адреса на сайта. По този начин правеше redirect и взимаше стойностите по подразбиране.
Код:
<meta property="og:url" content="<?= SITE_URL . substr($_SERVER['REQUEST_URI'], 1) ?>">
Ето така си реших проблема.

Ако някой има по-добро решение, нека да сподели.
Ако се чудите дали FB зарежда JS, не, не зарежда. За доказателство отворете следния адрес: https://developers.facebook.com/tools/debug/sharing . Вкарайте си сайта, натиснете debug и най-долу има Scraped URL - така ще видите какво точно вижда бота им.
Това важи и за тези, които дават акъл да уча DOM & .load :D
 

Горе