- Katılım
- 11 Kas 2010
- Mesajlar
- 204
- Tepkime puanı
- 8
- Puanları
- 38
- Yaş
- 65
- Web sitesi
- www.iks-info.narod2.ru
Sorry, the post was written by specials and therefore it will be a little complicated for a simple user ...
But no less interesting ... I think so ...
Further, the author’s text ...
Evidence
The Instant Preview feature is why we see annotation screenshots in SERP. These previews have an impressive opportunity: they not only display a screenshot of the page, but also visually highlight and underline the text that suits your request. This is simply impossible to achieve with a simple text spider. Screenshots of flash pages - you may already have noticed screenshots of flash sites in the Google Webmaster Tools. Wait ... I thought Google did not see the flash ... AJAX POST request confirmation - Matt Cutts confirmed that GoogleBot can handle AJAX POST requests, and, by chance, this happened a few hours after Rand posted the article “ GoogleBot is Chrome. ” By definition, AJAX is JavaScript-loaded content when an action occurs after the page loads. Therefore, it cannot be tracked with a text spider, because the text spider does not execute JavaScript, but only receives the existing code as provided at the initial download. Google tracks Flash - Matt Clayton also showed me some server logs in which GoogleBot accessed URLs that are accessible only through the built-in Flash modules on Mixcloud.com: 66.249.71.130 "13 / Nov / 2011: 11: 55: 41 + 0000 "" GET / config /? W = 300 & h = 300 & js = 1 & embed_type = widget_standard & feed = http% 3A // www.mixcloud.com / chrisreadsubstance / bbe-mixtape-competition-2010.json & tk = TlVMTA HTTP / 1.1 "200 695" - "" Mozilla / 5.0 (compatible; Googlebot / 2.1; + http: //www.google.com/bot.html) "66.249.71.116" 13 / Nov / 2011: 11: 51: 14 +0000 "" GET / config /?w=300&h=300&js=1&feed=http%3A//www.mixcloud.com/ZiMoN/electro-house-mix-16.json&embed_type=widget_standard&tk=TlVMTA HTTP / 1.1 "200 694" - "" Mozilla / 5.0 ( compatible; Googlebot / 2.1; + http: //www.google.com/bot.html) Let's say this is not news, but another post from 2008 explains that Google “treats Flash files in the same way as they would a person by entering data, and so on. ”And, you mean, how does a person work with a browser? Site - Although Google could get website load time from the toolbar and usage data from Chrome, it’s much more reliable for it to get this information by indexing the network itself. Without executing all the page code, it is almost impossible to accurately calculate the loading time of this page. Until now, all this may have sounded like Google is just a few steps from SkyNet. And optimizers and Google have been assuring us for many years that the search robot (spider) has a textual basis, so this may seem fantastic to you. I assure you, this is not so, and many of the things that I am talking about are accessible to programmers even with a much less strong team of engineers than Google. Meet PhantomJS PhantomJS is a headless Webkit browser that can be controlled through the JavaScript API. With a little script automation, you can easily turn your browser into a spider. It's funny that its logo is a ghost similar to the ghosts in Pacman, and the concept is quite simple: PhantomJS is used to load the page as the user sees it in Firefox, Chrome or Safari, extract materials and track links. PhantomJS has countless applications for parsing information and other types of website analysis, and I advise the SEO community to realize this before we move on. Josh used PhantomJS to prepare some evidence for the information I posted on SearchLove. Earlier, when I released GoFish, I already mentioned that I had difficulty collecting information about the growth in the number of requests from Google Insights using a text spider due to the fact that the list of these questions is provided through AJAX. Richard Baxter suggested that this data can be easily collected using the XPath string, and this convinces me that the search importXML architecture in Google Docs is also based on a headless browser. It is written in red on the diagram: "In the usual way, this data cannot be obtained, because it is AJAX." Anyway, here Josh takes this data off the page using PhantomJS. It is not possible to take screenshots with a text spider, but using the headless webkit browser is as simple as that. In this example, Josh shows how screenshots are taken using PhantomJS. Chromium is a public branch of the Webkit browser, and I strongly doubt that Google created the browser for purely altruistic reasons. The above study suggests that GoogleBot is a multi-threaded headless browser based on the same code. Why don't they tell us anything? Well, actually, they say, but claim that the "robot indexer for creating previews" is a completely separate object. Imagine this robot as "Mrs. Pacman." A member of the main forum of webmasters complained that as a user agent, they display in their logs "Mozilla / 5.0 (X11; U; Linux x86_64; en-US) AppleWebKit / 534.14 (KHTML, like Gecko) Chrome / 9.0.597 Safari / 534.14" and not "Mozilla / 5.0 (en-us) AppleWebKit / 525.13 (KHTML, like Gecko; Google Web Preview) Version / 3.1 Safari / 525.13". John Mu said: “As a tool for testing instant previews, we use a user agent similar to Chrome, so that we can compare what the browser will see (using this user agent) with what we see using Googlebot’s cached access preview. " While the headless browser and Googlebot, as we know, are different, it seems to me that they always browse the pages in parallel and collect information for indexing and ranking. In other words, it’s like a simultaneous two-user version of Pacman with Mrs. Pacman in 3D and regular Pacman, who play on the same level at the same time. In the end, it would not make sense for spiders to browse the entire network twice separately. So why isn’t everything so clear regarding these opportunities, because they are related to ranking? In a nutshell: search quality. Hiding behind the flaws of text spiders, search engines can continue to use them as a scapegoat to explain their imperfect results. They can continue to move in the direction of things like the alleged AuthorRank and rely on SEO to literally optimize their search engines. They can continue to say vague things, like “don't chase the algorithm”, “improve user experience” and “we take into account what is visible without scrolling”, which makes SEO experts make Google's job easier. The main products of Google (and their only products, if you ask Eric Schmidt in court), is search, and if you release information that their capabilities are much higher than declared, then they will have to improve the quality of the search. They don’t tell us about it, because as opportunities grow, so does responsibility. What does this mean for us? When Josh and I presented our research, many people asked me: “How should this change my actions in terms of SEO?” In my opinion, there are three points: 1. Javascript will not help you hide anything. If it seemed to you that with the help of JavaScript postloading you could hide some content - stop doing this. Luring and switching is now a 100% inefficient method. Pacman sees everything. 2. The user experience is extremely important. Google can literally see your site now! As Matt Cutts said, they look at what is above the scroll border, and therefore can take into account when ranking how much advertising is presented on the page. Google can use behavioral data along with site design to determine how useful the site is to people. This is both pleasing and scary, but it also means that every SEO specialist should buy the Circle of Do Not Make Me Think book. 3. SEO tools need to get smarter. Most SEO tools are based on text scrapers, and although many of them are quite complex (SEOmoz currently leads), they still look a lot like Pacman in the 80s. If we want to understand what Google really takes into account when ranking pages, we need to consider more aspects. - When discussing such things as Page Authority and the likelihood of spam, you need to visually check the pages from the point of view of the program, and not be limited to simple indicators, such as the distribution density of keywords and the link graph. In other words, we need a user perception quality indicator (UX Quality Score) that would be influenced by visual analysis and possible modifications to spam. - You should compare how much the page displayed differs from what can be assumed by the code. This can be called the Delta Score. - When assessing the distribution of the proportion of links on a page, one should also take into account dynamic transformation (dinamic transformations), since search engines are able to understand how many links are actually on the page. This factor can also be included in the Delta Score. - You should also include natural language processing in our analysis, as this, apparently, is also taken into account by the Google algorithm. This factor does not significantly affect the overall result, but helps to identify the key concepts with which the machine associates content, as well as fully understand what the link is worth, taking into account the desired result. In other words, contextual analysis of the link graph is necessary. In two things, I agree with Matt Kuts. The only constant parameter is change. However, we must also understand that Google will continue to misinform us about its capabilities or push us to certain conclusions, which we will then adhere to. Therefore, we should understand that Google is responsible for its technology. Simply put, if they can accurately prove that they are not doing anything, then from this moment they should start; after all, some of the most talented engineers on the planet work there. Google continues to complicate search engine marketing and cancel data that allows us to improve user experience, but the fact is that we have a symbiosis. Search engines need SEO specialists and webmasters to make the network faster, easier and more understandable, and we need search engines to promote high-quality content in more prominent places. The problem is that Google has all the cards in its hands, and I’m glad that I did my best to snatch one of them. Your move, Matt.
https://ne-onn.blog.ru/137298867.html
But no less interesting ... I think so ...
Further, the author’s text ...
Evidence
The Instant Preview feature is why we see annotation screenshots in SERP. These previews have an impressive opportunity: they not only display a screenshot of the page, but also visually highlight and underline the text that suits your request. This is simply impossible to achieve with a simple text spider. Screenshots of flash pages - you may already have noticed screenshots of flash sites in the Google Webmaster Tools. Wait ... I thought Google did not see the flash ... AJAX POST request confirmation - Matt Cutts confirmed that GoogleBot can handle AJAX POST requests, and, by chance, this happened a few hours after Rand posted the article “ GoogleBot is Chrome. ” By definition, AJAX is JavaScript-loaded content when an action occurs after the page loads. Therefore, it cannot be tracked with a text spider, because the text spider does not execute JavaScript, but only receives the existing code as provided at the initial download. Google tracks Flash - Matt Clayton also showed me some server logs in which GoogleBot accessed URLs that are accessible only through the built-in Flash modules on Mixcloud.com: 66.249.71.130 "13 / Nov / 2011: 11: 55: 41 + 0000 "" GET / config /? W = 300 & h = 300 & js = 1 & embed_type = widget_standard & feed = http% 3A // www.mixcloud.com / chrisreadsubstance / bbe-mixtape-competition-2010.json & tk = TlVMTA HTTP / 1.1 "200 695" - "" Mozilla / 5.0 (compatible; Googlebot / 2.1; + http: //www.google.com/bot.html) "66.249.71.116" 13 / Nov / 2011: 11: 51: 14 +0000 "" GET / config /?w=300&h=300&js=1&feed=http%3A//www.mixcloud.com/ZiMoN/electro-house-mix-16.json&embed_type=widget_standard&tk=TlVMTA HTTP / 1.1 "200 694" - "" Mozilla / 5.0 ( compatible; Googlebot / 2.1; + http: //www.google.com/bot.html) Let's say this is not news, but another post from 2008 explains that Google “treats Flash files in the same way as they would a person by entering data, and so on. ”And, you mean, how does a person work with a browser? Site - Although Google could get website load time from the toolbar and usage data from Chrome, it’s much more reliable for it to get this information by indexing the network itself. Without executing all the page code, it is almost impossible to accurately calculate the loading time of this page. Until now, all this may have sounded like Google is just a few steps from SkyNet. And optimizers and Google have been assuring us for many years that the search robot (spider) has a textual basis, so this may seem fantastic to you. I assure you, this is not so, and many of the things that I am talking about are accessible to programmers even with a much less strong team of engineers than Google. Meet PhantomJS PhantomJS is a headless Webkit browser that can be controlled through the JavaScript API. With a little script automation, you can easily turn your browser into a spider. It's funny that its logo is a ghost similar to the ghosts in Pacman, and the concept is quite simple: PhantomJS is used to load the page as the user sees it in Firefox, Chrome or Safari, extract materials and track links. PhantomJS has countless applications for parsing information and other types of website analysis, and I advise the SEO community to realize this before we move on. Josh used PhantomJS to prepare some evidence for the information I posted on SearchLove. Earlier, when I released GoFish, I already mentioned that I had difficulty collecting information about the growth in the number of requests from Google Insights using a text spider due to the fact that the list of these questions is provided through AJAX. Richard Baxter suggested that this data can be easily collected using the XPath string, and this convinces me that the search importXML architecture in Google Docs is also based on a headless browser. It is written in red on the diagram: "In the usual way, this data cannot be obtained, because it is AJAX." Anyway, here Josh takes this data off the page using PhantomJS. It is not possible to take screenshots with a text spider, but using the headless webkit browser is as simple as that. In this example, Josh shows how screenshots are taken using PhantomJS. Chromium is a public branch of the Webkit browser, and I strongly doubt that Google created the browser for purely altruistic reasons. The above study suggests that GoogleBot is a multi-threaded headless browser based on the same code. Why don't they tell us anything? Well, actually, they say, but claim that the "robot indexer for creating previews" is a completely separate object. Imagine this robot as "Mrs. Pacman." A member of the main forum of webmasters complained that as a user agent, they display in their logs "Mozilla / 5.0 (X11; U; Linux x86_64; en-US) AppleWebKit / 534.14 (KHTML, like Gecko) Chrome / 9.0.597 Safari / 534.14" and not "Mozilla / 5.0 (en-us) AppleWebKit / 525.13 (KHTML, like Gecko; Google Web Preview) Version / 3.1 Safari / 525.13". John Mu said: “As a tool for testing instant previews, we use a user agent similar to Chrome, so that we can compare what the browser will see (using this user agent) with what we see using Googlebot’s cached access preview. " While the headless browser and Googlebot, as we know, are different, it seems to me that they always browse the pages in parallel and collect information for indexing and ranking. In other words, it’s like a simultaneous two-user version of Pacman with Mrs. Pacman in 3D and regular Pacman, who play on the same level at the same time. In the end, it would not make sense for spiders to browse the entire network twice separately. So why isn’t everything so clear regarding these opportunities, because they are related to ranking? In a nutshell: search quality. Hiding behind the flaws of text spiders, search engines can continue to use them as a scapegoat to explain their imperfect results. They can continue to move in the direction of things like the alleged AuthorRank and rely on SEO to literally optimize their search engines. They can continue to say vague things, like “don't chase the algorithm”, “improve user experience” and “we take into account what is visible without scrolling”, which makes SEO experts make Google's job easier. The main products of Google (and their only products, if you ask Eric Schmidt in court), is search, and if you release information that their capabilities are much higher than declared, then they will have to improve the quality of the search. They don’t tell us about it, because as opportunities grow, so does responsibility. What does this mean for us? When Josh and I presented our research, many people asked me: “How should this change my actions in terms of SEO?” In my opinion, there are three points: 1. Javascript will not help you hide anything. If it seemed to you that with the help of JavaScript postloading you could hide some content - stop doing this. Luring and switching is now a 100% inefficient method. Pacman sees everything. 2. The user experience is extremely important. Google can literally see your site now! As Matt Cutts said, they look at what is above the scroll border, and therefore can take into account when ranking how much advertising is presented on the page. Google can use behavioral data along with site design to determine how useful the site is to people. This is both pleasing and scary, but it also means that every SEO specialist should buy the Circle of Do Not Make Me Think book. 3. SEO tools need to get smarter. Most SEO tools are based on text scrapers, and although many of them are quite complex (SEOmoz currently leads), they still look a lot like Pacman in the 80s. If we want to understand what Google really takes into account when ranking pages, we need to consider more aspects. - When discussing such things as Page Authority and the likelihood of spam, you need to visually check the pages from the point of view of the program, and not be limited to simple indicators, such as the distribution density of keywords and the link graph. In other words, we need a user perception quality indicator (UX Quality Score) that would be influenced by visual analysis and possible modifications to spam. - You should compare how much the page displayed differs from what can be assumed by the code. This can be called the Delta Score. - When assessing the distribution of the proportion of links on a page, one should also take into account dynamic transformation (dinamic transformations), since search engines are able to understand how many links are actually on the page. This factor can also be included in the Delta Score. - You should also include natural language processing in our analysis, as this, apparently, is also taken into account by the Google algorithm. This factor does not significantly affect the overall result, but helps to identify the key concepts with which the machine associates content, as well as fully understand what the link is worth, taking into account the desired result. In other words, contextual analysis of the link graph is necessary. In two things, I agree with Matt Kuts. The only constant parameter is change. However, we must also understand that Google will continue to misinform us about its capabilities or push us to certain conclusions, which we will then adhere to. Therefore, we should understand that Google is responsible for its technology. Simply put, if they can accurately prove that they are not doing anything, then from this moment they should start; after all, some of the most talented engineers on the planet work there. Google continues to complicate search engine marketing and cancel data that allows us to improve user experience, but the fact is that we have a symbiosis. Search engines need SEO specialists and webmasters to make the network faster, easier and more understandable, and we need search engines to promote high-quality content in more prominent places. The problem is that Google has all the cards in its hands, and I’m glad that I did my best to snatch one of them. Your move, Matt.
https://ne-onn.blog.ru/137298867.html
Original message
Извините пост писал спец и поэтому простому юзеру будет несколько сложновато...
Но не менее интересно... Мне так кажется...
Далее текст автора...
Доказательства
Функция Instant Preview – вот почему мы видим скриншоты-аннотации в SERP. Эти превью обладают впечатляющей возможностью: они не только отображают скриншот страницы, но также визуально выделяют и подчеркивают текст, подходящий под ваш запрос. Этого просто невозможно достигнуть простым текстовым пауком. Cкриншоты флеш-страниц – вы, возможно, уже заметили в Инструментах вебмастера Google скриншоты флеш-сайтов. Постойте... я думал, Google не видит флеш... Подтверждение запросов AJAX POST – Мэтт Каттс подтвердил, что GoogleBot умеет обращаться с запросами AJAX POST, и, по случайному совпадению, это произошло через несколько часов после того как Рэнд запостил статью «GoogleBot – это Chrome». Согласно определению, AJAX – это контент, загружаемый JavaScript, когда происходит действие после загрузки страницы. Следовательно, его невозможно отследить с помощью текстового паука, потому что текстовый паук не выполняет JavaScript, а только получает существующий код, каким он предоставлен при первоначальной загрузке. Google отслеживает Flash – Мэтт Клэйтон также показал мне некоторые журналы сервера, в которых GoogleBot получал доступ к URL, которые доступны только через встроенные Flash-модули на Mixcloud.com: 66.249.71.130 "13/Nov/2011:11:55:41 +0000" "GET /config/?w=300&h=300&js=1&embed_type=widget_standard&feed= http%3A//www.mixcloud.com/chrisreadsubstance/bbe-mixtape-competition-2010.json&tk=TlVMTA HTTP/1.1" 200 695 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +https://www.google.com/bot.html)" 66.249.71.116 "13/Nov/2011:11:51:14 +0000" "GET /config/?w=300&h=300&js=1&feed=http%3A//www.mixcloud.com/ZiMoN/electro-house-mix-16.json&embed_type=widget_standard&tk=TlVMTA HTTP/1.1" 200 694 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +https://www.google.com/bot.html) Допустим, это не новость, но другой пост от 2008 года объясняет, что Google «рассматривает Flash-файлы таким же образом, как это делал бы человек, вводя данные, и так далее». А, вы имеете в виду, как человек работает с браузером? Скорость сайта – Хотя Google мог бы получать время загрузки сайтов с панели инструментов и данные об использовании от Chrome, для него гораздо надежнее получать эту информацию, индексируя саму сеть. Не выполняя всего кода страницы, практически невозможно точно вычислить время загрузки этой страницы. До сих пор все это могло звучать так, как будто Google находится всего в нескольких шагах от SkyNet. А оптимизаторы и Google уже много лет уверяют нас, что поисковый робот (паук) имеет текстовую основу, поэтому это может показаться вам фантастикой. Уверяю вас, это не так, и многие из тех вещей, о которых я говорю, доступны программистам даже с намного менее сильной командой инженеров, чем у Google. Знакомьтесь – PhantomJS PhantomJS – это headless Webkit browser, которым можно управлять через JavaScript API. С помощью небольшой автоматизации скрипта браузер легко можно превратить в паука. Забавно, что его логотипом является призрак, похожий на призраки в Pacman, а концепт довольно прост: PhantomJS используется для загрузки страницы так, как пользователь видит ее в Firefox, Chrome или Safari, извлечения материалов и прослеживания ссылок. PhantomJS имеет бесчисленное количество приложений для парсинга информации и других видов анализа сайтов, и я советую SEO-общественности осознать это прежде чем мы двинемся дальше. Джош воспользовался PhantomJS, чтобы подготовить некоторые доказательства сведений, которые я выложил на SearchLove. Ранее, когда я выпустил GoFish, я уже упоминал, что столкнулся с трудностями при сборе информации о росте количества запросов с Google Insights с помощью текстового паука из-за того, что список этих вопросов предоставляется через AJAX. Ричард Бакстер предположил, что эти данные легко можно собрать с помощью строки XPath (XPath string), и это убеждает меня в том, что поисковая архитектура ImportXML в Google Docs основана тоже на headless browser. На схеме написано красным: «Обычным путем эти данные получить невозможно, потому что это AJAX». Во всяком случае, здесь Джош снимает эти данные со страницы при помощи PhantomJS. Делать скриншоты текстовым пауком невозможно, но с помощью headless webkit browser это проще простого. На этом примере Джош показывает, как делаются скриншоты при помощи PhantomJS. Chromium – это общедоступная ветвь браузера Webkit, а я сильно сомневаюсь, что Google создал браузер из чисто альтруистических побуждений. Вышеупомянутое исследование предполагает, что GoogleBot – это многопоточный headless browser на основе того же самого кода. Почему нам ничего не говорят? Ну, вообще-то, говорят, но утверждают, что «робот-индексатор для создания превью» – это совершенно отдельный объект. Представьте этого робота как «миссис Pacman». Участник главного форума вебмастеров пожаловался, что в качестве пользовательского агента у них в журналах отображается "Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/534.14 (KHTML, like Gecko) Chrome/9.0.597 Safari/534.14", а не "Mozilla/5.0 (en-us) AppleWebKit/525.13 (KHTML, like Gecko; Google Web Preview) Version/3.1 Safari/525.13". Джон Му рассказал: «В качестве инструмента для тестирования мгновенных превью мы используем пользовательский агент по образцу Chrome, чтобы можно было сравнить то, что будет видеть браузер (при помощи этого пользовательского агента), с тем, что видим мы с помощью доступа Googlebot к кэшированному превью». В то время как headless browser и Googlebot, как мы знаем, отличаются, мне кажется, что они всегда параллельно просматривают страницы и собирают информацию для индексации и ранжирования. Другими словами, это как одновременная двухпользовательская версия Pacman с миссис Pacman в 3D и обычным Pacman, которые играют на одном уровне в одно время. В конце концов, паукам не было бы смысла просматривать всю сеть дважды по отдельности. Так почему же относительно этих возможностей не все так ясно, ведь они имеют отношение к ранжированию? В двух словах: качество поиска. Прикрываясь недостатками текстовых пауков, поисковики могут продолжать использовать их в качестве козла отпущения, объясняющего их неидеальные результаты. Они могут продолжать двигаться в направлении таких вещей как предполагаемый AuthorRank и полагаться на SEO, чтобы в буквальном смысле оптимизировать свои поисковые машины. Они могут продолжать говорить неопределенные вещи, вроде «не гонитесь на алгоритмом», «улучшайте пользовательское восприятие» и «мы учитываем то, что видно без прокрутки», что заставляет специалистов SEO облегчать работу Google. Основной продукцией Google (и единственной их продукцией, если спросить у Эрика Шмидта в суде), является поиск, и если обнародовать информацию о том, что их возможности намного превосходят заявленные, то им придется повысить качество поиска. Они не говорят нам об этом, потому что с ростом возможностей растет и ответственность. Что это означает для нас? Когда мы с Джошем представили свое исследование, многие люди спрашивали меня: «Как это должно поменять мои действия в плане SEO?». По моему мнению, есть три момента: 1. Javascript не поможет вам ничего скрыть. Если вам казалось, что с помощью постзагрузки JavaScript вы можете спрятать какой-либо контент – прекратите это делать. Заманивание и переключение теперь на 100% неэффективный метод. Pacman видит все. 2. Пользовательское впечатление чрезвычайно важно. Google сейчас может в буквальном смысле видеть ваш сайт! Как сказал Мэтт Катс, они смотрят на то, что выше границы прокрутки, а следовательно, могут учитывать при ранжировании то, сколько рекламы представлено на странице. Google может применять данные о поведенческих факторах вместе с дизайном сайта чтобы определить, насколько сайт полезен для людей. Это одновременно радует и пугает, но также это означает, что каждый специалист SEO должен приобрести книгу Круга «Не заставляй меня думать». 3. Инструменты SEO должны стать умнее. Большинство средств SEO основано на текстовых сборщиках (text scrapers), и хотя многие из них довольно сложны (в данный момент лидирует SEOmoz), они все еще сильно напоминают Pacman 80-х годов. Если мы хотим понять, что на самом деле принимает во внимание Google при ранжировании страниц, надо учитывать больше аспектов. - При обсуждении таких вещей как Page Authority и вероятность спама необходимо визуально проверять страницы с точки зрения программы, а не ограничиваться простыми показателями, такими как плотность распределения ключевиков и граф ссылок. Другими словами, нам нужен показатель качества пользовательского восприятия (UX Quality Score), на который влиял бы визуальный анализ и возможные видоизменения спама. - Следует сравнивать, насколько отображаемая страница отличается от того, что можно предполагать по коду. Это можно назвать коэффициентом дельта (Delta Score). - При оценке распределения доли ссылок на странице нужно также учитывать динамическое преобразование (dinamic transformations), поскольку поисковые машины способны понять, сколько в действительности ссылок на странице. Этот фактор тоже можно включить в коэффициент дельта (Delta Score). - Также следует включить в наш анализ обработку естественного языка, так как это, по-видимому, тоже учитывается алгоритмом Google. Этот фактор не оказывает значительного влияния на общий результат, но помогает определить ключевые понятия, с которыми машина ассоциирует контент, а также полностью понять, чего стоит ссылка с учетом желаемого результата. Другими словами, необходим контекстуальный анализ графа ссылок. В двух вещах я согласен с Мэттом Катсом. Единственный постоянный параметр – это перемены. Однако мы должны также понимать, что Google будет продолжать дезинформировать нас относительно своих возможностей или подталкивать к определенным выводам, которых мы потом будем придерживаться. Поэтому нам следует понимать, что Google в ответе за свои технологии. Проще говоря, если они могут точно доказать, что они ничего такого не делают, то с этого момента им следует начать; в конце концов, там работают одни из самых талантливых инженеров на планете. Google продолжает усложнять поисковый маркетинг и отменять данные, позволяющие нам улучшать восприятие пользователем, но факт в том, что у нас симбиоз. Поисковики нуждаются в SEO-специалистах и вебмастерах, чтобы сделать сеть быстрее, проще и понятнее, а мы нуждаемся в поисковиках, чтобы качественный контент поощрялся, занимая более заметные места. Проблема в том, что у Google в руках все карты, и я рад, что приложил свои усилия к тому, чтобы вырвать одну из них. Твой ход, Мэтт.
https://ne-onn.blog.ru/137298867.html
Но не менее интересно... Мне так кажется...
Далее текст автора...
Доказательства
Функция Instant Preview – вот почему мы видим скриншоты-аннотации в SERP. Эти превью обладают впечатляющей возможностью: они не только отображают скриншот страницы, но также визуально выделяют и подчеркивают текст, подходящий под ваш запрос. Этого просто невозможно достигнуть простым текстовым пауком. Cкриншоты флеш-страниц – вы, возможно, уже заметили в Инструментах вебмастера Google скриншоты флеш-сайтов. Постойте... я думал, Google не видит флеш... Подтверждение запросов AJAX POST – Мэтт Каттс подтвердил, что GoogleBot умеет обращаться с запросами AJAX POST, и, по случайному совпадению, это произошло через несколько часов после того как Рэнд запостил статью «GoogleBot – это Chrome». Согласно определению, AJAX – это контент, загружаемый JavaScript, когда происходит действие после загрузки страницы. Следовательно, его невозможно отследить с помощью текстового паука, потому что текстовый паук не выполняет JavaScript, а только получает существующий код, каким он предоставлен при первоначальной загрузке. Google отслеживает Flash – Мэтт Клэйтон также показал мне некоторые журналы сервера, в которых GoogleBot получал доступ к URL, которые доступны только через встроенные Flash-модули на Mixcloud.com: 66.249.71.130 "13/Nov/2011:11:55:41 +0000" "GET /config/?w=300&h=300&js=1&embed_type=widget_standard&feed= http%3A//www.mixcloud.com/chrisreadsubstance/bbe-mixtape-competition-2010.json&tk=TlVMTA HTTP/1.1" 200 695 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +https://www.google.com/bot.html)" 66.249.71.116 "13/Nov/2011:11:51:14 +0000" "GET /config/?w=300&h=300&js=1&feed=http%3A//www.mixcloud.com/ZiMoN/electro-house-mix-16.json&embed_type=widget_standard&tk=TlVMTA HTTP/1.1" 200 694 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +https://www.google.com/bot.html) Допустим, это не новость, но другой пост от 2008 года объясняет, что Google «рассматривает Flash-файлы таким же образом, как это делал бы человек, вводя данные, и так далее». А, вы имеете в виду, как человек работает с браузером? Скорость сайта – Хотя Google мог бы получать время загрузки сайтов с панели инструментов и данные об использовании от Chrome, для него гораздо надежнее получать эту информацию, индексируя саму сеть. Не выполняя всего кода страницы, практически невозможно точно вычислить время загрузки этой страницы. До сих пор все это могло звучать так, как будто Google находится всего в нескольких шагах от SkyNet. А оптимизаторы и Google уже много лет уверяют нас, что поисковый робот (паук) имеет текстовую основу, поэтому это может показаться вам фантастикой. Уверяю вас, это не так, и многие из тех вещей, о которых я говорю, доступны программистам даже с намного менее сильной командой инженеров, чем у Google. Знакомьтесь – PhantomJS PhantomJS – это headless Webkit browser, которым можно управлять через JavaScript API. С помощью небольшой автоматизации скрипта браузер легко можно превратить в паука. Забавно, что его логотипом является призрак, похожий на призраки в Pacman, а концепт довольно прост: PhantomJS используется для загрузки страницы так, как пользователь видит ее в Firefox, Chrome или Safari, извлечения материалов и прослеживания ссылок. PhantomJS имеет бесчисленное количество приложений для парсинга информации и других видов анализа сайтов, и я советую SEO-общественности осознать это прежде чем мы двинемся дальше. Джош воспользовался PhantomJS, чтобы подготовить некоторые доказательства сведений, которые я выложил на SearchLove. Ранее, когда я выпустил GoFish, я уже упоминал, что столкнулся с трудностями при сборе информации о росте количества запросов с Google Insights с помощью текстового паука из-за того, что список этих вопросов предоставляется через AJAX. Ричард Бакстер предположил, что эти данные легко можно собрать с помощью строки XPath (XPath string), и это убеждает меня в том, что поисковая архитектура ImportXML в Google Docs основана тоже на headless browser. На схеме написано красным: «Обычным путем эти данные получить невозможно, потому что это AJAX». Во всяком случае, здесь Джош снимает эти данные со страницы при помощи PhantomJS. Делать скриншоты текстовым пауком невозможно, но с помощью headless webkit browser это проще простого. На этом примере Джош показывает, как делаются скриншоты при помощи PhantomJS. Chromium – это общедоступная ветвь браузера Webkit, а я сильно сомневаюсь, что Google создал браузер из чисто альтруистических побуждений. Вышеупомянутое исследование предполагает, что GoogleBot – это многопоточный headless browser на основе того же самого кода. Почему нам ничего не говорят? Ну, вообще-то, говорят, но утверждают, что «робот-индексатор для создания превью» – это совершенно отдельный объект. Представьте этого робота как «миссис Pacman». Участник главного форума вебмастеров пожаловался, что в качестве пользовательского агента у них в журналах отображается "Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/534.14 (KHTML, like Gecko) Chrome/9.0.597 Safari/534.14", а не "Mozilla/5.0 (en-us) AppleWebKit/525.13 (KHTML, like Gecko; Google Web Preview) Version/3.1 Safari/525.13". Джон Му рассказал: «В качестве инструмента для тестирования мгновенных превью мы используем пользовательский агент по образцу Chrome, чтобы можно было сравнить то, что будет видеть браузер (при помощи этого пользовательского агента), с тем, что видим мы с помощью доступа Googlebot к кэшированному превью». В то время как headless browser и Googlebot, как мы знаем, отличаются, мне кажется, что они всегда параллельно просматривают страницы и собирают информацию для индексации и ранжирования. Другими словами, это как одновременная двухпользовательская версия Pacman с миссис Pacman в 3D и обычным Pacman, которые играют на одном уровне в одно время. В конце концов, паукам не было бы смысла просматривать всю сеть дважды по отдельности. Так почему же относительно этих возможностей не все так ясно, ведь они имеют отношение к ранжированию? В двух словах: качество поиска. Прикрываясь недостатками текстовых пауков, поисковики могут продолжать использовать их в качестве козла отпущения, объясняющего их неидеальные результаты. Они могут продолжать двигаться в направлении таких вещей как предполагаемый AuthorRank и полагаться на SEO, чтобы в буквальном смысле оптимизировать свои поисковые машины. Они могут продолжать говорить неопределенные вещи, вроде «не гонитесь на алгоритмом», «улучшайте пользовательское восприятие» и «мы учитываем то, что видно без прокрутки», что заставляет специалистов SEO облегчать работу Google. Основной продукцией Google (и единственной их продукцией, если спросить у Эрика Шмидта в суде), является поиск, и если обнародовать информацию о том, что их возможности намного превосходят заявленные, то им придется повысить качество поиска. Они не говорят нам об этом, потому что с ростом возможностей растет и ответственность. Что это означает для нас? Когда мы с Джошем представили свое исследование, многие люди спрашивали меня: «Как это должно поменять мои действия в плане SEO?». По моему мнению, есть три момента: 1. Javascript не поможет вам ничего скрыть. Если вам казалось, что с помощью постзагрузки JavaScript вы можете спрятать какой-либо контент – прекратите это делать. Заманивание и переключение теперь на 100% неэффективный метод. Pacman видит все. 2. Пользовательское впечатление чрезвычайно важно. Google сейчас может в буквальном смысле видеть ваш сайт! Как сказал Мэтт Катс, они смотрят на то, что выше границы прокрутки, а следовательно, могут учитывать при ранжировании то, сколько рекламы представлено на странице. Google может применять данные о поведенческих факторах вместе с дизайном сайта чтобы определить, насколько сайт полезен для людей. Это одновременно радует и пугает, но также это означает, что каждый специалист SEO должен приобрести книгу Круга «Не заставляй меня думать». 3. Инструменты SEO должны стать умнее. Большинство средств SEO основано на текстовых сборщиках (text scrapers), и хотя многие из них довольно сложны (в данный момент лидирует SEOmoz), они все еще сильно напоминают Pacman 80-х годов. Если мы хотим понять, что на самом деле принимает во внимание Google при ранжировании страниц, надо учитывать больше аспектов. - При обсуждении таких вещей как Page Authority и вероятность спама необходимо визуально проверять страницы с точки зрения программы, а не ограничиваться простыми показателями, такими как плотность распределения ключевиков и граф ссылок. Другими словами, нам нужен показатель качества пользовательского восприятия (UX Quality Score), на который влиял бы визуальный анализ и возможные видоизменения спама. - Следует сравнивать, насколько отображаемая страница отличается от того, что можно предполагать по коду. Это можно назвать коэффициентом дельта (Delta Score). - При оценке распределения доли ссылок на странице нужно также учитывать динамическое преобразование (dinamic transformations), поскольку поисковые машины способны понять, сколько в действительности ссылок на странице. Этот фактор тоже можно включить в коэффициент дельта (Delta Score). - Также следует включить в наш анализ обработку естественного языка, так как это, по-видимому, тоже учитывается алгоритмом Google. Этот фактор не оказывает значительного влияния на общий результат, но помогает определить ключевые понятия, с которыми машина ассоциирует контент, а также полностью понять, чего стоит ссылка с учетом желаемого результата. Другими словами, необходим контекстуальный анализ графа ссылок. В двух вещах я согласен с Мэттом Катсом. Единственный постоянный параметр – это перемены. Однако мы должны также понимать, что Google будет продолжать дезинформировать нас относительно своих возможностей или подталкивать к определенным выводам, которых мы потом будем придерживаться. Поэтому нам следует понимать, что Google в ответе за свои технологии. Проще говоря, если они могут точно доказать, что они ничего такого не делают, то с этого момента им следует начать; в конце концов, там работают одни из самых талантливых инженеров на планете. Google продолжает усложнять поисковый маркетинг и отменять данные, позволяющие нам улучшать восприятие пользователем, но факт в том, что у нас симбиоз. Поисковики нуждаются в SEO-специалистах и вебмастерах, чтобы сделать сеть быстрее, проще и понятнее, а мы нуждаемся в поисковиках, чтобы качественный контент поощрялся, занимая более заметные места. Проблема в том, что у Google в руках все карты, и я рад, что приложил свои усилия к тому, чтобы вырвать одну из них. Твой ход, Мэтт.
https://ne-onn.blog.ru/137298867.html
