pushState та SEO

Багато людей говорять: використовуйте pushState, а не hashbang.

Що я не розумію, так це те, як би ви були зручними для пошукової системи, не використовуючи hashbang?

Імовірно, ваш вміст pushState генерується за допомогою клієнтського коду JavaScript.

Таким чином, сценарій:

Я на example.com. Мій користувач натискає посилання:href="example.com/blog"

pushState фіксує клік, оновлює URL-адресу, захоплює десь файл JSON і створює список публікацій блогу в області вмісту.

За допомогою hashbangs Google знає, що потрібно перейти до URL-адреси escaped_fragment, щоб отримати їх статичний вміст.

За допомогою pushState Google просто нічого не бачить, оскільки не може використовувати код JavaScript для завантаження JSON і подальшого створення шаблону.

Єдиний спосіб зробити це, я бачу, - це відобразити шаблон на стороні сервера, але це повністю заперечує переваги надсилання рівня програми клієнту.

Тож я правильно розумію, pushState взагалі не підходить для SEO для додатків на стороні клієнта?

А як щодо використання мета-тегу, який Google пропонує для тих, хто не хоче хеш-чубків у своїх URL-адресах: <meta name="fragment" content="!">

Дивіться тут для отримання додаткової інформації: https://developers.google.com/webmasters/ajax-crawling/docs/getting-started

На жаль, я не думаю, що Ніколь пояснила питання, яке, на мою думку, було в ОП. Проблема просто в тому, що ми не знаємо, кому ми обслуговуємо вміст, якщо не використовуємо хеш-баг. Пуштейш не вирішує цього для нас. Ми не хочемо, щоб пошукові системи повідомляли кінцевим користувачам перейти до якоїсь URL-адреси, яка виплюває неформатований JSON. Натомість ми створюємо URL-адреси (які викликають інші виклики до більшої кількості URL-адрес), які отримують дані через AJAX і представляють їх користувачеві у бажаний спосіб. Якщо користувач не є людиною, тоді як альтернативу ми можемо подати html-знімок, щоб пошукові системи могли належним чином направляти користувачів до URL-адреси, за якою вони очікували б знайти потрібні дані (і в презентабельній манері). Але головна проблема полягає в тому, як нам визначити тип користувача? Так, ми можемо використовувати. htaccess або щось інше, щоб переписати URL-адресу пошукових ботів, які ми виявляємо, але я не впевнений, наскільки це повний захист і захист від майбутнього. Також може бути можливо, що Google може покарати людей за подібні дії, але я не досліджував це повністю. Тож комбінація (pushstate + мета-тег google) є, мабуть, можливим рішенням.

Є чи pushStateпогано , якщо вам потрібно пошукові системи , щоб прочитати зміст?

Ні, мова pushStateйде про те , щоб виконати той самий загальний процес для hashbangs, але з більш красивими URL-адресами. Подумайте, що насправді відбувається, коли ви використовуєте hashbangs ...

Ти кажеш:

За допомогою hashbangs Google знає, що потрібно перейти до URL-адреси escaped_fragment, щоб отримати їх статичний вміст.

Іншими словами,

1. Google бачить посилання на example.com/#!/blog
2. Запити Google example.com/?_escaped_fragment_=/blog
3. Ви повертаєте знімок вмісту, який повинен побачити користувач

Як бачите, він уже покладається на сервер. Якщо ви не подаєте знімок вмісту з сервера, ваш веб-сайт не індексується належним чином.

То як Google побачить щось із pushState?

За допомогою pushState Google просто нічого не бачить, оскільки не може використовувати javascript для завантаження json і згодом створення шаблону.

Насправді, Google побачить, на що може запитати site.com/blog. URL-адреса все ще вказує на ресурс на сервері, і клієнти все ще виконують цей контракт. Звичайно, для сучасних клієнтів Javascript відкрив нові можливості для отримання та взаємодії з вмістом без оновлення сторінки , але контракти однакові.

Тож передбачувана елегантність pushStateполягає в тому, що він обслуговує однаковий вміст для всіх користувачів, старих і нових, підтримує JS і ні, але нові користувачі отримують покращений досвід .

Як змусити Google бачити ваш вміст?

1. Підхід Facebook - подайте той самий вміст за URL-адресою, на site.com/blogяку перетвориться ваш клієнтський додаток, коли ви натиснете /blogна стан. (Facebook ще не використовує pushStateте, що я знаю, але вони роблять це за допомогою hashbangs)

2. Підхід Twitter - перенаправляти всі вхідні URL-адреси на еквівалент hashbang. Іншими словами, посилання на "/ блог" штовхає /blogдержаву. Але якщо це запитується безпосередньо, браузер опиняється на #!/blog. (Для Googlebot це буде переадресовано _escaped_fragment_як завгодно. Для інших клієнтів ви можете pushStateповернутися до красивої URL-адреси)

То ви втрачаєте _escaped_fragment_здатність з pushState?

У декількох різних коментарях ви сказали

втік фрагмент зовсім інший. Ви можете обслуговувати чистий нетемізований вміст, кешований вміст, і не піддаватися навантаженню, яке звичайні сторінки.

Ідеальне рішення - Google може або створювати веб-сайти JavaScript, або впровадити якийсь спосіб дізнатися, що існує екранований фрагмент URL-адреси навіть для сайтів pushstate (robots.txt?).

Переваги, про які ви згадали, не відокремлені _escaped_fragment_. Те, що він робить переписування за вас і використовує спеціально названий GETпараметр, насправді є деталлю реалізації. Там немає нічого особливого про це , що ви не могли б зробити зі стандартними URL , - іншими словами, переписати /blogв /?content=/blogна свій власний , використовуючи mod_rewrite або вашого сервера еквівалентні.

Що робити, якщо ви взагалі не обслуговуєте вміст на стороні сервера?

Якщо ви не можете переписати URL - адреси і служать свого роду змістом в /blog(або якому б стані ви виштовхувати в браузері), то сервер не насправді більше не дотримується договору HTTP.

Це важливо, оскільки перезавантаження сторінки (з якоїсь причини) призведе до переміщення вмісту за цією URL-адресою. (Див. Https://wiki.mozilla.org/Firefox_3.6/PushState_Security_Review - "view-source і reload завантажуватимуть вміст у новому URI, якщо його було натиснуто.")

Справа не в тому, що малювати користувальницькі інтерфейси на стороні клієнта і завантажувати вміст за допомогою API JS - погана мета, це просто те, що це насправді не враховується за допомогою HTTP та URL-адрес, і це в основному не є зворотним.

На даний момент це саме те, для чого призначені hashbangs - для представлення різних станів сторінок, які переміщуються на клієнті, а не на сервері. Наприклад, перезавантаження завантажить той самий ресурс, який потім зможе прочитати, проаналізувати та обробити хеш-значення.

Буває так, що вони також використовувались (зокрема, Facebook та Twitter) для зміни історії на розташування на стороні сервера без оновлення сторінки. Саме в тих випадках використання люди рекомендують відмовитися від hashbangs для pushState.

Якщо ви робите весь вміст на стороні клієнта, вам слід думати про це pushStateяк про частину більш зручного API історії, а не про вихід із використання hashbangs.

Усі цікаві розмови про pushState і #!, і я досі не можу зрозуміти, як pushState замінює мету #!, Як просить оригінальний плакат.

Наше рішення, щоб зробити наш веб-сайт / додаток Ajax на основі JavaScript на 99% зручним, звичайно, за допомогою #!. Оскільки візуалізація клієнта здійснюється за допомогою HTML, JavaScript та PHP, ми використовуємо таку логіку в завантажувачі, керованому нашою сторінкою. Файли HTML повністю відокремлені від JavaScript та PHP, оскільки ми хочемо однаковий HTML в обох (здебільшого). JavaScript і PHP роблять в основному одне і те ж, але PHP-код менш складний, оскільки JavaScript - це набагато багатший інтерфейс користувача.

JavaScript використовує jQuery для введення в HTML потрібного вмісту. PHP використовує PHPQuery, щоб вводити в HTML потрібний вміст - використовуючи "майже" ту саму логіку, але набагато простішу, оскільки версія PHP буде використовуватися лише для відображення SEOable версії з SEOable посиланнями і не буде взаємодіяти з нею, як версія JavaScript.

Усі три компоненти, що складають сторінку, page.htm, page.js та page.php існують для будь-чого, що використовує фрагмент, що вийшов, щоб знати, чи слід завантажувати версію PHP замість версії JavaScript. Версія PHP не повинна існувати для вмісту, що не підлягає SEO (наприклад, сторінок, які можна побачити лише після входу користувача). Все просто.

Я все ще здивований, як деякі розробники інтерфейсу вдаються до розробки чудових сайтів (з багатством Документів Google), не використовуючи серверні технології в поєднанні з браузерними ... Якщо JavaScript навіть не ввімкнено, то наше 99% рішення JavaScript звичайно, нічого не робитиме без PHP на місці.

Можна мати гарну URL-адресу, щоб потрапити на сторінку, що обслуговується PHP, і перенаправити на версію JavaScript, якщо JavaScript увімкнено, але це неприємно з точки зору користувача, оскільки користувачі є найбільш важливою аудиторією.

На додатковій записці. Якщо ви робите просто простий веб-сайт, який може функціонувати без будь-якого JavaScript, тоді я бачу, що pushState є корисним, якщо ви хочете поступово покращувати свій досвід користування від простого статично відтвореного вмісту до чогось кращого, але якщо ви хочете надати своєму користувачеві найкращий досвід із ходу, отримаємо ... припустимо, ваша остання гра, написана на JavaScript або щось на зразок Google Docs, тоді її використання для цього рішення дещо обмежує, оскільки витончено відступати може зайти так далеко, перш ніж досвід користувача буде болючим порівняно з баченням сайту.