Почему другие сайты / сервисы не видят мои хеш-адреса?

Question

Почему другие сайты / сервисы не видят мои хеш-адреса?

0

Мой сайт имеет все динамически загружаемое содержимое.

Я написал несколько функций JS, которые меняют контент на основе полученного URL. Если кто-то отправится на сайт www.mysite.com/#1056, содержимое для него будет загружено.

function getLocationHash() {
    //check if there is a location hash in the address bar, get that URL
    if (window.location.hash != '') {
        processURL()
    }
}

Затем он вызывает функцию processURL

function processURL() {
    if (window.location.hash != '') {
        urlHash = window.location.hash;

        //if it a catalog item, it has a number above #1000
        if (urlHash > 10000) {
            getDetail(urlHash);
        }

Это отлично работает для истории или прыгает прямо на URL-адрес на сайте, однако другие сайты не могут следовать этому. Например, если я введу www.mysite.com/#1056 в статус Facebook, FB распечатывает только страницу индекса www.mysite.com. Он не проходит до конца JS. Это потому, что JS ищет свойство "окна"?

То же самое происходит при сканировании Google. Я установил карту сайта со всеми хешированными URL-адресами, но Google только сканирует страницу индекса.

Поэтому возникает вопрос: как мне взять то, что у меня есть, и правильно отформатировать URL-адрес, который другие сервисы, такие как Facebook, и Google могут "видеть"?

Любые советы будут высоко оценены.

frankie 24 окт. 2013, в 13:38

Источник

0

developers.google.com/webmasters/ajax-crawling/docs/...
CBroe 24 окт. 2013, в 11:11

Теги:

javascript

jquery

hash

2 ответа

-1

Это решения, которые я обнаружил, когда я исследовал это.

Для обхода есть "hashbang", как описано на страницах google. https://developers.google.com/webmasters/ajax-crawling/docs/learn-more?hl=nl

А для ссылки на facebook вы можете, например, использовать html5 pushstate. http://badassjs.com/post/840846392/location-hash-is-dead-long-live-html5-pushstate

Henk Jansen 24 окт. 2013, в 09:03

0

Подход hashbang довольно ужасен и устарел в History API.
Quentin 24 окт. 2013, в 11:19
0

@Quentin Я согласен с вами, но я подумал, что предложу ресурс независимо
Henk Jansen 24 окт. 2013, в 11:20
0

@quentin из всего, что я прочитал, кажется, что твиттер и FB все еще используют метод hashbang? Это правда?
frankie 24 окт. 2013, в 20:08
0

@frankie - Они могут использовать его как запасной вариант в древних браузерах, но ни один из них не использует его по умолчанию сегодня. Твиттер сделал большую демонстрацию избавления от них из-за снижения производительности, вызванного загрузкой страницы по умолчанию и перезаписью всего этого новым контентом, загруженным с помощью JS.
Quentin 24 окт. 2013, в 20:09
0

@frankie Я знаю, что Grooveshark все еще использует его.
Henk Jansen 24 окт. 2013, в 20:14

Показать ещё 3 комментария

Ещё вопросы

Подход hashbang довольно ужасен и устарел в History API.
@Quentin Я согласен с вами, но я подумал, что предложу ресурс независимо
@quentin из всего, что я прочитал, кажется, что твиттер и FB все еще используют метод hashbang? Это правда?
@frankie - Они могут использовать его как запасной вариант в древних браузерах, но ни один из них не использует его по умолчанию сегодня. Твиттер сделал большую демонстрацию избавления от них из-за снижения производительности, вызванного загрузкой страницы по умолчанию и перезаписью всего этого новым контентом, загруженным с помощью JS.
@frankie Я знаю, что Grooveshark все еще использует его.

Quentin · Accepted Answer · 2013-10-24T09-47-00.000Z

# Указывает начало идентификатора фрагмента. Это как вы ссылаетесь на часть страницы.

Его часто читают JavaScript для загрузки другого контента через Ajax, но это работает только в том случае, если клиент запускает JS.

Скребки, используемые Google и Facebook, не запускают JS.

Остановить использование идентификаторов фрагментов для загрузки содержимого
Вместо этого используйте реальные URL-адреса
Попросите сервер предоставить полные страницы для этих URL-адресов
Примените свои изменения Ajax с помощью API истории, чтобы обновить URI, чтобы он соответствовал тому, который загружал бы вашу страницу непосредственно с JS

«2. Вместо этого используйте реальные URL-адреса. 3. Предоставляет ли сервер полные страницы для этих URL-адресов? Итак, вы предлагаете php-решение?
Решение на стороне сервера. Вы можете использовать PHP, если хотите, но есть много других вариантов. Конечно, он будет использоваться только для начальной загрузки и не-JS-клиентов.
Просто чтобы подтвердить мое понимание здесь - страница, которую читает Google или FB, должна обслуживаться, а не генерироваться на стороне клиента - правильно? Таким образом, что-либо, включающее JavaScript, сгенерированный на стороне клиента контент (будь то хешированный URL-адрес или нет), не будет «видно»?
Верный. Не делайте контент доступным только через JS, если вы хотите, чтобы его читали боты.
Спасибо за советы. Вы говорите "только через JS". Так как весь мой код уже находится в JS, я должен оставить это для браузеров и сделать отдельный код только для ботов? Что, если код бота - это просто грубый HTML (изображения и текст) без всей информации о макете (таблицы и т. Д.)? Я мог, например, увидеть использование php для заполнения тега <P> всего текста, проанализированного из файла json (content), в неотформатированном виде. Будет ли что-то подобное работать?
Тогда люди получат некрасивую страницу, когда придут из поисковика. Делай, что я сказал в ответе. Пусть каждый URL даст полную страницу. Если вы хотите заняться Ajaxy, то используйте JS, чтобы перевести страницу в то же состояние, в котором она была бы, если бы вы загрузили этот новый URL-адрес с сервера и использовали pushState, чтобы поместить этот URL-адрес в историю.