С сайта: как бесплатно спарсить и извлечь данные с сайта — SEO на vc.ru

alexxlab 06.03.2019 Разное Leave a comment 133 Просмотры

Содержание

как бесплатно спарсить и извлечь данные с сайта — SEO на vc.ru

Часто у вебмастера, маркетолога или SEO-специалиста возникает необходимость извлечь данные со страниц сайтов и отобразить их в удобном виде для дальнейшей обработки. Это может быть парсинг цен в интернет-магазине, получение числа лайков или извлечение содержимого отзывов с интересующих ресурсов.

{«id»:182968,»url»:»https:\/\/vc.ru\/seo\/182968-veb-skreyping-kak-besplatno-sparsit-i-izvlech-dannye-s-sayta»,»title»:»\u0412\u0435\u0431-\u0441\u043a\u0440\u0435\u0439\u043f\u0438\u043d\u0433: \u043a\u0430\u043a \u0431\u0435\u0441\u043f\u043b\u0430\u0442\u043d\u043e \u0441\u043f\u0430\u0440\u0441\u0438\u0442\u044c \u0438 \u0438\u0437\u0432\u043b\u0435\u0447\u044c \u0434\u0430\u043d\u043d\u044b\u0435 \u0441 \u0441\u0430\u0439\u0442\u0430″,»services»:{«facebook»:{«url»:»https:\/\/www.

facebook.com\/sharer\/sharer.php?u=https:\/\/vc.ru\/seo\/182968-veb-skreyping-kak-besplatno-sparsit-i-izvlech-dannye-s-sayta»,»short_name»:»FB»,»title»:»Facebook»,»width»:600,»height»:450},»vkontakte»:{«url»:»https:\/\/vk.com\/share.php?url=https:\/\/vc.ru\/seo\/182968-veb-skreyping-kak-besplatno-sparsit-i-izvlech-dannye-s-sayta&title=\u0412\u0435\u0431-\u0441\u043a\u0440\u0435\u0439\u043f\u0438\u043d\u0433: \u043a\u0430\u043a \u0431\u0435\u0441\u043f\u043b\u0430\u0442\u043d\u043e \u0441\u043f\u0430\u0440\u0441\u0438\u0442\u044c \u0438 \u0438\u0437\u0432\u043b\u0435\u0447\u044c \u0434\u0430\u043d\u043d\u044b\u0435 \u0441 \u0441\u0430\u0439\u0442\u0430″,»short_name»:»VK»,»title»:»\u0412\u041a\u043e\u043d\u0442\u0430\u043a\u0442\u0435″,»width»:600,»height»:450},»twitter»:{«url»:»https:\/\/twitter.com\/intent\/tweet?url=https:\/\/vc.ru\/seo\/182968-veb-skreyping-kak-besplatno-sparsit-i-izvlech-dannye-s-sayta&text=\u0412\u0435\u0431-\u0441\u043a\u0440\u0435\u0439\u043f\u0438\u043d\u0433: \u043a\u0430\u043a \u0431\u0435\u0441\u043f\u043b\u0430\u0442\u043d\u043e \u0441\u043f\u0430\u0440\u0441\u0438\u0442\u044c \u0438 \u0438\u0437\u0432\u043b\u0435\u0447\u044c \u0434\u0430\u043d\u043d\u044b\u0435 \u0441 \u0441\u0430\u0439\u0442\u0430″,»short_name»:»TW»,»title»:»Twitter»,»width»:600,»height»:450},»telegram»:{«url»:»tg:\/\/msg_url?url=https:\/\/vc.

ru\/seo\/182968-veb-skreyping-kak-besplatno-sparsit-i-izvlech-dannye-s-sayta&text=\u0412\u0435\u0431-\u0441\u043a\u0440\u0435\u0439\u043f\u0438\u043d\u0433: \u043a\u0430\u043a \u0431\u0435\u0441\u043f\u043b\u0430\u0442\u043d\u043e \u0441\u043f\u0430\u0440\u0441\u0438\u0442\u044c \u0438 \u0438\u0437\u0432\u043b\u0435\u0447\u044c \u0434\u0430\u043d\u043d\u044b\u0435 \u0441 \u0441\u0430\u0439\u0442\u0430″,»short_name»:»TG»,»title»:»Telegram»,»width»:600,»height»:450},»odnoklassniki»:{«url»:»http:\/\/connect.ok.ru\/dk?st.cmd=WidgetSharePreview&service=odnoklassniki&st.shareUrl=https:\/\/vc.ru\/seo\/182968-veb-skreyping-kak-besplatno-sparsit-i-izvlech-dannye-s-sayta»,»short_name»:»OK»,»title»:»\u041e\u0434\u043d\u043e\u043a\u043b\u0430\u0441\u0441\u043d\u0438\u043a\u0438″,»width»:600,»height»:450},»email»:{«url»:»mailto:?subject=\u0412\u0435\u0431-\u0441\u043a\u0440\u0435\u0439\u043f\u0438\u043d\u0433: \u043a\u0430\u043a \u0431\u0435\u0441\u043f\u043b\u0430\u0442\u043d\u043e \u0441\u043f\u0430\u0440\u0441\u0438\u0442\u044c \u0438 \u0438\u0437\u0432\u043b\u0435\u0447\u044c \u0434\u0430\u043d\u043d\u044b\u0435 \u0441 \u0441\u0430\u0439\u0442\u0430&body=https:\/\/vc.

ru\/seo\/182968-veb-skreyping-kak-besplatno-sparsit-i-izvlech-dannye-s-sayta»,»short_name»:»Email»,»title»:»\u041e\u0442\u043f\u0440\u0430\u0432\u0438\u0442\u044c \u043d\u0430 \u043f\u043e\u0447\u0442\u0443″,»width»:600,»height»:450}},»isFavorited»:false}

7661 просмотров

По умолчанию большинство программ технического аудита сайтов собирают только содержимое заголовков h2 и h3, однако, если например, вы хотите собрать заголовки H5, то их уже нужно будет извлекать отдельно. И чтобы избежать рутинной ручной работы по парсингу и извлечению данных из HTML-кода страниц – обычно используют веб-скраперы.

Веб-скрейпинг – это автоматизированный процесс извлечения данных с интересующих страниц сайта по определенным правилам.

Возможные сферы применения веб-скрейпинга:

Отслеживание цен на товары в интернет-магазинах.
Извлечение описаний товаров и услуг, получение числа товаров и картинок в листинге.
Извлечение контактной информации (адреса электронной почты, телефоны и т.д.).
Сбор данных для маркетинговых исследований (лайки, шеры, оценки в рейтингах).
Извлечение специфичных данных из кода HTML-страниц (поиск систем аналитики, проверка наличия микроразметки).
Мониторинг объявлений.

Основными способами веб-скрейпинга являются методы разбора данных используя XPath, CSS-селекторы, XQuery, RegExp и HTML templates.

XPath представляет собой специальный язык запросов к элементам документа формата XML / XHTML. Для доступа к элементам XPath использует навигацию по DOM путем описания пути до нужного элемента на странице. С его помощью можно получить значение элемента по его порядковому номеру в документе, извлечь его текстовое содержимое или внутренний код, проверить наличие определенного элемента на странице. Описание XPath >>

CSS-селекторы используются для поиска элемента его части (атрибут). CSS синтаксически похож на XPath, при этом в некоторых случаях CSS-локаторы работают быстрее и описываются более наглядно и кратко. Минусом CSS является то, что он работает лишь в одном направлении – вглубь документа. XPath же работает в обе стороны (например, можно искать родительский элемент по дочернему). Таблица сравнения CSS и XPath >>

XQuery имеет в качестве основы язык XPath. XQuery имитирует XML, что позволяет создавать вложенные выражения в таким способом, который невозможен в XSLT. Описание XQuery >>
RegExp – формальный язык поиска для извлечения значений из множества текстовых строк, соответствующих требуемым условиям (регулярному выражению). Описание RegExp >>
HTML templates – язык извлечения данных из HTML документов, который представляет собой комбинацию HTML-разметки для описания шаблона поиска нужного фрагмента плюс функции и операции для извлечения и преобразования данных. Описание HTML templates >>

Обычно при помощи парсинга решаются задачи, с которыми сложно справиться вручную. Это может быть веб скрейпинг описаний товаров при создании нового интернет-магазина, скрейпинг в маркетинговых исследованиях для мониторинга цен, либо для мониторинга объявлений (например, по продаже квартир). Для задач SEO-оптимизации обычно используются узко специализированные инструменты, в которых уже встроены парсеры со всеми необходимыми настройками извлечения основных SEO параметров.

BatchURLScraper

Существует множество инструментов, позволяющих осуществлять скрейпинг (извлекать данные из веб-сайтов), однако большинство из них платные и громоздкие, что несколько ограничивает их доступность для массового использования.

Поэтому нами был создан простой и бесплатный инструмент – BatchURLScraper, предназначенный для сбора данных из списка URL с возможностью экспорта полученных результатов в Excel.

Интерфейс программы достаточно прост и состоит всего из 3-х вкладок:

Вкладка «Список URL» предназначена для добавления страниц парсинга и отображения результатов извлечения данных с возможностью их последующего экспорта.
На вкладке «Правила» производится настройка правил скрейпинга при помощи XPath, CSS-локаторов, XQuery, RegExp или HTML templates.
Вкладка «Настройки» содержит общие настройки программы (число потоков, User-Agent и т.п.).

Также нами был добавлен модуль для отладки правил.

При помощи встроенного отладчика правил можно быстро и просто получить HTML-содержимое любой страницы сайта и тестировать работу запросов, после чего использовать отлаженные правила для парсинга данных в BatchURLScraper.

Разберем более подробно примеры настроек парсинга для различных вариантов извлечения данных.

Извлечение данных со страниц сайтов в примерах

Так как BatchURLScraper позволяет извлекать данные из произвольного списка страниц, в котором могут встречаться URL от разных доменов и, соответственно, разных типов сайта, то для примеров тестирования извлечения данных мы будем использовать все пять вариантов скрейпинга: XPath, CSS, RegExp, XQuery и HTML templates. Список тестовых URL и настроек правил находятся в дистрибутиве программы, таким образом можно протестировать все это лично, используя пресеты (предустановленные настройки парсинга).

Механика извлечения данных

1. Пример скрейпинга через XPath.

Например, в интернет-магазине мобильных телефонов нам нужно извлечь цены со страниц карточек товаров, а также признак наличия товара на складе (есть в наличии или нет).

Для извлечения цен нам нужно:

Перейти на карточку товара.
Выделить цену.
Кликнуть по ней правой кнопкой мыши и нажать «Показать код элемента» (или «Inspect», если вы используете англоязычный интерфейс).
В открывшемся окне найти элемент, отвечающий за цену (он будет подсвечен).
Кликнуть по нему правой кнопкой мыши и выбрать «Копировать» > «Копировать XPath».

Для извлечения признака наличия товара на сайте операция будет аналогичной.

Так как типовые страницы обычно имеют одинаковый шаблон, достаточно проделать операцию по получению XPath для одной такой типовой страницы товара, чтобы спарсить цены всего магазина.

Далее, в списке правил программы мы добавляем поочередно правила и вставляем в них ранее скопированные коды элементов XPath из браузера.

2. Определяем присутствие счетчика Google Analytics при помощи RegExp или XPath.

XPath: Открываем исходный код любой страницы по Ctrl-U, затем ищем в нем текст «gtm.start», ищем в коде идентификатор UA-…, и далее также используя отображение кода элемента копируем его XPath и вставляем в новое правило в BatchURLScraper.
RegExp: Поиск счетчика через регулярные выражения еще проще: код правила извлечения данных вставляем [‘](UA-.*?)[‘].

3. Извлечь контактный Email используя CSS.

Тут совсем все просто. =»mailto:»].

4. Извлечь значения в списках или в таблице при помощи XQuery.

В отличии от других селекторов, XQuery позволяет использовать циклы и прочие возможности языков программирования.

Например, при помощи оператора FOR можно получить значения всех списков LI. Пример:

Либо узнать, есть ли почта на страницах сайта:

if (count(//a[starts-with(@href, ‘mailto:’)])) then «Есть почта» else «Нет почты»

5. Использование HTML templates.

В данном языке извлечения данных в качестве функций можно использовать XPath/XQuery, CSSpath, JSONiq и обычные выражения.

Тестовая таблица:

Например, данный шаблон ищет таблицу с атрибутом и извлекает текст из второго столбца таблицы:

<table><template:loop><tr><td></td><td>{text()}</td></tr></template:loop></table>

Извлечение данных из второй строки:

<table><tr></tr><tr><template:loop><td>{text()}</td></template:loop></tr></table>

А этот темплейт вычисляет сумму чисел в колонке таблицы:

<table>{_tmp := 0}<template:loop><tr><td>{_tmp := $_tmp + . }</td></tr></template:loop>{result := $_tmp}</table>

Таким образом, мы получили возможность извлекать практически любые данные с интересующих страниц сайтов, используя произвольный список URL, включающий страницы с разных доменов.

Скачать BatchURLScraper и протестировать работу правил извлечения данных можно по этой ссылке

Как бесплатно спарсить и извлечь данные с сайта (веб-скрейпинг)

Возможные сферы применения веб-скрейпинга:

Отслеживание цен на товары в интернет-магазинах.
Извлечение описаний товаров и услуг, получение числа товаров и картинок в листинге.
Извлечение контактной информации (адреса электронной почты, телефоны и т.д.).
Сбор данных для маркетинговых исследований (лайки, шеры, оценки в рейтингах).
Извлечение специфичных данных из кода HTML-страниц (поиск систем аналитики, проверка наличия микроразметки).
Мониторинг объявлений.

XPath представляет собой специальный язык запросов к элементам документа формата XML / XHTML. Для доступа к элементам XPath использует навигацию по DOM путем описания пути до нужного элемента на странице. С его помощью можно получить значение элемента по его порядковому номеру в документе, извлечь его текстовое содержимое или внутренний код, проверить наличие определенного элемента на странице. Описание XPath >>
CSS-селекторы используются для поиска элемента его части (атрибут). CSS синтаксически похож на XPath, при этом в некоторых случаях CSS-локаторы работают быстрее и описываются более наглядно и кратко. Минусом CSS является то, что он работает лишь в одном направлении – вглубь документа. XPath же работает в обе стороны (например, можно искать родительский элемент по дочернему). Таблица сравнения CSS и XPath >>
XQuery имеет в качестве основы язык XPath. XQuery имитирует XML, что позволяет создавать вложенные выражения в таким способом, который невозможен в XSLT. Описание XQuery >>
RegExp – формальный язык поиска для извлечения значений из множества текстовых строк, соответствующих требуемым условиям (регулярному выражению). Описание RegExp >>
HTML templates – язык извлечения данных из HTML документов, который представляет собой комбинацию HTML-разметки для описания шаблона поиска нужного фрагмента плюс функции и операции для извлечения и преобразования данных. Описание HTML templates >>

BatchURLScraper

Интерфейс программы достаточно прост и состоит всего из 3-х вкладок:

Вкладка «Список URL» предназначена для добавления страниц парсинга и отображения результатов извлечения данных с возможностью их последующего экспорта.
На вкладке «Правила» производится настройка правил скрейпинга при помощи XPath, CSS-локаторов, XQuery, RegExp или HTML templates.
Вкладка «Настройки» содержит общие настройки программы (число потоков, User-Agent и т.п.).

Также нами был добавлен модуль для отладки правил.

Разберем более подробно примеры настроек парсинга для различных вариантов извлечения данных.

Извлечение данных со страниц сайтов в примерах

Механика извлечения данных

1. Пример скрейпинга через XPath.

Для извлечения цен нам нужно:

Перейти на карточку товара.
Выделить цену.
Кликнуть по ней правой кнопкой мыши и нажать «Показать код элемента» (или «Inspect», если вы используете англоязычный интерфейс).
В открывшемся окне найти элемент, отвечающий за цену (он будет подсвечен).
Кликнуть по нему правой кнопкой мыши и выбрать «Копировать» > «Копировать XPath».

Для извлечения признака наличия товара на сайте операция будет аналогичной.

2. Определяем присутствие счетчика Google Analytics при помощи RegExp или XPath.

XPath:

Открываем исходный код любой страницы по Ctrl-U, затем ищем в нем текст «gtm.

=»mailto:»].

4. Извлечь значения в списках или в таблице при помощи XQuery.

Например, при помощи оператора FOR можно получить значения всех списков LI. Пример:

Либо узнать, есть ли почта на страницах сайта:

if (count(//a[starts-with(@href, ‘mailto:’)])) then «Есть почта» else «Нет почты»

5. Использование HTML templates.

В данном языке извлечения данных в качестве функций можно использовать XPath/XQuery, CSSpath, JSONiq и обычные выражения.

Тестовая таблица:

1	aaa	other
2	foo	columns
3	bar	are
4	xyz	here

Например, данный шаблон ищет таблицу с атрибутом и извлекает текст из второго столбца таблицы:

<table><template:loop><tr><td></td><td>{text()}</td></tr></template:loop></table>

Извлечение данных из второй строки:

<table><tr></tr><tr><template:loop><td>{text()}</td></template:loop></tr></table>

А этот темплейт вычисляет сумму чисел в колонке таблицы:

<table>{_tmp := 0}<template:loop><tr><td>{_tmp := $_tmp + . }</td></tr></template:loop>{result := $_tmp}</table>

Ниже представлена таблица, с наиболее часто встречающимися правилами для извлечения данных.

Примеры кода для извлечения данных

В данной таблице мы собрали список наиболее часто встречающихся вариантов получения данных, которые можно извлечь используя различные типы экстракторов.

Экстрактор	Выражение	Описание
1. CSSPath	#comments>h5	Содержимое ID «comments» и в нем подзаголовка h5
2. CSSPath	*[src^=http://]	Поиск небезопасных ссылок на HTTP протокол
3. =mailto:]	Поиск ссылок, содержащих в URL mailto:
5. CSSPath	a[itemprop=maps]:not([href=your_google_maps_url])	Поиск страниц, не содержащих определенный URL на карты Google
6. CSSPath	a[itemprop=maps][href=your_google_maps_url]	Поиск страниц, содержащих определенный URL на карты Google
7. CSSPath	body>noscript:has(iframe[src$=GTM-your_tracking_id]):first-child	Извлечение Google Tag Manager ID
8. CSSPath	head:has(link[rel=alternate][hreflang=es-es][href*=/es/])	Поиск страниц, содержащих href или hreflang =/es/
9. CSSPath	img[alt*=SiteAnalyzer]	Содержимое тега alt, если он содержит текст SiteAnalyzer
10. =http://]	Поиск не безопасных ссылок на HTTP протокол в ссылках на CSS файлы стилей
12. CSSPath	meta[name=description][content*=siteanalyzer]	Содержимое мета-тега description, если он содержит текст SiteAnalyzer
13. Regex	[‘](GTM-.*?)[‘]	Извлечение Google Tag Manager ID 1
14. Regex	[‘](GTM-\w+)[‘]	Извлечение Google Tag Manager ID 2
15. Regex	[‘](UA-.*?)[‘]	Извлечение Google Analytics ID
16. Regex	[a-zA-Z0-9][a-zA-Z0-9\.+-]+\@[\w-\.]+\.\w+	Ищем Email 1
17. Regex	[a-zA-Z0-9-_.]+@[a-zA-Z0-9-]+.[a-zA-Z0-9-.]+	Ищем Email 2
18. Regex	\w+	Ищем одиночные слова
19. XPath	//*[@hreflang]	Содержимое всех элементов hreflang
20. XPath	//*[@hreflang]/@hreflang	Конкретные значения элементов hreflang
21. XPath	//*[@id=»our_price»]	Парсинг цен 1
22. XPath	//*[@class=»price»]	Парсинг цен 2
23. XPath	//*[@itemprop]/@itemprop	Правила Itemprop
24. XPath	//*[@itemtype]/@itemtype	Типы схем структрурированных данных
25. XPath	//*[contains(@class, ‘watch-view-count’)]»	Число просмотров на Youtube
26. XPath	//*[contains(@class,’like-button-renderer-dislike-button’)])[1]	Число дизлайков ролика на Youtube
27. XPath	//*[contains(@class,’like-button-renderer-like-button’)])[1]	Число лайков ролика на Youtube
28. XPath	//a[contains(.,’SEO Spider’)]/@href	Ссылки, включающие анкор SEO Spider
29. XPath	//a[contains(@class, ‘my_class’)]	Получение страниц, содержащих гиперссылку с определенным классом
30. XPath	//a[contains(@href, ‘linkedin.com/in’) or contains(@href, ‘twitter.com/’) or contains(@href, ‘facebook.com/’)]/@href;	Ссылки на соцсети
31. XPath	//a[contains(@href, ‘site-analyzer.pro’)]/@href	Ссылки на внутренние страницы
32. XPath	//a[contains(@href,’screamingfrog.co.uk’)]	Извлечение ссылок с вхождением (полный код либо текст анкора)
33. XPath	//a[contains(@href,’screamingfrog.co.uk’)]/@href	Извлечение именно URL со вхождением
34. XPath	//a[contains(translate(., ‘ABCDEFGHIJKLMNOPQRSTUVWXYZ’, ‘abcdefghijklmnopqrstuvwxyz’),’seo spider’)]/@href	Регистрозависимый поиск
35. XPath	//a[not(contains(@href, ‘site-analyzer.pro’))]/@href	Ссылки на внешние страницы
36. XPath	//a[starts-with(@href, ‘mailto’)]	Все email на странице
37. XPath	//a[starts-with(@href, ‘tel:’)]	Все телефоны на странице
38. XPath	//div[@class=»example»]	Содержимое по классу
39. XPath	//div[@class=»main-blog—posts_single—inside»]//a	Получение якорного текста
40. XPath	//div[@class=»main-blog—posts_single—inside»]//a	Исходный код ссылки
41. XPath	//div[@class=»main-blog—posts_single—inside»]//a/@href	Содержимое URL
42. XPath	//div[contains(@class ,’main-blog—posts_single-inner—text—inner’)]//h4\|//a[@class=»comments-link»]	Несколько правил в одном выражении
43. XPath	//div[contains(@class, ‘rating-box’)]	Парсинг рейтинга 4.5
44. XPath	//div[contains(@class, ‘rating-box’)]	Парсинг рейтинга
45. XPath	//div[contains(@class, ‘right-text’)]/span[1]	Парсинг цены товара
46. XPath	//div[contains(@class, ‘video-line’)]/iframe	Количество видео на странице по классу
47. XPath	//h2/text()	Получение h2 страницы
48. XPath	//h4	Содержимое всех подзаголовков h4
49. XPath	//head/link[@rel=’amphtml’]/@href	Ищем ссылки на APM-версии страниц
50. XPath	//iframe/@src	Все URL в контейнерах IFrame
51. XPath	//iframe[contains(@src ,’www.youtube.com/embed/’)]	Ищем все URL в IFrame, которые содержат Youtube
52. XPath	//iframe[not(contains(@src, ‘https://www.googletagmanager.com/’))]/@src	Ищем все URL в IFrame, которые не содержат GTM
53. XPath	//meta[@name=’description’]/@content	Содержимое мета-тега Description
54. XPath	//meta[@name=’robots’]/@content	Получение значений мета Robots (Index/Noindex)
55. XPath	//meta[@name=’theme-color’]/@content	Содержимое мета-тега цвета шапки для мобильной версии
56. XPath	//meta[@name=’viewport’]/@content	Содержимое тега Viewport
57. XPath	//meta[starts-with(@property, ‘fb:page_id’)]/@content	Содержимое разметки Open Graph 1
58. XPath	//meta[starts-with(@property, ‘og:title’)]/@content	Содержимое разметки Open Graph 2
59. XPath	//meta[starts-with(@property, ‘twitter:title’)]/@content	Содержимое разметки Open Graph 3
60. XPath	//span[@class=»example»]	Содержимое по классу
61. XPath	//table[@class=»chars-t»]/tbody/tr[2]/td[2]	Парсинг определенных ячеек в таблице 1
62. XPath	//table[@class=»chars-t»]/tbody/tr[4]/td[2]	Парсинг определенных ячеек в таблице 2
63. XPath	//title/text()	Получение title страницы
64. XPath	/descendant::h4[1]	Содержимое первого по списку подзаголовка h4
65. XPath	/descendant::h4[position() >= 0 and position() <= 10]	Содержимое первых 10 по списку подзаголовков h4
66. XPath	count(//h4)	Число подзаголовков h4
67. XPath	product: «(.*?)»	Структурированные данные JSON-LD 1
68. XPath	ratingValue: «(.*?)»	Структурированные данные JSON-LD 2
69. XPath	reviewCount: «(.*?)»	Структурированные данные JSON-LD 3
70. XPath	string-length(//h4)	Длина извлеченной строки
71. XPath	//a[contains(@rel,’ugc’)]/@href	UGC
72. XPath	//a[contains(@rel,’sponsored’)]/@href	Sponsored
73. XQuery	if (count(//a[starts-with(@href, ‘mailto:’)])) then «Есть почта» else «Нет почты»	Проверить, есть Email на странице или нет
74. XQuery	for $a in //li return $a	Получить содержимое всех элементов списка LI
75. HTML templates	<table><template:loop><tr><td></td><td>{text()}</td></tr></template:loop></table>	Поиск таблицы с атрибутом и извлечение текста из второго столбца
76. HTML templates	<table><tr></tr><tr><template:loop><td>{text()}</td></template:loop></tr></table>	Извлечение данных из второй строки таблицы
77. HTML templates	<table>{_tmp := 0}<template:loop><tr><td>{_tmp := $_tmp + . }</td></tr></template:loop>{result := $_tmp}</table>	Вычисление суммы чисел в колонке таблицы

Как скопировать защищенный текст с сайта с помощью Google Chrome

Случалось ли такое, что вы пытались скопировать текст с веб-страницы и это вам не удавалось? Вот простой способ, как копировать с сайта если копирование запрещено (с помощью браузера Google Chrome).

Авторы контента тратят свое время, чтобы создать качественные тексты, а другие копируют их контент и вставляют на свои сайты, не давая ничего взамен. Поэтому авторы заинтересованы в защите своих публикаций. Самый распространенный способ копирования со страницы — это выделить текст и, кликнув правой кнопкой мыши, выбрать пункт «Скопировать».

Существуют различные плагины для WordPress, позволяющие защитить тексты от копирования. Отключение функции копирования/вставки на сайте позволяет блокировать создание дубликатов публикаций. Так можно защитить свой сайт от плагиата.

Но люди копируют контент, не только чтобы использовать его на своих сайтах. Некоторые после того, как полностью скопировали страницу сайта, используют ее для создания контента высокого качества, отдавая должное авторам оригинальной информации.

В этой статье я покажу различные методы копирования текстов с защищенных веб-страниц.

Большинство владельцев сайтов использует JavaScript, чтобы отключить вывод контекстного меню. JavaScript блокирует и выделение текста, и клик правой кнопкой мыши. Но есть несколько способов, с помощью которых можно скопировать текст с сайта, защищенного таким образом.

Отключить JavaScript в Google Chrome

Большинство современных браузеров позволяют настроить JavaScript для любого сайта. Выполните следующие действия, чтобы отключить JavaScript в Google Chrome, и вы сможете скопировать «запароленную» страницу сайта:

В браузере Google Chrome перейдите в раздел Настройки >> Показать дополнительные настройки;
В разделе «Личные данные» нажмите на кнопку «Настройки контента»;
Затем выберите «Запретить выполнение JavaScript на всех сайтах».

Все готово!

Эту же процедуру можно использовать в Google Chrome для Android и в Firefox.

Использование прокси-сайтов

Прокси-сайты имеют много опций для просмотра веб-страниц. Все, что нужно сделать, это использовать те сайты, которые предлагают такие опции, как отключение защиты от клика правой кнопкой мыши и выделения текста:

Вот еще один способ, как скопировать страницу сайта. Существует небольшое расширение для браузера Google Chrome под названием Allow Copy, которое принудительно включает функции выделения, копирования и клика правой кнопки мыши на любой веб-странице.

Следуйте приведенным ниже инструкциям, чтобы использовать его:

Сначала нужно скачать и установить расширение Allow Copy;
Находясь на защищенной странице, нажмите на иконку расширения Allow Copy. Функция копирования будет сразу же включена на этом сайте;
Когда расширение отключено, оно отображается иконкой серого цвета с надписью OFF, а когда функция копирования-вставки включена, на иконке будет отображаться зеленая галочка.

После включения расширения Allow Copy можно свободно копировать тексты с любой веб-страницы.

В этой статье мы рассказали о способах, с помощью которых в браузере Google Chrome можно скопировать «запароленную» страницу сайта. Рассмотренные решения предназначены только для образовательных целей. Я не советую никому копировать в интернете любой защищенный авторским правом контент. Это руководство было создано для того, чтобы помочь студентам и остальным, которые будут использовать его в легальных целях.

Узнайте как фиксировать точки выхода с сайта и загрузку файлов

Google Analytics

Google Tag Manager

Материал обновлен:

06:10:2015

Комментарии:

Предлагаю рассмотреть еще несколько вариантов использования Google Tag Manager, на примере определения точек выхода с сайта и отслеживания загрузок различных файлов (например, прайс-листов, купонов и т.п.).

Описанные ниже действия подразумевают, что у вас уже установлен Google Tag Manager и в нем настроен код отслеживания Google Analytics. Если вы еще не сделали этого, то необходимо выполнить всего несколько простых шагов, которые описаны в этом материале (если ваш сайт работает на WordPress, посмотрите также эту инструкцию).

1. Определение точек выхода с сайта

Добавим на сайт тег для прослушивания кликов на ссылках, в качестве типа тега выберите Прослушивание кликов по ссылке в правилах активации укажите Все страницы, чтобы тег активировался на всех страницах сайта:

Тег прослушки кликов по ссылкам

Теперь Google Tag Manager фиксирует все клики на всех страницах нашего сайта.

Следующим шагом мы добавим возможность передачи данных о фиксации клика в Google Analytics. Предлагаю фиксировать клики в виде событий.

Поскольку при фиксации события в Google Analytics мы можем указать Категорию, Действие и Ярлык, мы можем использовать эти параметры впоследствии для работы с отчетами анализируя точки выхода. Давайте использовать следующий вариант:

Категория – переход по внешней (исходящей) ссылке;
Действие – страница, с которой ушел посетитель;
Ярлык – адрес сайта, на которой осуществлен переход.

Добавим макрос, который предоставит нам в удобной форме информацию о заголовке страницы, с которой ушел посетитель:

Добавить макрос Google Tag Manager

Укажите имя макроса и выберите тип Собственный код Java Script:

Макрос – заголовок страницы

В окне ввода кода добавьте следующие строки:

function() {

var u = {{element}};

return u.ownerDocument.title;

}

Сохраните макрос нажав Сохранить внизу страницы.

Создайте новый тег для передачи данных в Google Analytics. Укажите для него имя, тип тега выберите Google Analytics или Universal Analytics, в зависимости от используемой версии, введите идентификатор отслеживания, тип отслеживания Событие.

Далее заполним Параметры отслеживания событий:

Категория – введите текст Переход по внешней ссылке;
Действие – нажмите на значок справа от поля и выберите из списка макрос {{page title}};
Ярлык – нажмите на значок справа от поля и выберите из списка макрос {{element url}}.

После выполнения этих действий должно получиться примерно следующее:

Настройка события Google Analytics в Google Tag Manager

Теперь необходимо указать правила при которых тег будет активироваться:

Добавить правило активации тега

Нужного нам правила в списке существующих правил нет, поэтому выбираем Создать новое правило и задаем условия сопоставления. Поскольку мы передаем информацию в Google Analytics о переходу по ссылке и нас интересуют только внешние ссылки указываем следующее:

Правило для внешних ссылок

Небольшое пояснение. В операторе сопоставления для макроса {{element url}} необходимо указать не содержит, а строку для сравнения доменное имя вашего сайта.

Сохраняем правило, а затем изменения в теге нажатием на кнопки Сохранить. Создаем версию и публикуем ее.

Теперь можно перейти к отчетам в реальном времени и наблюдать за страницами с которых посетители покидают ваш сайт и узнать адреса страниц, на которые они переходят:

Отчет в реальном времени – точки выхода с сайта

2. Фиксируем загрузку файлов

Метод фиксации сведений о загрузке файлов используя Google Tag Manager схож с описанным выше, отличие в том, что нужно создать дополнительный макрос типа Собственный код JavaScript со следующим кодом:

function(){

var u = {{element}};

return u.pathname;

}

Затем добавить новый тег для передачи данных в Google Analytics, как описано выше, за исключением правил активации, которые укажем следующим образом:

Загрузка zip файла

Обратите внимание на второе условие. В приведенном примере отслеживание загрузка архива с расширением ZIP, если необходимо отследить другие расширения файлов используйте необходимые вам значения или регулярные выражения.

Пример отчета в реальном времени по загрузкам файла:

Пример отчета загрузок файлов

Если материал оказался полезным и интересным, пожалуйста поделитесь им в социальных сетях. Готов ответить на ваши вопросы и помочь с настройкой Google Tag Manager.

С сайта Роспотребнадзора исчезла новость об ищущих коронавирус собаках :: Общество :: РБК

В ней говорилось о том, что ведомство совместно с другими организациями, в том числе «Аэрофлотом», разрабатывает такой способ выявлять больных COVID-19. В Роспотребнадзоре отказались комментировать исчезновение публикации

Фото: Илья Питалев / РИА Новости

С сайта федерального Роспотребнадзора пропало сообщение о том, что ведомство совместно с несколькими другими организациями разрабатывает способ идентификации больных коронавирусом с помощью собак.

В среду о новом способе поиска зараженных написали СМИ, поставив ссылку на соответствующее сообщение ведомства. Однако позже ссылка стала вести на страницу с надписью «Элемент не найден». Тем не менее на сайте управления ведомства по Самарской области аналогичный материал на момент публикации доступен.

Google закэшировал исходное сообщение федерального Роспотребнадзора. В нем говорилось, что с Роспотребнадзором над проектом работает, в частности, «Аэрофлот».

Кинологическая служба авиакомпании уже начала тренировку служебных собак по выявлению образцов биоматериалов тех людей, которые заразились коронавирусом, сообщал Роспотребнадзор.

РБК направил запрос в «Аэрофлот». В Роспотребнадзоре отказались комментировать исчезновение сообщения с сайта.

Я хочу стянуть информацию с сайта. Как это сделать?

Допустим, нам нужно получить данные с сайта, сбор которых вручную нецелесообразен или невозможен из-за объёма. В таком случае мы можем автоматизировать процесс, используя инструменты, описанные далее.

Библиотека requests

Python-библиотека для выполнения запросов к серверу и обработки ответов. Фундамент скрипта для парсинга и наше основное оружие. Пользуясь данной библиотекой мы получаем содержимое страницы в виде html для дальнейшего парсинга.

import requests

response = requests.get('https://ya.ru') # get-запрос
print(response.text) # вывод содержимого страницы

payload = {'key1': 'value1', 'key2': 'value2'}
response = requests.get('http://httpbin.org/get', params=payload) # запрос с параметрами

headers = {'user-agent': 'my-app/0.0.1'} 
response = requests.get(url, headers=headers) # запрос с определенными html заголовками

Документация: http://docs.python-requests.org/en/master/user/quickstart/

API

Application programming interface — программный интерфейс приложения, предоставляемый владельцем веб-приложения для других разработчиков. Отсутствие API, способного удовлетворить наши нужды — первое в чем стоит убедиться прежде чем бросаться анализировать исходный код страницы и писать для нее парсер. Множество популярных сайтов имеет собственное api и документацию, которая объясняет как им пользоваться. Мы можем использовать api таким образом — формируем http-запрос согласно документации, и получаем ответ при помощи requests.

BS4

Beautifulsoup4 — это библиотека для парсинга html и xml документов. Позволяет получить доступ напрямую к содержимому любых тегов в html.

from bs4 import BeautifulSoup

soup = BeautifulSoup(raw_html, 'html.parser')
print(soup.find("p", class_="some-class").text) # вывод содержимого тэга 'p' классом 'some-class'

Подробная документация: https://www.crummy.com/software/BeautifulSoup/bs4/doc/

Selenium Web Driver

Данные на сайте могут генерироваться динамически при помощи javascript. В таком случае спарсить эти данные силами requests+bs4 не удастся. Дело в том, что bs4 парсит исходный код страницы, не исполняя js. Для исполнения js кода и получения страницы, идентичной той, которую мы видим в браузере, можно использовать selenium web driver — это набор драйверов для различных браузеров, снабжающийся библиотеками для работы с этими драйверами.

Большой туториал по парсингу: http://thiagomarzagao.com/2013/11/12/webscraping-with-selenium-part-1/

А что делать, если там авторизация?

Предварительно авторизоваться, отправив post-запрос и инициировать сессию:

session = requests.Session()
data = {"login_username":"login", "login_password":"password"}
url = "http://site.com/login.php"
response = session.post(url, data=data)

А что, если сайт банит за много запросов?

Установить задержку между запросами:

response = requests.get(url, timeout=(10, 0.01)) # таймаут на соединения, таймаут на чтение (в секундах)

Притвориться браузером, используя selenium web driver или передав содержимое заголовка user-agent, формируя запрос:

user_agent = ('Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:50.0) '
              'Gecko/20100101 Firefox/50.0')
request = requests.get(url, headers={'User-Agent':user_agent})

Использовать прокси:

request = requests. get(url, proxies={"http":"http://10.10.1.10:3128"})

С сайта Центра Мейерхольда удалили страницу актрисы, поддержавшей Навального

https://www.znak.com/2021-02-08/s_sayta_centra_meyerholda_udalili_stranicu_aktrisy_podderzhavshey_navalnogo

2021.02.08

Театральный центр имени В. С. Мейерхольда удалил со своего сайта страницу актрисы Варвары Шмыковой. Внимание на это обратил на своей странице в Facebook актер Максим Виторган. «Конечно, то, что это происходит в Центре имени МЕЙЕРХОЛЬДА (!!!) особенно пикантно. Что впереди?» — прокомментировал он.

Варвара ШмыковаСтраница Варвары Шмыковой в Facebook / Гоголь-Центр

В комментариях под постом арт-директор центра Елена Ковальская сообщила, что страница «временно закрыта». «Мои сотрудники сопротивлялись, но сделали это по моему требованию. Что мною двигало или кто, объяснять не буду», — прокомментировала она. В разговоре с «Медиазоной» Ковальская добавила, что Шмыкова продолжит участвовать в постановках театра.

В поддержку Варвары Шмыковой уже выступили несколько российских актеров театра и кино. «Я, естественно не знаю, что там реально произошло и происходит, но вот факт и вот ответ. И вот время, в котором мы живем. И вот страна реально превратилась в репрессивное полицейское государство. И да, друзья, пора собирать тревожные чемоданчики», — прокомментировала происходящее актриса Юлия Ауг.

Варвара Шмыкова записывала обращение в поддержку Алексея Навального после просмотра фильма-расследования о «дворце Путина». К тому моменту Навального уже задержали на границе с Россией, когда он возвращался в страну из Германии после реабилитации, следовавшей за попыткой отравления. «Мне грустно от того, что это огромное количество денег, которое потрачено на удовлетворение одного человека, ну или удовлетворение одной семьи или трех семей, уходит вот так безобразно, просто мелочно в то время, когда есть люди, которые реально нуждаются в помощи. Огромный вопрос, почему так сложно в России продвигаются благотворительные фонды, их практически ни один не поддерживает государство. […] Гражданин Российской Федерации задержан ни за что. Что с ним вытворяют — это безнравственно и ужасно. Это касается каждого из нас — неужели это не понятно?» — говорила актриса на своей странице в Instagram.

Хочешь, чтобы в стране были независимые СМИ? Поддержи Znak.com

Как работает Интернет — Изучите веб-разработку

Как работает Интернет обеспечивает упрощенное представление о том, что происходит, когда вы просматриваете веб-страницу в веб-браузере на своем компьютере или телефоне.

Эта теория не важна для написания веб-кода в краткосрочной перспективе, но вскоре вы действительно начнете получать пользу от понимания того, что происходит в фоновом режиме.

Компьютеры, подключенные к Интернету, называются клиентами и серверами . Упрощенная схема их взаимодействия может выглядеть так:

Клиенты — это типичные устройства веб-пользователя, подключенные к Интернету (например, ваш компьютер, подключенный к вашему Wi-Fi, или ваш телефон, подключенный к вашей мобильной сети) и программное обеспечение для доступа в Интернет, доступное на этих устройствах (обычно это веб-браузер, например Firefox или Chrome).
Серверы — это компьютеры, на которых хранятся веб-страницы, сайты или приложения. Когда клиентское устройство хочет получить доступ к веб-странице, копия веб-страницы загружается с сервера на клиентский компьютер для отображения в веб-браузере пользователя.

Клиент и сервер, которые мы описали выше, не раскрывают всей истории. Есть много других частей, и мы опишем их ниже.

А пока представим, что Интернет — это дорога. На одном конце дороги клиент, который похож на ваш дом.На другом конце дороги находится сервер, в котором вы хотите что-то купить.

В дополнение к клиенту и серверу нам также нужно передать привет:

Ваше подключение к Интернету : позволяет отправлять и получать данные в Интернете. По сути, это как улица между вашим домом и магазином.
TCP / IP : Протокол управления передачей и Интернет-протокол — это протоколы связи, которые определяют способ передачи данных в Интернете. Это как транспортные механизмы, позволяющие оформить заказ, зайти в магазин и купить товар. В нашем примере это похоже на машину или байк (или что-то еще, что вы можете обойти).
DNS : Серверы доменных имен похожи на адресную книгу для веб-сайтов. Когда вы вводите веб-адрес в своем браузере, браузер проверяет DNS, чтобы найти реальный адрес веб-сайта, прежде чем он сможет найти веб-сайт. Браузеру необходимо выяснить, на каком сервере находится веб-сайт, чтобы отправлять HTTP-сообщения в нужное место (см. Ниже).Это похоже на поиск адреса магазина, чтобы получить к нему доступ.
HTTP : протокол передачи гипертекста — это протокол приложения, который определяет язык, на котором клиенты и серверы могут общаться друг с другом. Это похоже на язык, на котором вы заказываете товары.
Файлы компонентов : Веб-сайт состоит из множества разных файлов, которые подобны различным частям товаров, которые вы покупаете в магазине. Эти файлы бывают двух основных типов:
- Файлы кода : веб-сайты в основном создаются на основе HTML, CSS и JavaScript, хотя вы познакомитесь с другими технологиями чуть позже.
- Активы : это собирательное название для всего остального, что составляет веб-сайт, например изображений, музыки, видео, документов Word и PDF-файлов.

Когда вы вводите веб-адрес в свой браузер (для нашей аналогии это похоже на прогулку в магазин):

Браузер переходит на DNS-сервер и находит реальный адрес сервера, на котором находится веб-сайт (вы находите адрес магазина).
Браузер отправляет на сервер сообщение HTTP-запроса с просьбой отправить копию веб-сайта клиенту (вы идете в магазин и заказываете товар).Это сообщение и все другие данные, передаваемые между клиентом и сервером, отправляются через ваше интернет-соединение с использованием TCP / IP.
Если сервер одобряет запрос клиента, сервер отправляет клиенту сообщение «200 OK», что означает «Конечно, вы можете посмотреть этот веб-сайт! Вот он», а затем начинает отправлять файлы веб-сайта в браузер в качестве серия небольших фрагментов, называемых пакетами данных (магазин дает вам товары, а вы приносите их домой).
Браузер собирает небольшие фрагменты в целую веб-страницу и отображает ее вам (товары прибывают к вам — новые блестящие штуки, круто!).

Настоящие веб-адреса — это не красивые запоминающиеся строки, которые вы вводите в адресную строку, чтобы найти свои любимые веб-сайты. Это специальные числа, которые выглядят так: 63.245.215.20 .

Это называется IP-адресом, и он представляет собой уникальное место в сети. Однако запомнить это непросто, не так ли? Вот почему были изобретены серверы доменных имен. Это специальные серверы, которые сопоставляют введенный вами в браузере веб-адрес (например, «mozilla.org») с реальным (IP) адресом веб-сайта.

На сайты

можно попасть напрямую через их IP-адреса. Вы можете узнать IP-адрес веб-сайта, введя его домен в такой инструмент, как IP Checker.

Ранее мы использовали термин «пакеты» для описания формата, в котором данные отправляются от сервера к клиенту. Что мы здесь имеем в виду? В основном, когда данные отправляются через Интернет, они отправляются в виде тысяч небольших фрагментов, так что многие разные веб-пользователи могут загружать один и тот же веб-сайт одновременно. Если бы веб-сайты отправлялись как отдельные большие блоки, только один пользователь мог бы загружать их по одному, что, очевидно, сделало бы Интернет очень неэффективным и не очень интересным в использовании.

Оценка информации в Интернете

«предыдущая страница 8 из 10 следующая»

«точка com» «точка gov» — суффиксы и коды стран объяснены

Любая информация, которую вы используете для поддержки идей и аргументов в исследовательской работе, должна подвергаться некоторой проверке. Печатные материалы, собранные в библиотеке, проходят процесс оценки, поскольку библиотекари выбирают их для включения в свои коллекции. Также проводится оценка веб-сайтов, включенных в каталоги поиска, таких как Yahoo !, по крайней мере, с точки зрения классификации и размещения сайтов в схеме категоризации.Однако сайты, собираемые «пауками» или «роботами» для поисковых систем, не проходят никакой оценки.

Нет никаких реальных ограничений или редакционных процессов для публикации информации в Интернете, помимо некоторых базовых знаний о создании веб-страниц и доступе к хост-компьютеру. Кто угодно может публиковать мнение, сатиру, розыгрыш или заведомо ложную информацию. Чтобы убедиться, что веб-сайты, которые вы используете в качестве источников информации, приемлемы для исследовательских целей, вам следует задавать вопросы об этих сайтах.Ниже приведены некоторые элементы, на которые следует обратить внимание, прежде чем принимать решение об использовании веб-сайта в качестве исследовательского ресурса:

Суффикс домена

Термин «dot.com» стал повсеместным словосочетанием в английском языке. «Dot.com» действительно относится к домену веб-сайта. Сайты в Интернете сгруппированы по их URL-адресам в соответствии с типом организации, предоставляющей информацию на сайте. Например, любое коммерческое предприятие или корпорация, имеющая веб-сайт, будет иметь суффикс домена.com, что означает, что это коммерческая организация.

Суффикс домена дает вам представление о цели или аудитории веб-сайта. Суффикс домена также может дать вам представление о географическом происхождении веб-сайта. Многие сайты из Великобритании будут иметь суффикс домена .uk.

Ниже приводится список наиболее распространенных суффиксов домена и типов организаций, которые будут их использовать.

.com
Коммерческий сайт. Информация, предоставленная коммерческими организациями, как правило, проливает позитивный свет на продвигаемый продукт.Хотя эта информация не обязательно может быть ложной, вы можете получить только часть картины. Помните, что за каждым коммерческим сайтом стоит денежный стимул в предоставлении вам информации, будь то для хороших связей с общественностью или для прямой продажи вам продукта.

.edu
Образовательное учреждение. Сайты, использующие это доменное имя, — это школы от детских садов до высших учебных заведений. Если вы посмотрите URL-адрес своего учебного заведения, вы заметите, что он заканчивается доменом.edu. Информация с сайтов в этом домене требует очень тщательного изучения. Если оно получено из отдела или исследовательского центра учебного заведения, оно обычно может считаться достоверным. Однако личные веб-сайты учащихся обычно не отслеживаются школой, даже если они находятся на школьном сервере и используют домен .edu.

.gov
Правительство. Если вы встретили сайт с этим доменом, значит, вы просматриваете сайт федерального правительства. Все ветви федерального правительства США используют этот домен.Такая информация, как статистика переписи населения, слушания в Конгрессе и постановления Верховного суда, будет включена в сайты с этим доменом. Информация получена из надежного источника.

.org
Традиционно некоммерческая организация. Такие организации, как Американский Красный Крест или PBS (Система общественного вещания) используют этот суффикс домена. Как правило, информация на сайтах такого типа достоверна и беспристрастна, но есть примеры организаций, которые решительно отстаивают определенные точки зрения по сравнению с другими, например, Национальный комитет по праву на жизнь и Планируемое отцовство. Вы, вероятно, захотите в наши дни более внимательно изучить этот домен. Некоторые коммерческие интересы могут быть конечными спонсорами сайта с этим суффиксом.

мил
Военный. Этот суффикс домена используется различными видами вооруженных сил США.

.net
Сеть. Вы можете найти любой сайт под этим суффиксом домена. Он действует как универсальное средство для сайтов, которые не вписываются ни в один из предыдущих суффиксов домена.Информация с этих сайтов требует тщательного изучения.

Суффиксы домена страны
.au	Австралия
.в	Индия
.br	Бразилия
.it	Италия
. ок.	Канада
. М x	Мексика
.fr	Франция
.tw	Тайвань
.il	Израиль
.Великобритания	объединенное Королевство

Полномочия

Указывает ли сайт, который вы оцениваете, автора? Если ответственный автор не указан, есть ли указание на спонсорство? Пытаясь определить надежность информации, представленной на любом носителе, вы хотите иметь некоторое представление о полномочиях автора. Являются ли они экспертами по теме, о которой пишут? Какое у них образование? Помните, что кто угодно может публиковать в сети.Им не обязательно знать, о чем они говорят.

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

Валюта

Информация, которая устарела, может быть неверной или неполной. Хорошо обслуживаемый веб-сайт обычно сообщает вам в нижней части начального экрана, когда он был обновлен в последний раз и, возможно, даже когда он был первоначально создан и размещен в Интернете.

Ссылки

Информационный веб-сайт, на котором все гиперссылки не работают, может быть не очень надежным ресурсом. Неработающие гиперссылки не редкость из-за постоянно меняющейся природы Интернета, но когда на веб-сайте много неработающих ссылок, это может указывать на то, что сайт не поддерживается на регулярной основе.

URL

Адрес сайта может дать вам подсказку относительно окончательного спонсорства сайта. Если вы не можете определить, кто написал сайт или кто или что спонсирует сайт, попробуйте усечь URL до его корневого адреса.Это сообщит вам, где размещается сайт. Например, на этом сайте представлена информация о суточных суточных нормах питания:

http://www. mikeschoice.com/reports/rda.htm.

Если вы усечете URL-адрес до его корневого адреса http://www.mikeschoice.com, вы обнаружите, что это сайт, продающий минеральные добавки. Учитывая очевидную предвзятость, это, вероятно, не лучший источник информации о питании.

Еще один ключ к пониманию того, какой тип сайта вы смотрите, — это наличие символа ~ (тильда) в URL-адресе.Этот символ обычно указывает на то, что сайт является персональной веб-страницей, и информация должна быть тщательно изучена.

Сравнение

Всегда сравнивайте информацию, которую вы найдете на веб-сайте, с другими источниками информации. Как правило, вы не хотите использовать только веб-сайты в качестве поддержки для исследовательской работы, поэтому вам следует искать и другие типы источников, такие как книги, журнальные статьи и т. Д. Как соотносится информация, найденная в различных форматах?

«предыдущая страница 8 из 10 следующая»

Как пользователи читают в Интернете

В ходе исследования того, как люди читают веб-сайты, мы обнаружили, что 79 процентов наших тестовых пользователей всегда сканировали любую новую страницу, на которую они попадали; только 16% читают слово за словом. (Обновление: более новое исследование показало, что пользователи читают информационные бюллетени по электронной почте даже быстрее, чем веб-сайты.)

В результате веб-страницы должны использовать сканируемого текста , используя

выделено ключевых слов (гипертекстовые ссылки служат одной из форм выделения; вариации шрифта и цвета — другие)
содержательные подрубрик (не «умные»)
маркированный списков
одна идея на абзац (пользователи пропускают любые дополнительные идеи, если их не уловили первые несколько слов абзаца)
стиль перевернутой пирамиды, начиная с заключения
вдвое меньше слов (или меньше), чем при обычном письме

Мы обнаружили, что доверие важно для пользователей Интернета, поскольку неясно, кто стоит за информацией в Интернете и можно ли доверять странице.Доверие можно повысить за счет высококачественной графики, хорошего письма и использования исходящих гипертекстовых ссылок . Ссылки на другие сайты показывают, что авторы сделали свою домашнюю работу и не боятся позволять читателям посещать другие сайты.

Пользователи ненавидят «маркетологов» ; рекламный стиль письма с хвастливыми субъективными утверждениями («самый горячий»), который в настоящее время преобладает в сети. Пользователи Интернета заняты: они хотят знать правдивые факты. Кроме того, доверие страдает, когда пользователи ясно видят, что сайт преувеличивает.

Измерение эффекта от улучшения веб-письма

Чтобы измерить эффект некоторых из установленных нами руководящих принципов по содержанию, мы разработали пять разных версий одного и того же веб-сайта (та же основная информация; разные формулировки; одинаковая навигация по сайту). Затем мы попросили пользователей выполнить одни и те же задачи с разными сайтами. Как показано в таблице, удобство использования было значительно выше для краткой версии (на 58% лучше) и для версии для сканирования (на 47% лучше). И когда мы объединили три идеи для улучшения стиля письма в один сайт, результат был поистине звездным: Юзабилити на 124% лучше .

Версия сайта Образец абзаца Улучшение удобства использования
(относительно контрольного условия)

Рекламное письмо (контрольное условие)
с использованием слова «marketese», которое можно найти на многих коммерческих сайтах Небраска наполнена всемирно признанными достопримечательностями, которые неизменно привлекают большие толпы людей каждый год. В 1996 году одними из самых популярных мест были Государственный парк Форт-Робинсон (355 000 посетителей), Национальный памятник Скоттс-Блафф (132 166), Государственный исторический парк и музей Арбор-Лодж (100 000), Кархендж (86 598), Музей Штур Пионер прерий ( 60 002) и Государственный исторический парк Buffalo Bill Ranch (28 446). 0%
(по определению)

Краткий текст
с примерно половиной количества слов в качестве условия управления В 1996 году шестью наиболее посещаемыми достопримечательностями Небраски были Государственный парк Форт Робинсон, Национальный памятник Скоттс-Блафф, Государственный исторический парк и музей Арбор-Лодж, Кархендж, Музей Пионера прерий Штур и Государственный исторический парк Ранчо Баффало Билла. 58%

Макет для сканирования
с использованием того же текста, что и условие управления в макете, который облегчил сканирование Небраска наполнена всемирно признанными достопримечательностями, которые неизменно привлекают большие толпы людей каждый год.В 1996 году одними из самых популярных мест были:

Государственный парк Форт Робинсон (355 000 посетителей)

Национальный памятник Скоттс Блафф (132 166)

Государственный исторический парк и музей Arbor Lodge (100 000)

Кархендж (86,598)

Stuhr Museum of the Prairie Pioneer (60 002)

Государственный исторический парк ранчо Буффало Билла (28 446).

47%

Объективный язык
Использование нейтральной, а не субъективной, хвастливой или преувеличенной формулировки (в остальном то же, что и контрольное условие) Небраска имеет несколько достопримечательностей. В 1996 году одними из самых посещаемых мест были Государственный парк Форт Робинсон (355 000 посетителей), Национальный памятник Скоттс-Блафф (132 166), Государственный исторический парк и музей Арбор-Лодж (100 000), Кархендж (86 598), Музей Пионера Прерии (60 002), и Государственный исторический парк Ранчо Буффало Билла (28 446). 27%

Комбинированная версия
, использующая вместе все три улучшения стиля письма: краткое, с возможностью сканирования и объективное В 1996 году шесть самых посещаемых мест в Небраске были:

Государственный парк Форт Робинсон

Национальный памятник Скоттс-Блафф

Государственный исторический парк и музей Arbor Lodge

Carhenge

Stuhr Museum of the Prairie Pioneer

Государственный исторический парк ранчо Буффало Билла

124%

Для нас было несколько удивительно, что удобство использования было значительно улучшено в объективной языковой версии (на 27% лучше). Мы ожидали, что пользователям понравится эта версия больше, чем рекламный сайт (как они и сделали), но мы думали, что показатели производительности будут одинаковыми для обоих языков. Как оказалось, наши четыре показателя производительности (время, ошибки, память и структура сайта) также были лучше для объективной версии, чем для рекламной версии. Наша гипотеза, объясняющая этот вывод, состоит в том, что рекламный язык накладывает когнитивное бремя на пользователей, которым приходится тратить ресурсы на отфильтровывание преувеличений, чтобы добраться до фактов.Когда люди читают абзац, который начинается со слов «Небраска наполнена всемирно признанными достопримечательностями», их первая реакция — нет, это , а не , , и эта мысль их замедляет и отвлекает от использования сайта.

Полный отчет

Полный отчет о том, как пользователи читают в Интернете, доступен для загрузки.

Как долго пользователи остаются на веб-страницах?

Как долго пользователи будут оставаться на веб-странице перед тем, как уйти? Это извечный вопрос, но ответ всегда был один:

В среднем посещение страницы длится немногим меньше минуты.

По мере того, как пользователи бегут по веб-страницам, у них есть время прочитать только четверть текста на страницах, которые они фактически посещают (не говоря уже обо всех тех, которые они не посещают). Таким образом, если ваш текст не является исключительно ясным и целенаправленным, мало что из того, что вы говорите на своем веб-сайте, дойдет до клиентов.

Однако, хотя пользователи всегда торопятся в Интернете, время, которое они тратят на посещение отдельных страниц, сильно различается: иногда люди сразу уходят, а иногда задерживаются намного дольше минуты.Учитывая это, среднее — не самый плодотворный способ анализа поведения пользователей. Пользователи — люди — их поведение сильно различается и не фиксируется полностью одним числом.

Оставление веб-страниц: функция опасности Вейбулла

Исследование, проведенное Чао Лю и его коллегами из Microsoft Research, теперь дает математическое понимание поведения пользователей при уходе с страниц. Ученые собрали данные из «популярного плагина для веб-браузера», проанализировав продолжительность посещений 205 873 различных веб-страниц , для которых они зафиксировали более 10 000 посещений . Достаточно сказать: эти ребята обработали много данных (более 2 миллиардов задержек).

Результат: времени, которое пользователи проводят на веб-странице, соответствует распределению Вейбулла .

99,9% читателей теперь спросят: Что такое распределение Вейбулла?

Weibull — это концепция обеспечения надежности, которая используется для анализа наработки на отказ компонентов . Функция опасности модели указывает вероятность того, что компонент выйдет из строя в момент времени t , при условии, что он работал нормально до момента времени t .

Итак, после замены запасной части в единице оборудования анализ Вейбулла предсказывает, когда вам придется заменить ее снова. Это также позволяет проводить анализ рисков, выходящий за рамки упрощенного среднего времени до отказа. А если у вас много оборудования, вы можете использовать агрегированный анализ, например, для управления запасами запасных частей.

Конечно, при анализе посещений сети мы просто заменяем «отказ компонента» на «пользователь покидает страницу». В своей исследовательской работе Лю и его коллеги проводят интенсивный статистический анализ, чтобы показать, что модель Вейбулла точно соответствует эмпирически наблюдаемому поведению пользователей.

Согласно более раннему исследованию, существует 2 различных вида распределения Вейбулла:

Положительное старение : чем дольше компонент находится в эксплуатации, тем больше вероятность, что откажет. Другими словами, функция риска увеличивается для больших значений t . Это имеет интуитивный смысл, потому что чем дольше используется материал, тем больше он изнашивается. Таким образом, то, что использовалось долгое время, приближается к своему пределу.

Отрицательное старение : Чем дольше компонент находится в эксплуатации, тем меньше вероятность выхода из строя. Здесь функция риска уменьшается для больших значений t . Это имеет смысл, когда отдельные компоненты различаются по качеству: плохо сделанные компоненты обычно выходят из строя раньше, поэтому все, что находилось в эксплуатации в течение длительного времени, скорее всего, будет особенно надежным и обычно прослужит еще дольше.

Отрицательное старение: быстро уйти или остаться надолго

Исследователи обнаружили , что 99% веб-страниц имеют отрицательный эффект старения .В исследованиях взаимодействия человека с компьютером (HCI) крайне редко удается получить столь убедительные результаты, и Лю и его коллеги должны заслужить признание в открытии важной новой идеи.

Почему отрицательное старение? Потому что веб-страницы действительно очень разного качества. Пользователи знают это и проводят свое первое время на странице в безжалостной сортировке, чтобы как можно скорее избавиться от шлаков. Люди редко задерживаются на веб-страницах, но когда пользователи решают, что страница ценная, они могут оставаться на ней ненадолго.

На следующей диаграмме показана функция риска — то есть вероятность ухода — для медианных параметров Вейбулла, соответствующих огромному набору данных ученых:

Из диаграммы видно, что первых 10 секунд посещения страницы имеют решающее значение для решения пользователей остаться или уйти.Вероятность ухода в эти первые несколько секунд очень высока, потому что пользователи настроены крайне скептически, поскольку в прошлом они страдали бесчисленным количеством плохо спроектированных веб-страниц. Люди знают, что большинство веб-страниц бесполезны, и ведут себя соответствующим образом, чтобы не тратить больше времени, чем необходимо, на плохие страницы.

Если веб-страница выдержит эту первую — чрезвычайно суровую — 10-секундную оценку, пользователи будут немного оглядываться. Тем не менее, они по-прежнему с большой вероятностью уйдут в течение следующих 20 секунд после посещения.Только после того, как люди оставались на странице примерно 30 секунд, кривая становится относительно плоской. Люди продолжают уходить каждую секунду, но гораздо медленнее, чем в течение первых 30 секунд.

Итак, если вы можете убедить пользователей оставаться на вашей странице на полминуты, есть большая вероятность, что они останутся намного дольше — часто 2 минуты или больше, что для Интернета — целая вечность.

Итак, грубо говоря, здесь два случая:

плохих страниц , которые удаляются за несколько секунд; и

хороших страниц , на которые можно выделить несколько минут.

Примечание: «хорошо» или «плохо» — это решение, которое каждый отдельный пользователь принимает в течение первых нескольких секунд после прибытия. Смысл дизайна очевиден:

Чтобы привлечь внимание пользователя на несколько минут, вы должны четко сообщить свое ценностное предложение в течение 10 секунд .

Справочная и связанная литература

Чао Лю, Рен Уайт и Сьюзен Дюмэ. 2010. Понимание поведения при просмотре веб-страниц с помощью анализа Вейбулла времени ожидания.В материалах 33-й международной конференции ACM SIGIR по исследованиям и разработкам в области информационного поиска (SIGIR ’10)

Оптимизация для повторных посещений, а не для показателя отказов

Связанный контент увеличивает просмотры страниц, если все сделано правильно

Почему туристы здесь никчемны

Руководство по миграции веб-сайта: SEO-стратегия, процесс и контрольный список

Что такое миграция сайта?

Перенос сайта — это термин, широко используемый специалистами по поисковой оптимизации для описания любого события, при котором веб-сайт претерпевает существенные изменения в областях, которые могут существенно повлиять на видимость в поисковых системах — обычно это изменения местоположения, платформы, структуры, контента, дизайна или UX сайта.

Документация Google по миграции на сайт не рассматривает их подробно и преуменьшает тот факт, что так часто они приводят к значительным потерям трафика и доходов, которые могут длиться от нескольких недель до нескольких месяцев — в зависимости от степени сигналов ранжирования в поисковых системах. были затронуты, а также сколько времени может потребоваться затронутому бизнесу, чтобы развернуть успешный план восстановления.

Ссылки быстрого доступа

Контрольный список миграции сайта (8-страничный PDF-файл)
Примеры миграции сайта
Типы миграции сайта
Распространенные ошибки миграции сайта
Процесс миграции сайта
1.Объем и планирование
2. Подготовка к запуску
3. Тестирование перед запуском
4. Действия в день запуска
5. Тестирование после запуска
6. Обзор производительности
Приложение: Полезные инструменты

Примеры миграции сайта

В следующем разделе обсуждается, как выглядят как успешные, так и неуспешные миграции сайтов, и объясняется, почему на 100% можно выйти из миграции сайта без значительных потерь.

Развенчание мифа о «ожидаемом спаде трафика»

Любой, кто был вовлечен в миграцию сайта, вероятно, слышал широко распространенную теорию о том, что это де-факто приведет к потере трафика и доходов.Несмотря на то, что в этом утверждении есть доля правды для некоторых очень конкретных случаев (например, при переходе от установленной области к совершенно новой), его не следует рассматривать как евангелие. Совершенно возможно осуществить миграцию без потери трафика или доходов; вы даже можете ощутить значительный рост сразу после запуска обновленного веб-сайта. Однако этого можно достичь только в том случае, если каждый шаг был хорошо спланирован и выполнен.

Примеры неудачных миграций сайтов

На следующем графике показана неудачная миграция сайта крупного розничного продавца в Великобритании, когда веб-сайт потерял 35% своей видимости через две недели после перехода с HTTP на HTTPS.Им потребовалось около шести месяцев, чтобы полностью восстановиться, что должно было существенно повлиять на доход от обычного поиска. Это типичный пример плохой миграции сайта, возможно, вызванной плохим планированием или реализацией.

Пример неудачной миграции сайта — восстановление заняло 6 месяцев!

Но восстановление не всегда возможно. Приведенный ниже график видимости взят от другого крупного розничного продавца в Великобритании, где переход с HTTP на HTTPS привел к постоянной потере видимости на 20%.

Еще один пример неудачной миграции сайта — нет признаков восстановления через 6 месяцев!

Фактически, вполне возможно перейти с HTTP на HTTPS без потери такого большого объема трафика и на такой длительный период, за исключением первых нескольких недель, когда наблюдается высокая волатильность, когда Google обнаруживает новые URL-адреса и обновляет результаты поиска.

Примеры успешных миграций сайтов

Как выглядит успешная миграция сайта? Это во многом зависит от типа миграции сайта, целей и ключевых показателей эффективности (подробнее позже). Но в большинстве случаев успешная миграция сайта демонстрирует хотя бы одну из следующих характеристик:

Минимальная потеря видимости в течение первых нескольких недель (краткосрочная цель)

Рост видимости в дальнейшем — в зависимости от типа миграции (долгосрочная цель)

Следующий отчет о видимости взят из перехода сайта с HTTP на HTTPS, который также сопровождался значительным улучшением времени загрузки страницы сайта.

Следующий отчет о видимости является результатом полного капитального ремонта сайта, в котором мне посчастливилось участвовать за несколько месяцев до этого и поддерживаться на этапах стратегии, планирования и тестирования, которые были одинаково важны.

Как это обычно бывает в проектах миграции на месте, дату запуска приходилось переносить несколько раз из-за рисков преждевременного запуска нового сайта и до полного устранения основных технических препятствий. Но, как вы можете видеть на графике видимости ниже, ожидание того стоило. Органическая видимость не только не упала (как обычно ожидает большинство), но и начала расти с первой недели.

Рост видимости через месяц после миграции достиг 60%, в то время как органический рост трафика через два месяца после запуска превысил 80%.

Пример очень успешной миграции сайта — мгновенный рост после запуска нового сайта!

Это был довольно сложный переход, поскольку новый веб-сайт был переработан и построен с нуля на новой платформе с улучшенной таксономией сайтов, которая включала новые целевые страницы, обновленную структуру URL-адресов, множество перенаправлений для сохранения равноправия ссылок, а также переключение с HTTP на HTTPS.

В общем, введение слишком большого количества изменений одновременно может быть непростой задачей, потому что если что-то пойдет не так, вам будет сложно понять, в чем именно виноват.Но в то же время откладывать серьезные изменения на потом тоже не идеально, так как это потребует дополнительных ресурсов. Если вы знаете, что делаете, одновременное внесение нескольких положительных изменений может оказаться очень рентабельным.

Прежде чем вдаваться в подробности того, как можно превратить сложный проект миграции сайта в успешный, важно пройтись по основным типам миграции сайта, а также объяснить основные причины, по которым многие миграции сайтов терпят неудачу.

Типы миграции сайта

Существует множество типов миграции сайтов.Все зависит от характера происходящих изменений.

Документация Google в основном касается миграции с изменением местоположения сайта, которые подразделяются на следующие категории:

Сайт перемещается на с изменениями URL

Сайт перемещается на без изменений URL

Миграция перемещения сайта

Обычно это происходит, когда сайт переходит на другой URL-адрес по любой из следующих причин:

Изменение протокола

Классический пример — переход с HTTP на HTTPS.

Изменение субдомена или подпапки

Очень часто встречается в международной поисковой оптимизации, когда компания решает переместить один или несколько ccTLD в субдомены или подпапки. Другой распространенный пример — когда мобильный сайт, расположенный в отдельном субдомене или подпапке, становится адаптивным, и URL-адреса для настольных компьютеров и мобильных устройств едины.

Изменение доменного имени

Обычно происходит, когда компания проводит ребрендинг и должна перейти с одного домена на другой.

Изменение домена верхнего уровня

Это обычное явление, когда компания решает запустить международные веб-сайты и ей необходимо перейти от ccTLD (национальный домен верхнего уровня) к gTLD (общий домен верхнего уровня) или наоборот, e.грамм. переход с .co.uk на .com или переход с .com на .co.uk и т. д.

Изменения в структуре сайта

Это изменения в архитектуре сайта, которые обычно влияют на внутренние ссылки сайта и структуру URL.

Другие виды миграции

Существуют и другие типы миграции, которые запускаются изменениями содержания, структуры, дизайна или платформы сайта.

Переплатформенность

Это тот случай, когда веб-сайт перемещается с одной платформы / CMS на другую, т.е.грамм. переход с WordPress на Magento или просто обновление до последней версии платформы. В некоторых случаях повторная платформа может также привести к изменению дизайна и URL-адресов из-за технических ограничений, которые часто возникают при смене платформ. Вот почему миграции с повторной платформой редко приводят к тому, что веб-сайт выглядит точно так же, как предыдущий.

Перенос содержимого

Основные изменения содержания, такие как переписывание содержания, консолидация или сокращение содержания, могут иметь большое влияние на видимость сайта в обычном поиске, в зависимости от масштаба.Эти изменения часто могут повлиять на таксономию, навигацию и внутренние ссылки сайта.

Изменения в мобильной настройке

При таком большом количестве опций, доступных для мобильной настройки сайта, включение индексации приложений, создание сайта AMP или создание сайта PWA также можно рассматривать как частичную миграцию сайта, особенно когда существующий мобильный сайт заменяется приложением, AMP , или PWA.

Структурные изменения

Они часто вызваны серьезными изменениями в таксономии сайта, которые влияют на навигацию по сайту, внутренние ссылки и переходы пользователей.

Редизайн сайта

Они могут варьироваться от значительных изменений дизайна во внешнем виде и до полного обновления веб-сайта, которое также может включать значительные изменения в носителях, коде и копиях.

Гибридные миграции

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

Общие ошибки при переносе сайтов

Несмотря на то, что каждая миграция сайта отличается от других, наиболее типичные аварии, связанные с миграцией сайтов, связаны с несколькими общими темами, среди которых самые большие:

Плохая стратегия

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

Установление измеримых целей имеет важное значение для измерения воздействия миграции после запуска.Для большинства переносов сайтов основной целью должно быть сохранение текущего трафика и уровня доходов сайта. В некоторых случаях планка может быть поднята выше, но в целом ожидание или прогноз роста должно быть второстепенной задачей. Это поможет избежать создания нереалистичных ожиданий.

Плохое планирование

Составление подробного плана проекта как можно раньше поможет избежать задержек в процессе. Учитывайте дополнительное время и ресурсы, чтобы справиться с любыми непредвиденными обстоятельствами, которые могут возникнуть.Независимо от того, насколько хорошо продуман и детален ваш план, маловероятно, что все пойдет так, как ожидалось. Будьте гибкими со своим планом и примите тот факт, что задержки почти наверняка будут. Определите все зависимости и сообщите о них всем заинтересованным сторонам.

Не планируйте запуск сайта вблизи сезонных пиков, потому что, если что-то пойдет не так, у вас не будет достаточно времени, чтобы исправить проблемы. Например, розничным торговцам следует избегать открытия сайта ближе к сентябрю / октябрю, чтобы не подвергать риску напряженный предрождественский период.В этом случае было бы разумнее запускать в более спокойные летние месяцы.

Недостаток ресурсов

Прежде чем приступить к проекту миграции сайта, оцените время и усилия, необходимые для его успешного выполнения. Если ваш бюджет ограничен, спросите, стоит ли продолжать миграцию, которая, скорее всего, не сможет достичь поставленных целей и приведет к потере доходов.

Как правило, попробуйте включить буфер не менее 20% в дополнительный ресурс, чем вы изначально думаете, что потребуется проекту.Этот дополнительный буфер позже позволит вам быстро решать любые проблемы, как только они возникают, без ущерба для успеха. Если у вас слишком мало ресурсов или вы начнете срезать углы на этой ранней стадии, миграция сайта окажется под угрозой.

Отсутствие консультации по SEO / UX

Когда на веб-сайте происходят изменения, каждое решение необходимо взвешивать как с точки зрения UX, так и с точки зрения SEO. Например, удаление большого количества контента или ссылок для улучшения UX может повредить возможности сайта по нацеливанию на важные для бизнеса ключевые слова или привести к проблемам со сканированием и индексированием.В любом случае такие изменения могут повредить видимость сайта в обычных результатах поиска. С другой стороны, слишком много текста и мало изображений могут отрицательно повлиять на взаимодействие с пользователем и повлиять на конверсию сайта.

Чтобы избежать рисков, назначьте опытных консультантов по SEO и UX, чтобы они могли обсудить потенциальные последствия каждого отдельного изменения с ключевыми заинтересованными сторонами, которые разбираются в тонкостях бизнеса лучше, чем кто-либо другой. Прежде чем принимать какое-либо решение, необходимо взвесить плюсы и минусы каждого варианта.

Позднее участие

Миграция сайта может занять несколько месяцев, потребует тщательного планирования и достаточно времени для тестирования. Обратиться за профессиональной поддержкой с опозданием — очень рискованно, поскольку важные шаги могли быть пропущены.

Отсутствие тестирования

Помимо отличной стратегии и продуманного плана, перед запуском сайта выделите время и усилия на тщательное тестирование. Гораздо предпочтительнее отложить запуск, если тестирование выявило критические проблемы, а не спешить с отрывочной реализацией в производство.Само собой разумеется, что вам не следует запускать веб-сайт, если он не был протестирован как опытными командами SEO, так и командами UX.

Внимание к деталям тоже очень важно. Убедитесь, что разработчики полностью осознают риски, связанные с плохой реализацией. Информирование разработчиков о прямом влиянии их работы на посещаемость сайта (и, следовательно, доход) может иметь большое значение.

Медленный ответ на исправление ошибки

Когда новый сайт заработает, всегда будут ошибки, которые нужно исправить. Однако некоторые ошибки более важны, чем другие, и могут потребовать немедленного внимания. Например, запуск нового сайта только для того, чтобы обнаружить, что пауки поисковых систем не могут сканировать и индексировать контент сайта, потребует немедленного исправления. Медленное реагирование на серьезные технические препятствия иногда может иметь катастрофические последствия, и восстановление после них может занять много времени.

Шкала занижения

Заинтересованные стороны часто не ожидают, что миграция сайтов займет много времени и ресурсов.Старшие заинтересованные лица нередко требуют, чтобы новый сайт запускался в запланированный день, независимо от того, готов он на 100% или нет. Девиз «Запустим как можно скорее, потом исправим» — классическая ошибка. Большинство заинтересованных сторон не знают о том, что для очистки видимости органического поиска может потребоваться всего несколько дней, а восстановление может занять несколько месяцев.

Консультант и менеджер проекта обязаны обучать клиентов, проводить их через все этапы и сценарии и объяснять, что влечет за собой каждый из них. После этого заинтересованные стороны бизнеса смогут принимать более обоснованные решения, и их ожиданиями станет легче управлять.

Процесс миграции сайта

Процесс миграции сайта можно разделить на шесть основных этапов. Все они одинаково важны, и пропуск любой из перечисленных ниже задач может в разной степени помешать успешной миграции.

Этап 1: Объем и планирование

Разработать объем проекта

Независимо от причин, стоящих за проектом миграции сайта, вам необходимо с самого начала четко определить цели, потому что они помогут установить ожидания и управлять ими.Перемещение сайта с HTTP на HTTPS сильно отличается от полного пересмотра сайта, поэтому у них должны быть разные цели. В первом случае целью должно быть сохранение уровня посещаемости сайта, тогда как во втором вы потенциально можете стремиться к росту.

Миграция сайта — прекрасная возможность решить устаревшие проблемы. Включение как можно большего количества из них в объем проекта должно быть очень рентабельным, потому что решение этих проблем после запуска потребует значительно больше ресурсов.

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

Включение как можно большего числа заинтересованных сторон на этом раннем этапе поможет вам получить более глубокое понимание самых серьезных проблем и возможностей в разных подразделениях.Спросите мнение ваших специалистов по контенту, SEO, UX и аналитике и составьте список самых серьезных проблем и возможностей. Затем вам нужно выяснить, какой будет потенциальная рентабельность инвестиций при решении каждой из этих проблем. Наконец, выберите один из доступных вариантов в зависимости от ваших целей и доступных ресурсов, который сформирует стратегию миграции вашего сайта.

Теперь у вас должен остаться список приоритетных действий, которые, как ожидается, будут иметь положительную рентабельность инвестиций, если будут реализованы.Затем их следует сообщить и обсудить со всеми заинтересованными сторонами, чтобы вы установили реалистичные цели, согласовали проект, масштаб и с самого начала установили правильные ожидания.

Подготовить план проекта

Планирование не менее важно, потому что миграция сайта часто может быть очень сложным проектом, который легко может занять несколько месяцев. На этапе планирования каждой задаче нужен владелец (например, консультант по SEO, консультант по UX, редактор контента, веб-разработчик) и ожидаемая дата доставки.Любые зависимости должны быть идентифицированы и включены в план проекта, чтобы все знали о любых действиях, которые невозможно выполнить из-за зависимости от других. Например, перенаправления не могут быть протестированы, если отображение перенаправления не было завершено и перенаправления не были реализованы при постановке.

План проекта должен быть представлен всем участникам как можно раньше, чтобы было достаточно времени для обсуждения и разъяснений. Каждое мероприятие необходимо подробно описать, чтобы заинтересованные стороны знали, что влечет за собой выполнение каждой задачи.Само собой разумеется, что безупречное управление проектом необходимо для того, чтобы организовать и провести необходимые мероприятия в соответствии с графиком.

Важнейшей частью плана проекта является определение предполагаемой даты запуска. В идеале новый сайт должен запускаться в то время, когда посещаемость низкая. Опять же, избегайте запусков до или во время пикового периода, потому что последствия могут быть разрушительными, если все пойдет не так, как ожидалось. Следует иметь в виду, что, поскольку миграция сайтов никогда не идет полностью по плану, потребуется определенная степень гибкости.

Этап 2: Предпусковая подготовка

Сюда входят любые действия, которые необходимо выполнить, пока новый сайт все еще находится в стадии разработки. К этому моменту требования к SEO для нового сайта уже должны были быть учтены. Вы должны поддерживать связь с дизайнерами и информационными архитекторами, обеспечивая обратную связь по прототипам и каркасам задолго до того, как новый сайт станет доступным в промежуточной среде.
Обзор
Wireframes

Перед началом разработки проверьте прототипы или макеты нового сайта.Обзор основных шаблонов нового сайта может помочь выявить проблемы как с поисковой оптимизацией, так и с UX на ранней стадии. Например, вы можете обнаружить, что со страниц категорий были удалены большие части контента, которые должны быть немедленно помечены. Или вы можете обнаружить, что некоторые страницы с высокой посещаемостью больше не отображаются в основной навигации. Любые радикальные изменения в дизайне или копии страниц должны быть тщательно проверены на предмет потенциальных проблем с поисковой оптимизацией.

Подготовка технических спецификаций SEO

После проверки прототипов и каркасов подготовьте подробную техническую спецификацию SEO. Цель этого жизненно важного документа состоит в том, чтобы зафиксировать все основные требования к SEO, о которых необходимо знать разработчикам, прежде чем определять объем проекта с точки зрения работ и затрат. Именно на этом этапе утверждаются бюджеты; если требования к SEO не включены, возможно, будет невозможно включить их позже.

Техническая спецификация SEO должна быть очень подробной, но при этом написанной таким образом, чтобы разработчики могли легко превратить требования в действия.Это не документ, объясняющий , почему необходимо реализовать что-то , а , как это должно быть реализовано.

Обязательно включите особые требования, которые охватывают как минимум следующие области:

Структура URL

Метаданные (включая динамически генерируемые значения по умолчанию)

Структурированные данные

Канонические директивы и мета-роботы

Копии и заголовки

Основная и дополнительная навигация

Внутренняя перелинковка (в любой форме)

Пагинация

XML карта (и) сайта

HTML карта сайта

Hreflang (если есть международные сайты)

Мобильная установка (включая приложение, AMP или сайт PWA)

Перенаправляет

На заказ 404 стр.

JavaScript, CSS и файлы изображений

Время загрузки страницы (для ПК и мобильных устройств)

В спецификацию также должны быть включены области функциональности CMS, которые позволяют пользователям:

Укажите настраиваемые URL-адреса и замените их по умолчанию

Обновить заголовки страниц

Обновить метаописания

Обновить любые заголовки h2 – h6

Добавить или изменить канонический тег по умолчанию

Установите для атрибутов мета-роботов index / noindex / follow / nofollow

Добавить или отредактировать замещающий текст для каждого изображения

Включить поля Open Graph для описания, URL, изображения, типа, имени сайта

Включить поля Twitter Open Graph для карточки, URL, заголовка, описания, изображения

Массовая загрузка или изменение переадресации

Обновите файл robots.txt файл

Также важно убедиться, что при обновлении определенного атрибута (например, h2) не затрагиваются другие элементы (например, заголовок страницы или какие-либо навигационные меню).

Определение приоритетных страниц

Одна из самых больших проблем, связанных с миграцией сайтов, заключается в том, что успех во многом будет зависеть от количества и качества перенесенных страниц. Поэтому очень важно сосредоточиться на действительно важных страницах.Это страницы, которые привлекают трафик на унаследованный сайт, страницы с накопленными ссылками, страницы с хорошей конверсией и т. Д.

Для этого вам необходимо:

Сканирование устаревшего сайта

Определить все индексируемые страницы

Определите наиболее эффективные страницы

Как сканировать старый сайт

Сканируйте старый веб-сайт, чтобы у вас были копии всех URL-адресов, заголовков страниц, метаданных, заголовков, перенаправлений, неработающих ссылок и т. Д.Независимо от выбранного приложения-краулера (см. Приложение), убедитесь, что сканирование не слишком ограничительное. Перед сканированием старого сайта обратите особое внимание на настройки сканера и подумайте, следует ли вам:

Игнорировать robots. txt (в случае, если какие-либо важные части случайно заблокированы)

Переходите по внутренним ссылкам «nofollow» (чтобы сканер просматривал больше страниц)

Сканировать все субдомены (в зависимости от области)

Обход вне начальной папки (в зависимости от области)

Измените пользовательский агент на Googlebot (рабочий стол)

Измените пользовательский агент на Googlebot (смартфон)

Совет для профессионалов: храните копию данных сканирования старого сайта (в файле или в облаке) в течение нескольких месяцев после завершения миграции, на случай, если вам когда-нибудь понадобятся какие-либо данные старого сайта после того, как новый сайт будет ушел жить.

Как определить индексируемые страницы

После завершения сканирования работайте над определением проиндексированных страниц устаревшего сайта. Это любые HTML-страницы со следующими характеристиками:

Вернуть ответ сервера 200

Либо у вас нет канонического тега, либо у вас есть канонический URL-адрес со ссылкой на себя.

Нет мета-роботов noindex

Не исключены из файла robots.txt

Есть внутренние ссылки с других страниц (несиротские страницы)

Индексируемые страницы — это единственные страницы, которые могут привлекать трафик на сайт и, следовательно, должны иметь приоритет для целей миграции вашего сайта.Это те страницы, которые стоит оптимизировать (если они будут существовать на новом сайте) или перенаправить (если они не будут существовать на новом сайте).

Как определить самые эффективные страницы

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

В этом случае следует определить наиболее эффективные страницы старого сайта.Это поможет расставить приоритеты для страниц, на которых нужно сосредоточиться на более поздних этапах.

Рекомендуется подготовить электронную таблицу, содержащую следующие поля:

Устаревший URL (включая только индексируемые из данных сканирования)

Органические посещения за последние 12 месяцев (Аналитика)

Доход, конверсии и коэффициент конверсии за последние 12 месяцев (Аналитика)

просмотров страниц за последние 12 месяцев (Аналитика)

Количество кликов за последние 90 дней (Search Console)

Самые популярные страницы (Majestic SEO / Ahrefs)

С приведенной выше информацией в одном месте теперь намного проще идентифицировать ваши самые важные страницы: те, которые генерируют обычные посещения, хорошо конвертируются, вносят вклад в доход, имеют большое количество ссылающихся доменов, ссылающихся на них, и т. Д.Это страницы, на которых вы должны сосредоточиться для успешной миграции сайта.

В идеале самые эффективные страницы также должны существовать на новом сайте. Если по какой-либо причине они этого не сделают, их следует перенаправить на наиболее релевантную страницу, чтобы пользователи, запрашивающие их, не попадали на страницы 404, а количество ссылок, которые у них были ранее, оставалось на сайте. Если какая-либо из этих страниц перестанет существовать и не будет правильно перенаправлена, это отрицательно скажется на рейтинге и посещаемости вашего сайта.

Бенчмаркинг

Как только запуск нового веб-сайта приближается, вам следует сравнить производительность старого сайта.Бенчмаркинг необходим не только для сравнения эффективности нового сайта с предыдущим, но и для определения того, какие области на новом сайте неэффективны, и для быстрого их устранения.

Отслеживание рейтинга ключевых слов

Если вы не часто отслеживаете рейтинг сайта, вам следует делать это непосредственно перед тем, как новый сайт будет запущен. В противном случае вам позже будет сложно понять, прошла ли миграция гладко или где именно что-то пошло не так. Не откладывайте это на последнюю минуту, если что-то пойдет не так — за неделю было бы идеальным временем.

Потратьте некоторое время на то, чтобы выяснить, какие ключевые слова наиболее отражают видимость сайта в обычном поиске, и отследите их на настольных и мобильных устройствах. Поскольку отслеживать тысячи комбинаций ключевых слов в начале, середине и конце, как правило, нереально, минимум, который вы должны отслеживать, — это ключевые слова, которые привлекают трафик на сайт (ключевые слова ранжируются на первой странице) и имеют приличный объем поиска (заголовок / середина -хвост фокус)

Если вы получаете трафик как от брендовых, так и от небрендовых ключевых слов, вам также следует решить, на какие ключевые слова следует сосредоточить больше внимания при отслеживании POV.В целом, ключевые слова, не относящиеся к бренду, обычно более конкурентоспособны и изменчивы. Для большинства сайтов имеет смысл сосредоточиться в основном на них.

Не забывайте отслеживать рейтинги на компьютерах и мобильных устройствах. Это значительно упростит диагностику проблем после запуска, если возникнут проблемы с производительностью на одном типе устройств. Если вы получаете большой объем трафика из более чем одной страны, рассмотрите возможность использования ключевых слов для отслеживания рейтинга и на других рынках, потому что видимость и рейтинг могут значительно различаться от страны к стране.

Производительность сайта

Время загрузки страницы нового сайта может иметь большое влияние как на посещаемость, так и на продажи. Несколько исследований показали, что чем дольше загружается страница, тем выше показатель отказов. Если время загрузки страницы старого сайта и оценка его производительности не были записаны, будет очень сложно связать любой трафик или потерю дохода с проблемами, связанными с производительностью сайта, после того, как новый сайт будет запущен.

Рекомендуется просмотреть все основные типы страниц с помощью инструментов Google PageSpeed Insights и Lighthouse.Вы можете использовать сводные таблицы, подобные приведенным ниже, для сравнения некоторых из наиболее важных показателей производительности, которые будут полезны для сравнений после запуска нового сайта.

МОБИЛЬНЫЙ

Скорость

FCP

DCL

Оптимизация

Оценка оптимизации

Домашняя страница

Быстро

0. 7 с

1,4 с

Хорошо

81/100

Страница категории

Медленно

1,8 с

5,1 с

Средний

78/100

Страница подкатегории

Среднее

0.9 с

2,4 с

Средний

69/100

Страница продукта

Медленно

1,9 с

5,5 с

Хорошо

83/100

НАСТОЛЬНЫЙ СТОЛ

Скорость

FCP

DCL

Оптимизация

Оценка оптимизации

Домашняя страница

Хорошо

0. 7 с

1,4 с

Среднее

81/100

Страница категории

Быстро

0,6 с

1,2 с

Средний

78/100

Страница подкатегории

Быстро

0.6 с

1,3 с

Средний

78/100

Страница продукта

Хорошо

0,8 с

1,3 с

Хорошо

83/100

Данные сканирования старого сайта

За несколько дней до того, как новый сайт заменит старый, запустите последнее сканирование старого сайта.Это впоследствии может оказаться бесценным, если на новом сайте возникнут проблемы с оптимизацией. Окончательное сканирование позволит вам сохранить важную информацию о заголовках страниц старого сайта, метаописаниях, заголовках h2 – h6, статусе сервера, канонических тегах, страницах noindex / nofollow, входящих / исходящих ссылках, уровне и т. Д. Наличие всей этой информации может избавит вас от множества проблем, если, скажем, новый сайт плохо оптимизирован или имеет проблемы с технической неправильной конфигурацией. Также попробуйте сохранить копию файла robots.txt и XML карты сайта на случай, если они понадобятся позже.

Данные Search Console

Также рекомендуется экспортировать как можно больше данных из Search Console со старого сайта. Они доступны только в течение 90 дней, и есть вероятность, что после запуска нового сайта данные Search Console старого сайта рано или поздно исчезнут. Данные, которые стоит экспортировать, включают:

Поисковая аналитика запросов и страниц

Ошибки сканирования

Заблокированные ресурсы

Проблемы с удобством использования мобильных устройств

Параметры URL

Ошибки структурированных данных

Ссылки на ваш сайт

Внутренние ссылки

Статус индекса

Подготовка редиректов

Реализация перенаправления — одно из наиболее важных действий во время миграции сайта. Если URL-адреса старого сайта перестанут существовать и не будут правильно перенаправлены, рейтинг и видимость сайта просто упадут.

Почему редиректы важны при миграции сайтов?
Перенаправления
чрезвычайно важны, потому что они помогают поисковым системам и пользователям находить страницы, которые больше не существуют, были переименованы или перемещены в другое место. С точки зрения поисковой оптимизации, переадресация помогает поисковым системам быстрее обнаруживать и индексировать новые URL-адреса сайта, а также понимать, как страницы старого сайта связаны со страницами нового сайта.Эта ассоциация позволит передавать сигналы ранжирования со старых страниц на новые, так что ранжирование сохраняется без отрицательного воздействия.

Что происходит, если переадресация не выполняется правильно?

Если перенаправления реализованы некачественно, последствия могут быть катастрофическими. Пользователи будут либо попадать на страницы Not Found (404), либо на нерелевантные страницы, которые не соответствуют намерениям пользователя. В любом случае это отрицательно скажется на показателях отказов и конверсии сайта.Последствия для поисковых систем могут быть столь же катастрофическими: они не смогут связать страницы старого сайта со страницами нового сайта, если URL-адреса не совпадают. Сигналы ранжирования не будут передаваться со старого сайта на новый, что приведет к снижению рейтинга и потере видимости в обычном поиске. Кроме того, поисковым системам потребуется больше времени, чтобы обнаружить и проиндексировать страницы нового сайта.

301, 302, перенаправление JavaScript или мета-обновление?

Если URL-адреса между старой и новой версиями сайта различаются, используйте 301 (постоянное) перенаправление.Они укажут поисковым системам индексировать новые URL-адреса, а также перенаправить любые сигналы ранжирования со старых URL-адресов на новые. Следовательно, вы должны использовать 301 редирект, если ваш сайт перемещается в / из другого домена / поддомена, если вы переключаетесь с HTTP на HTTPS или если сайт или его части были реструктурированы. Несмотря на некоторые утверждения Google о том, что переадресация 302 проходит через PageRank, индексация новых URL-адресов будет медленнее, а передача сигналов ранжирования со старой на новую страницу может занять гораздо больше времени.

302 (временные) переадресации следует использовать только в тех случаях, когда переадресация не должна существовать постоянно и, следовательно, индексирование нового URL не является приоритетом.При переадресации 302 поисковые системы сначала будут неохотно индексировать содержимое URL-адреса назначения переадресации и передавать ему какие-либо сигналы ранжирования. Однако, если временные перенаправления остаются в течение длительного периода времени без удаления или обновления, они могут в конечном итоге вести себя так же, как постоянные (301) перенаправления. Используйте переадресацию 302, когда переадресация может потребовать обновления или удаления в ближайшем будущем, а также для любых переадресаций, зависящих от страны, языка или устройства.

Следует избегать мета-обновления и перенаправления JavaScript.Несмотря на то, что Google все лучше и лучше сканирует JavaScript, нет никаких гарантий, что он будет обнаружен или передаст сигналы ранжирования новым страницам.

Если вы хотите узнать больше о том, как Google борется с различными типами переадресации, прочтите сообщение Джона Мюллера.

Процесс отображения перенаправления

Если вам посчастливилось работать над миграцией, не связанной с изменением URL, вы можете пропустить этот раздел. В противном случае читайте дальше, чтобы узнать, почему любые устаревшие страницы, которые не будут доступны по тому же URL-адресу после миграции, должны быть перенаправлены.

Файл сопоставления перенаправления — это электронная таблица, которая включает следующие два столбца:

URL старого сайта -> URL страницы на старом сайте.

URL нового сайта -> URL страницы на новом сайте.

При отображении (перенаправлении) страницы со старого сайта на новый всегда пытайтесь сопоставить ее с наиболее релевантной соответствующей страницей. В случаях, когда релевантной страницы не существует, избегайте перенаправления страницы на главную. Прежде всего, перенаправление пользователей на нерелевантные страницы приводит к очень плохому взаимодействию с пользователем.Google заявил, что «массовое» перенаправление страниц на нерелевантные страницы будет рассматриваться как «мягкие» 404 и поэтому не будет передавать никакой SEO-ценности. Если вы не можете найти эквивалентную страницу на новом сайте, попробуйте сопоставить ее со страницей родительской категории.

После завершения сопоставления файл необходимо будет отправить группе разработчиков для создания перенаправлений, чтобы их можно было протестировать перед запуском нового сайта. Реализация переадресации — еще одна часть цикла миграции сайта, когда что-то может пойти не так.

Повышение эффективности процесса сопоставления перенаправления Сопоставление перенаправления
требует большого внимания к деталям и должно выполняться опытными специалистами по поисковой оптимизации. Сопоставление URL-адресов на небольших сайтах теоретически может быть выполнено путем ручного сопоставления каждого URL-адреса старого сайта с URL-адресом на новом сайте. Но на крупных сайтах, которые состоят из тысяч или даже сотен тысяч страниц, сопоставление каждого URL вручную практически невозможно, и необходимо ввести автоматизацию.Использование определенных общих атрибутов старого и нового сайта может значительно сэкономить время. Такие атрибуты могут включать в себя заголовки страниц, заголовки h2 или другие уникальные идентификаторы страниц, такие как коды продуктов, SKU и т. Д. Убедитесь, что атрибуты, на которые вы полагаетесь при сопоставлении перенаправления, уникальны и не повторяются на нескольких страницах; в противном случае вы получите неправильное сопоставление.
Совет
Pro: убедитесь, что структура URL нового сайта на 100% завершена на стадии подготовки, прежде чем начинать работу над сопоставлением перенаправления.Нет ничего более рискованного, чем сопоставление URL-адресов, которые будут обновлены перед запуском нового сайта. Когда URL-адреса обновляются после завершения сопоставления перенаправления, вам, возможно, придется иметь дело с нежелательными ситуациями при запуске, такими как неработающие перенаправления, цепочки перенаправления и циклы перенаправления. Замораживание контента должно быть размещено на старом сайте задолго до даты миграции, чтобы на старом сайте была точка отсечения для публикации нового контента. Это гарантирует, что ни одна страница не будет пропущена при сопоставлении перенаправления, и гарантирует, что все страницы на старом сайте будут перенаправлены.

Не забывайте устаревшие переадресации!
Вам следует воспользоваться существующими переадресациями старого сайта, чтобы убедиться, что они учтены при подготовке сопоставления переадресации для нового сайта. Если вы этого не сделаете, вероятно, что текущий файл перенаправления сайта будет заменен новым в день запуска. Если это произойдет, все устаревшие перенаправления, которые были ранее применены, перестанут существовать, и сайт может потерять приличную долю ссылочного капитала, степень которого будет во многом зависеть от объема старых перенаправлений на сайте. Например, сайт, который в прошлом претерпел несколько миграций, должен иметь большое количество устаревших перенаправлений, которые вы не хотите терять.

В идеале следует сохранить как можно больше устаревших переадресаций, чтобы они не вызывали никаких проблем в сочетании с переадресациями нового сайта. Настоятельно рекомендуется исключить любые потенциальные цепочки переадресации на этом раннем этапе, что можно легко сделать, проверив, отображается ли один и тот же URL как «Старый URL» и «Новый URL-адрес сайта» в электронной таблице сопоставления переадресации.В этом случае вам необходимо будет соответствующим образом обновить «URL-адрес нового сайта».

Пример:

URL A перенаправляет на URL B (устаревшее перенаправление)

URL B перенаправляет на URL C (новое перенаправление)

В результате получается следующая цепочка переадресации:

URL A -> URL B -> URL C

Чтобы устранить это, измените существующее устаревшее перенаправление и создайте новое, чтобы:

URL A перенаправляет на URL C (измененное устаревшее перенаправление)

URL B перенаправляет на URL C (новое перенаправление)

Совет от профессионалов: Проверьте свою электронную таблицу отображения перенаправления на наличие петель перенаправления. Это происходит, когда «Устаревший URL» идентичен «URL нового сайта». Циклы перенаправления необходимо удалить, поскольку они приводят к бесконечной загрузке страниц, недоступных для пользователей и поисковых систем. Петли перенаправления должны быть устранены, потому что они мгновенно убивают трафик, конверсию и ранжирование!

Реализуйте общие правила перенаправления, чтобы избежать дублирования контента

Настоятельно рекомендуется попробовать разработать правила переадресации, охватывающие как можно больше URL-запросов.Реализация правил перенаправления на веб-сервере намного эффективнее, чем полагаться на многочисленные однозначные перенаправления. Если ваш документ сопоставления перенаправления состоит из очень большого количества перенаправлений, которые необходимо реализовать как правила перенаправления «один-к-одному», производительность сайта может снизиться. В любом случае дважды проверьте с командой разработчиков максимальное количество перенаправлений, которое веб-сервер может обработать без проблем.

В любом случае, должны быть некоторые стандартные правила перенаправления, чтобы избежать дублирования контента:

Даже если некоторые из этих стандартных правил перенаправления существуют на старом веб-сайте, не предполагайте, что они обязательно будут существовать на новом сайте, если они не запрашиваются явным образом.

Избегайте внутренних перенаправлений

Попробуйте обновить внутренние ссылки сайта, чтобы они не вызывали внутренние переадресации. Несмотря на то, что поисковые системы могут следовать внутренним перенаправлениям, это не рекомендуется, поскольку они увеличивают время загрузки страницы и могут отрицательно повлиять на время сканирования поисковой системой.

Не забывайте файлы изображений

Если изображения с сайта переместились в новое место, Google рекомендует перенаправить URL-адреса старых изображений на URL-адреса новых изображений, чтобы помочь Google быстрее обнаруживать и индексировать новые изображения. Если перенаправить все изображения непросто, постарайтесь перенаправить хотя бы те URL-адреса изображений, на которые есть обратные ссылки.

Этап 3: Предпусковые испытания

Чем раньше вы начнете тестирование, тем лучше. Некоторые вещи необходимо полностью реализовать для тестирования, а другие — нет. Например, проблемы взаимодействия с пользователем могут быть выявлены уже на этапе разработки прототипов или каркасов. Связанные с контентом проблемы между старым и новым сайтом или несоответствия контента (например, между настольным и мобильным сайтом) также могут быть выявлены на ранней стадии.Но более технические компоненты следует тестировать только после полной реализации — такие как перенаправления, канонические теги или карты сайта XML. Чем раньше будут выявлены проблемы, тем больше вероятность того, что они будут устранены до запуска нового сайта. Выявление определенных типов проблем на более позднем этапе нерентабельно, потребует дополнительных ресурсов и приведет к значительным задержкам. Плохое тестирование и отсутствие времени, необходимого для тщательного тестирования всех строительных блоков, которые могут повлиять на производительность SEO и UX, могут иметь катастрофические последствия вскоре после запуска нового сайта.

Убедитесь, что поисковые системы не могут получить доступ к промежуточному / испытательному сайту

Перед тем, как сделать новый сайт доступным в тестовой среде, примите некоторые меры, чтобы поисковые системы не индексировали его. Есть несколько способов сделать это, каждый из которых имеет свои плюсы и минусы.

Сайт доступен для определенных IP-адресов
(наиболее рекомендуется)
Сделать тестовый сайт доступным только для определенных (занесенных в белый список) IP-адресов — очень эффективный способ предотвратить его сканирование поисковыми системами.Любой, кто попытается получить доступ к URL-адресу тестового сайта, не сможет увидеть какой-либо контент, если его IP-адрес не будет внесен в белый список. Основным преимуществом является то, что пользователи из белого списка могут легко получить доступ к сайту и сканировать его без каких-либо проблем. Единственным недостатком является то, что сторонние веб-инструменты (например, инструменты Google) нельзя использовать из-за ограничений IP.

Защита паролем

Защита паролем промежуточного / тестового сайта — еще один способ отпугнуть роботов поисковых систем, но у этого решения есть два основных недостатка.В зависимости от реализации может оказаться невозможным сканирование и тестирование веб-сайта, защищенного паролем, если приложение-сканер не проходит через экран входа в систему. Другой недостаток: защищенные паролем веб-сайты, использующие формы для аутентификации, можно сканировать с помощью сторонних приложений, но существует риск возникновения серьезных и неожиданных проблем. Это связано с тем, что сканер нажимает на каждую ссылку на странице (когда вы вошли в систему) и может легко перейти по ссылкам, которые создают или удаляют страницы, устанавливают / удаляют плагины и т. Д.

Блокировка Robots.txt

Добавление следующих строк кода в файл robots.txt тестового сайта предотвратит сканирование страниц тестового сайта поисковыми системами.

Агент пользователя: * Запретить: /

Один из недостатков этого метода заключается в том, что даже если контент, отображаемый на тестовом сервере, не будет проиндексирован, запрещенные URL-адреса могут появиться в результатах поиска Google. Еще одним недостатком является то, что если указанный выше файл robots.txt перемещается на действующий сайт, это вызовет серьезные проблемы с деиндексированием.Я сталкивался с этим много раз, и по этой причине я бы не рекомендовал использовать этот метод для блокировки поисковых систем.

Обзор пути пользователя

Если сайт был переработан или реструктурирован, есть вероятность, что это в какой-то мере повлияет на пути пользователя. Анализ пути пользователя как можно раньше и задолго до запуска нового сайта затруднен из-за отсутствия пользовательских данных. Однако опытный UX-профессионал сможет указать на любые проблемы, которые могут негативно повлиять на коэффициент конверсии сайта.Поскольку A / B-тестирование на этом этапе практически невозможно, возможно, стоит провести некоторое пользовательское тестирование и попытаться получить отзывы от реальных пользователей. К сожалению, проблемы взаимодействия с пользователем могут быть одними из самых сложных, потому что они могут потребовать глобальных изменений, требующих много времени и усилий.

При полном ремонте сайта не все решения UX всегда можно подкрепить данными, и многие решения должны будут основываться на передовой практике, прошлом опыте и «интуиции», поэтому вовлечение экспертов UX / CRO может быть осуществлено как можно раньше. выплатить дивиденды позже.

Обзор архитектуры сайта

Миграция сайта часто является отличной возможностью улучшить архитектуру сайта. Другими словами, у вас есть отличный шанс реорганизовать контент, ориентированный на ключевые слова, и максимально увеличить его потенциал поискового трафика. Проведение обширного исследования ключевых слов поможет определить наиболее подходящие страницы категорий и подкатегорий, чтобы пользователи и поисковые системы могли перейти на любую страницу сайта за несколько кликов — чем меньше, тем лучше, поэтому вы не получите очень глубокого таксономия.

Определение новых ключевых слов с приличным потенциалом трафика и сопоставление их с новыми целевыми страницами может иметь большое значение для уровня органического трафика сайта. С другой стороны, улучшение архитектуры сайта нужно делать вдумчиво. Это может вызвать проблемы, если, скажем, важные страницы углубятся в новую архитектуру сайта или будет слишком много похожих страниц, оптимизированных для тех же ключевых слов. Некоторые из наиболее успешных миграций сайтов — это те, при которых выделяются значительные ресурсы для улучшения архитектуры сайта.

Обзор метаданных и копий

Убедитесь, что заголовки страниц, метаописания, заголовки и текст без проблем перенесены со старого сайта на новый. Если вы создали какие-либо новые страницы, убедитесь, что они оптимизированы и не нацелены на ключевые слова, которые уже использовались другими страницами. Если вы повторно выполняете переход на новую платформу, имейте в виду, что новая платформа может иметь другие значения по умолчанию при создании новых страниц. Запуск нового сайта без должным образом оптимизированных заголовков страниц или какой-либо отсутствующей копии немедленно окажет негативное влияние на рейтинг вашего сайта и посещаемость.Не забудьте проверить, был ли загружен какой-либо пользовательский контент (например, отзывы пользователей, комментарии).

Проверка внутренних ссылок

Внутренние ссылки являются основой веб-сайта. Независимо от того, насколько хорошо оптимизирована и структурирована копия сайта, для успеха ее будет недостаточно, если она не будет поддержана безупречной внутренней схемой ссылок. Внутренние ссылки необходимо просматривать на всем сайте, включая ссылки, найденные в:

Главная и дополнительная навигация

Ссылки верхнего и нижнего колонтитулов

Ссылки на содержимое тела

Ссылки на страницы

Горизонтальные ссылки (похожие статьи, похожие товары и т. Д.)

Вертикальные звенья (например,грамм. Навигация по хлебным крошкам)

Межсайтовые ссылки (например, ссылки на международные сайты)

Технические проверки

Необходимо провести серию технических проверок, чтобы убедиться, что техническая настройка нового сайта исправна, и чтобы избежать серьезных технических сбоев после запуска нового сайта.

Обзор файла Robots.txt

Подготовьте файл robots.txt нового сайта в тестовой среде. Таким образом, вы можете проверить его на наличие ошибок или упущений и избежать проблем со сканированием поисковыми системами при запуске нового сайта.Классическая ошибка при переносе сайта — это когда файл robots.txt запрещает доступ поисковой системе с помощью следующей директивы:

Disallow: /

Если это случайно переносится на действующий сайт (а это часто бывает), это предотвратит сканирование сайта поисковыми системами. И когда поисковые системы не могут сканировать проиндексированную страницу, ключевые слова, связанные со страницей, будут понижены в результатах поиска, и в конечном итоге страница будет деиндексирована.

Но если файл robots.txt при постановке заполняется директивами robots.txt нового сайта, этой неприятности можно было бы избежать.

При подготовке файла robots.txt для нового сайта убедитесь, что:

Не блокирует доступ поисковой системы к страницам, предназначенным для индексации.

Он не блокирует ресурсы JavaScript или CSS, необходимые поисковым системам для отображения содержимого страницы.

Содержание файла robots.txt устаревшего сайта было проверено и при необходимости перенесено.

Он ссылается на новые карты сайта XML, а не на устаревшие, которые больше не существуют.

Canonical tags обзор

Проверьте канонические теги сайта. Найдите страницы, которые либо не имеют канонического тега, либо имеют канонический тег, указывающий на другой URL-адрес, и задайте вопрос, предназначено ли это. Не забудьте просканировать канонические теги, чтобы узнать, возвращают ли они ответ сервера 200. В противном случае вам нужно будет обновить их, чтобы исключить все ответы сервера 3xx, 4xx или 5xx. Вам также следует искать страницы, на которых канонический тег указывает на другой URL в сочетании с директивой noindex, потому что эти два сигнала являются конфликтующими, и вам нужно будет удалить один из них.

Обзор Meta robots

После сканирования промежуточного сайта найдите страницы, для которых в свойствах мета-роботов установлено значение «noindex» или «nofollow». В этом случае просмотрите каждый из них, чтобы убедиться, что это сделано намеренно, и удалите директиву noindex или nofollow, если это не так.

Обзор XML-карт сайта

Подготовьте два разных типа файлов Sitemap: одну, которая содержит все индексируемые страницы нового сайта, а другую — все индексируемые страницы старого сайта. Первый из них поможет Google узнать об индексируемых URL-адресах нового сайта. Последнее поможет Google узнать об имеющихся перенаправлениях и о том, что некоторые из проиндексированных URL-адресов переместились в новые места, чтобы он мог их обнаруживать и быстрее обновлять результаты поиска.

Вы должны проверить каждую карту сайта XML, чтобы убедиться, что:

Проверяет без проблем

Он закодирован как UTF-8

Не более 50000 строк

Его размер не превышает 50 МБ в несжатом виде

Если имеется более 50 КБ строк или размер файла превышает 50 МБ, необходимо разбить карту сайта на более мелкие.Это предотвращает перегрузку сервера, если Google слишком часто запрашивает карту сайта.

Кроме того, вы должны сканировать каждую XML-карту сайта, чтобы убедиться, что она включает только индексируемые URL. Любые неиндексируемые URL-адреса должны быть исключены из карт сайта XML, например:

Страницы 3xx, 4xx и 5xx (например, перенаправленные, ненайденные страницы, неверные запросы и т. Д.)

Мягкие 404с. Это страницы без содержимого, которые возвращают ответ сервера 200 вместо 404.

Канонизированные страницы (кроме самонаводящихся канонических URL)

Страницы с директивой noindex мета-роботов

(…) (…)

Страницы с тегом noindex X-Robots-Tag в заголовке HTTP

HTTP / 1. 1 200 ОК Дата: вт, 10 ноября 2017 г., 17:12:43 GMT (…) X-Robots-Tag: noindex (…)

Страницы заблокированы для роботов.txt файл

Создание чистых XML-карт сайта может помочь отслеживать истинные уровни индексации нового сайта после его запуска. Если вы этого не сделаете, будет очень сложно обнаружить какие-либо проблемы с индексированием.

Совет для профессионалов: Загрузите и откройте каждую XML-карту сайта в Excel, чтобы получить подробный обзор любых дополнительных атрибутов, таких как атрибуты hreflang или изображения.

HTML карта сайта обзор

В зависимости от размера и типа переносимого сайта в некоторых случаях может быть полезным наличие карты сайта в формате HTML.Карта сайта в формате HTML, состоящая из URL-адресов, на которые нет ссылок из основной навигации сайта, может значительно ускорить обнаружение и индексирование страниц. Однако избегайте создания карты сайта HTML, содержащей слишком много URL-адресов. Если вам действительно нужно включить тысячи URL-адресов, подумайте о создании сегментированной карты сайта HTML.

Количество вложенных карт сайта, а также максимальное количество URL-адресов, которые следует включать в каждую карту сайта, зависит от авторитета сайта. Чем авторитетнее веб-сайт, тем большее количество вложенных карт сайта и URL-адресов он может использовать.

Например, карта сайта NYTimes.com HTML состоит из трех уровней, каждый из которых включает более 1000 URL-адресов на карту сайта. Эти вложенные карты сайта HTML помогают сканерам поисковых систем находить статьи, опубликованные с 1851 года, которые в противном случае было бы трудно обнаружить и проиндексировать, поскольку не все из них были бы связаны внутренними ссылками.

Карта сайта NYTimes HTML (уровень 1)

Карта сайта NYTimes HTML (уровень 2)

Обзор структурированных данных

Ошибки в разметке структурированных данных необходимо выявлять заранее, чтобы было время исправить их, прежде чем новый сайт будет запущен. В идеале вам следует тестировать каждый шаблон страницы (а не каждую страницу) с помощью инструмента проверки структурированных данных Google.

Обязательно проверьте разметку как на настольных, так и на мобильных страницах, особенно если мобильный веб-сайт не реагирует.

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

Самые последние сведения о реализации структурированных данных и поддерживаемых типах контента см. В документации Google.

Проверка сканирования JavaScript

Вы должны протестировать каждый шаблон страницы нового сайта, чтобы убедиться, что Google сможет сканировать контент, требующий синтаксического анализа JavaScript. Если вы можете использовать инструмент Google Fetch and Render на своем тестовом сайте, вам обязательно стоит это сделать. В противном случае выполните несколько тестов вручную, следуя совету Джастина Бригга.

Как показали тесты Бартоша Горалевича, даже если Google может сканировать и индексировать контент, созданный с помощью JavaScript, это не означает, что он может сканировать контент JavaScript во всех основных средах JavaScript. В следующей таблице обобщены выводы Бартоша, показывающие, что некоторые фреймворки JavaScript не оптимизированы для SEO, при этом AngularJS в настоящее время является наиболее проблематичным из всех.

Бартош также обнаружил, что другие поисковые системы (такие как Bing, Yandex и Baidu) действительно испытывают трудности с индексированием содержимого, созданного с помощью JavaScript, что важно знать, зависит ли трафик вашего сайта от какой-либо из этих поисковых систем.

Будем надеяться, что со временем это будет улучшаться, но с ростом популярности фреймворков JavaScript в веб-разработке это должно быть высоко в вашем контрольном списке.

Наконец, вы должны проверить, не блокируются ли какие-либо внешние ресурсы. К сожалению, это не то, что вы можете контролировать на 100%, потому что многие ресурсы (такие как файлы JavaScript и CSS) размещаются на сторонних веб-сайтах, которые могут блокировать их через свои собственные файлы robots.txt!

Опять же, инструмент «Выборка и рендеринг» может помочь диагностировать проблемы этого типа, которые, если их не решить, могут иметь серьезные негативные последствия.

SEO-проверка мобильного сайта

Проверка блокировки активов

Во-первых, убедитесь, что файл robots.txt не блокирует случайно любые файлы JavaScript, CSS или изображений, которые необходимы для отображения содержания мобильного сайта. Это может отрицательно повлиять на то, как поисковые системы обрабатывают и индексируют содержание страницы мобильного сайта, что, в свою очередь, может отрицательно сказаться на видимости и эффективности мобильного сайта в поиске.

Обзор Mobile-first index

Чтобы избежать проблем, связанных с индексом Google для мобильных устройств, тщательно просмотрите веб-сайт для мобильных устройств и убедитесь в отсутствии несоответствий между сайтами для компьютеров и мобильных устройств в следующих областях:

Заголовки страниц

Метаописания

Товаров

Копия

Канонические теги

Мета атрибуты роботов (т. е. noindex, nofollow)

Внутренние ссылки

Структурированные данные

Адаптивный веб-сайт должен обслуживать один и тот же контент, ссылки и разметку на разных устройствах, а указанные выше атрибуты SEO должны быть идентичными для настольных и мобильных веб-сайтов.

В дополнение к вышеизложенному вам необходимо выполнить еще несколько технических проверок в зависимости от настройки мобильного сайта.

Отзывчивый отзыв сайта
Адаптивный веб-сайт должен обслуживать все устройства одним и тем же кодом HTML, который настраивается (с помощью CSS) в зависимости от размера экрана.

Робот Googlebot может автоматически обнаруживать эту мобильную настройку, если ему разрешено сканировать страницу и ее ресурсы. Поэтому чрезвычайно важно убедиться, что робот Googlebot имеет доступ ко всем важным ресурсам, таким как изображения, файлы JavaScript и CSS.

Чтобы сигнализировать браузерам, что страница реагирует, тег meta = «viewport» должен быть размещен внутри каждой HTML-страницы.

Если метатег области просмотра отсутствует, размеры шрифта могут отображаться непоследовательно, что может привести к тому, что Google будет рассматривать страницу как несовместимую с мобильными устройствами.

Просмотр отдельных мобильных URL-адресов
Если мобильный веб-сайт использует URL-адреса, отличные от обычных, убедитесь, что:

На каждой странице рабочего стола есть тег, указывающий на соответствующий URL-адрес мобильного устройства.

Каждая мобильная страница имеет тег rel = «canonical», указывающий на соответствующий URL-адрес рабочего стола.

Когда URL для настольных компьютеров запрашиваются на мобильных устройствах, они перенаправляются на соответствующий URL для мобильных устройств.
Перенаправления
работают на всех мобильных устройствах, включая телефоны Android, iPhone и Windows.

Нет нерелевантных перекрестных ссылок между страницами для компьютеров и мобильных устройств. Это означает, что внутренние ссылки на странице для ПК должны указывать только на страницы для ПК, а ссылки на странице для мобильных устройств должны указывать только на другие страницы для мобильных устройств.

Мобильные URL-адреса возвращают ответ сервера 200.

Обзор динамического обслуживания
Веб-сайты с динамическим обслуживанием предоставляют разный код для каждого устройства, но по одному и тому же URL-адресу.

На сайтах с динамическим обслуживанием проверьте, правильно ли настроен изменяемый заголовок HTTP. Это необходимо, поскольку веб-сайты с динамическим обслуживанием изменяют HTML для мобильных пользовательских агентов, а изменяющийся HTTP-заголовок помогает роботу Googlebot обнаруживать мобильный контент.

Обзор мобильности

Независимо от настройки мобильного сайта (адаптивный, отдельные URL-адреса или динамическое обслуживание) просмотрите страницы с помощью мобильного агента пользователя и убедитесь, что:

Область просмотра настроена правильно. Использование области просмотра фиксированной ширины на разных устройствах вызовет проблемы с удобством использования на мобильных устройствах.

Размер шрифта не слишком мал.

Сенсорные элементы (то есть кнопки, ссылки) не слишком близко.

Нет никаких навязчивых межстраничных объявлений, таких как реклама, формы подписки на списки рассылки, всплывающие окна загрузки приложений и т. Д. Чтобы избежать каких-либо проблем, вы должны использовать небольшой HTML-баннер или графический баннер.

Мобильные страницы загружаются не слишком медленно (см. Следующий раздел).

Инструмент тестирования Google для мобильных устройств может помочь диагностировать большинство из перечисленных выше проблем:

Инструмент Google для мобильных устройств в действии

Обзор сайта AMP

Если есть веб-сайт AMP и доступна настольная версия сайта, убедитесь, что:

Каждая страница без AMP (т.е.е. desktop, mobile) имеет тег, указывающий на соответствующий URL AMP.

Каждая страница AMP имеет тег rel = «canonical», указывающий на соответствующую страницу для ПК.

Любая страница AMP, не имеющая соответствующего URL-адреса рабочего стола, имеет саморегулирующийся канонический тег.

Вы также должны убедиться, что AMP действительны. Это можно проверить с помощью Google AMP Test Tool.

Ошибки смешанного содержимого

Поскольку Google прилагает все усилия для обеспечения полной безопасности сайтов, а Chrome становится первым браузером, который помечает HTTP-страницы как небезопасные, стремитесь запустить новый сайт по HTTPS, убедившись, что все ресурсы, такие как изображения, файлы CSS и JavaScript, запрашиваются через безопасный режим. HTTPS-соединения.Это важно, чтобы избежать проблем со смешанным содержимым.

Смешанное содержимое возникает, когда страница, загруженная через защищенное соединение HTTPS, запрашивает ресурсы через небезопасные соединения HTTP. Большинство браузеров либо блокируют опасные HTTP-запросы, либо просто отображают предупреждения, мешающие работе пользователя.

Ошибки смешанного содержания в консоли JavaScript Chrome

Существует множество способов выявления ошибок смешанного содержания, в том числе с помощью приложений для сканирования, Google Lighthouse и т. Д.

Обзор графических ресурсов

Google сканирует изображения реже, чем страницы HTML. При переносе изображений с сайта из одного места в другое (например, из вашего домена в CDN) есть способы помочь Google быстрее обнаруживать перенесенные изображения. Создание карты сайта в формате XML поможет, но вам также необходимо убедиться, что робот Googlebot может получить доступ к изображениям сайта при сканировании сайта. Сложность индексирования изображений заключается в том, что индексируются как веб-страница, на которой появляется изображение, так и сам файл изображения.

Обзор эффективности сайта

И последнее, но не менее важное: измерьте время загрузки страницы старого сайта и посмотрите, как оно будет сравниваться с временем загрузки нового сайта, когда оно станет доступным на стадии тестирования. На этом этапе сосредоточьтесь на независимых от сети аспектах производительности, таких как использование внешних ресурсов (изображений, JavaScript и CSS), кода HTML и конфигурации веб-сервера. Более подробная информация о том, как это сделать, доступна ниже.

Обзор отслеживания Google Analytics

Убедитесь, что отслеживание аналитики правильно настроено.Этот обзор в идеале должен выполняться специалистами-консультантами по аналитике, которые не ограничиваются внедрением кода отслеживания. Убедитесь, что цели и события настроены правильно, реализовано отслеживание электронной торговли, включено расширенное отслеживание электронной торговли и т. Д. Нет ничего более неприятного, чем отсутствие данных аналитики после запуска вашего нового сайта.

Тестирование перенаправлений

Тестирование переадресации до того, как новый сайт заработает, имеет решающее значение и может избавить вас от многих проблем в дальнейшем.Есть много способов проверить перенаправления на промежуточном / тестовом сервере, но суть в том, что вам не следует запускать новый веб-сайт, не протестировав перенаправления .

Как только перенаправления станут доступны в тестовой среде, просканируйте весь список перенаправлений и проверьте следующие проблемы:

Циклы перенаправления (URL, который бесконечно перенаправляет на себя)

Перенаправляет с ответом сервера 4xx или 5xx.

Цепочки переадресации (URL-адрес, который перенаправляет на другой URL-адрес, который, в свою очередь, перенаправляет на другой URL-адрес и т. Д.).

Канонические URL-адреса, возвращающие ответ сервера 4xx или 5xx.

Канонические циклы (страница A имеет канонический указатель на страницу B, у которого есть канонический указатель на страницу A).

Канонические цепочки (канонические цепочки, указывающие на другую страницу, имеющие канонические значения, указывающие на другую страницу, и т. Д.).

Несогласованность протокола / хоста e.грамм. URL-адреса перенаправляются на URL-адреса HTTP и HTTPS или URL-адреса с www и без www.

Начальные / конечные пробельные символы. Для их устранения используйте trim () в Excel.

Недопустимые символы в URL-адресах.

Совет для профессионалов: убедитесь, что один из URL-адресов старого сайта перенаправляет на правильный URL-адрес нового сайта. На этом этапе, поскольку новый сайт еще не существует, вы можете только проверить, является ли целевой URL переадресации предполагаемым, но оно того стоит.Тот факт, что URL-адрес выполняет перенаправление, не означает, что он перенаправляется на нужную страницу.

Этап 4: Мероприятия в день запуска

Когда сайт не работает …

Пока новый сайт заменяет старый, есть вероятность, что действующий сайт временно отключится. Время простоя должно быть сведено к минимуму, но пока это происходит, веб-сервер должен отвечать на любой запрос URL-адреса ответом сервера 503 (служба недоступна). Это сообщит поисковым роботам, что сайт временно недоступен для обслуживания, поэтому они вернутся, чтобы сканировать сайт позже.

Если сайт слишком долго не работает, не обслуживая ответ сервера 503, а поисковые системы сканируют сайт, это отрицательно скажется на видимости в обычном поиске и восстановление не будет мгновенным после того, как сайт будет восстановлен. Кроме того, хотя веб-сайт временно не работает, он также должен служить информативной страницей хранения, уведомляющей пользователей о том, что веб-сайт временно недоступен для обслуживания.

Выборочные технические проверки

Как только новый сайт заработает, взгляните на:

Роботы.txt, чтобы поисковые системы не блокировали сканирование

Перенаправления на верхние страницы (например, правильно ли перенаправляются запросы на верхние страницы старого сайта?)

Верхние страницы канонических тегов

Самые популярные ответы сервера

Директивы Noindex / nofollow, если они являются непреднамеренными

Выборочные проверки необходимо проводить как на мобильных, так и на настольных сайтах, если только сайт не работает полностью.

Действия в Search Console

Сразу после запуска нового веб-сайта необходимо провести следующие мероприятия:

Проверить и загрузить XML-карту (-ы) сайта

Установите предпочтительное расположение домена (www или не www)

Установите международный таргетинг (если применимо)

Сконфигурируйте параметры URL-адреса для раннего решения любых потенциальных проблем с дублированием контента.

Загрузите файл Disavow (если применимо)

Используйте инструмент изменения адреса (при переключении доменов)

Профессиональный совет: используйте функцию «Просмотреть как Google» для разных типов страниц (например, для домашней страницы, категории, подкатегории, страницы продукта), чтобы робот Googlebot мог отображать страницы без каких-либо проблем. Просмотрите все сообщения о заблокированных ресурсах и не забудьте использовать Fetch и Render для настольных и мобильных устройств, особенно если мобильный веб-сайт не реагирует.

Заблокированные ресурсы не позволяют роботу Googlebot отображать содержимое страницы

Этап 5: Обзор после запуска

Как только новый сайт заработает, следует провести новый раунд тщательных проверок. Это в основном те же самые, что упомянуты в разделе «Фаза 3: предварительное тестирование».

Однако основное отличие этого этапа заключается в том, что теперь у вас есть доступ к гораздо большему количеству данных и инструментов. Не стоит недооценивать количество усилий, которые вам нужно будет приложить на этом этапе, потому что любые проблемы, с которыми вы сейчас сталкиваетесь, напрямую влияют на производительность сайта в поисковой выдаче. С другой стороны, чем раньше будет выявлена проблема, тем быстрее она будет решена.

В дополнение к повторению тех же задач тестирования, которые были описаны в разделе «Фаза 3», в определенных областях можно протестировать более тщательно, точно и более детально. Теперь вы можете в полной мере использовать возможности Search Console.

Проверить статистику сканирования и журналы сервера

Следите за статистикой сканирования, доступной в Search Console, чтобы убедиться, что Google сканирует страницы нового сайта. Как правило, когда робот Googlebot обнаруживает новые страницы, он обычно увеличивает среднее количество страниц, которые он сканирует в день. Но если вы не можете обнаружить всплеск во время даты запуска, что-то может отрицательно сказаться на способности робота Googlebot сканировать сайт.

Статистика сканирования в Google Search Console

Просмотр файлов журналов сервера — это, безусловно, самый эффективный способ обнаружить любые проблемы со сканированием или неэффективность.Такие инструменты, как Botify и On Crawl, могут быть чрезвычайно полезными, поскольку они сочетают сканирование с данными журнала сервера и могут выделять страницы, которые не сканируются поисковыми системами, страницы, на которые нет внутренних ссылок (страницы-сироты), малоценные страницы, на которые есть сильные внутренние ссылки, и многое другое.

Регулярно проверяйте ошибки сканирования

Следите за сообщениями об ошибках сканирования, в идеале ежедневно в течение первых нескольких недель. Ежедневная загрузка этих ошибок, сканирование указанных URL-адресов и выполнение необходимых действий (т.е. реализовать дополнительные 301 редирект, исправить мягкие ошибки 404) поможет более быстрому восстановлению. Маловероятно, что вам потребуется перенаправлять каждую полученную ошибку 404, но вам следует добавить перенаправление для наиболее важных.

Совет для профессионалов: В Google Analytics вы можете легко узнать, какие 404 URL-адреса наиболее часто запрашиваются, и исправить их в первую очередь!

Другие полезные функции Search Console

Другие функции Search Console, которые стоит проверить, включают заблокированные ресурсы, ошибки структурированных данных, ошибки удобства использования мобильных устройств, улучшения HTML и международный таргетинг (для проверки ошибок, сообщаемых hreflang).
Совет
Pro: внимательно следите за параметрами URL, если они вызывают проблемы с дублированием контента. В этом случае рассмотрите возможность принятия срочных мер по исправлению положения.

Скорость участка измерения

Как только новый сайт будет запущен, измерьте его скорость, чтобы убедиться, что страницы сайта загружаются достаточно быстро как на настольных, так и на мобильных устройствах. Поскольку скорость сайта является сигналом ранжирования на разных устройствах и из-за того, что страницы медленно теряют пользователей и клиентов, сравнение скорости нового сайта со скоростью старого сайта чрезвычайно важно. Если время загрузки страницы нового сайта кажется выше, вам следует немедленно принять меры, иначе трафик вашего сайта и конверсии почти наверняка пострадают.

Оценка скорости с помощью инструментов Google

В этом могут помочь два инструмента: Google Lighthouse и Pagespeed Insights.

Инструмент Pagespeed Insights измеряет производительность страниц как на мобильных, так и на настольных устройствах и показывает реальные данные о скорости страницы на основе пользовательских данных, которые Google собирает из Chrome.Он также проверяет, применены ли к странице общие рекомендации по производительности, и предоставляет оценку оптимизации. Инструмент включает следующие основные категории:

Оценка скорости: классифицирует страницу как быструю, среднюю или медленную с использованием двух показателей: первая отрисовка содержимого (FCP) и загруженное содержимое DOM (DCL). Страница считается быстрой, если оба показателя находятся в верхней трети своей категории.

Оценка оптимизации: классифицирует страницу как хорошую, среднюю или низкую в зависимости от запаса производительности.

Распределение загрузки страниц: классифицирует страницу как быструю (третья третья скорость), среднюю треть (средняя треть) или медленную (нижняя треть) путем сравнения со всеми событиями FCP и DCL в отчете о пользовательском опыте Chrome.

Статистика страницы: может указывать, может ли страница работать быстрее, если разработчик изменит внешний вид и функциональность страницы.

Предложения по оптимизации: список передовых методов, которые можно применить к странице.

Google’s PageSpeed Insights в действии

Google’s Lighthouse очень удобен для проверки производительности мобильных устройств, доступности и прогрессивных веб-приложений.Он предоставляет различные полезные показатели, которые можно использовать для измерения производительности страницы на мобильных устройствах, например:

Первая значимая отрисовка, которая измеряет, когда видно основное содержимое страницы.

Время до интерактивности — это момент, когда страница готова к взаимодействию пользователя.
Индекс скорости
показывает, насколько быстро страница заполняется.

Оба инструмента предоставляют рекомендации по улучшению любых обнаруженных проблем с производительностью сайта.

Маяк Google в действии

Вы также можете использовать этот инструмент Google, чтобы получить приблизительную оценку процента пользователей, которых вы можете потерять со страниц своего мобильного сайта из-за медленной загрузки страницы.

Этот же инструмент также обеспечивает сравнение по отраслям, чтобы вы могли понять, насколько вы далеки от самых эффективных сайтов в своей отрасли.

Измерение скорости от реальных пользователей

После того, как сайт заработал, вы можете начать оценивать скорость сайта на основе пользователей, посещающих ваш сайт.Если у вас есть Google Analytics, вы можете легко сравнить среднее время загрузки нового сайта с предыдущим.

Кроме того, если у вас есть доступ к инструменту мониторинга реальных пользователей, например Pingdom, вы можете оценить скорость сайта на основе пользователей, посещающих ваш сайт. На приведенной ниже карте показано, как разные посетители испытывают очень разное время загрузки в зависимости от своего географического положения. В приведенном ниже примере время загрузки страницы кажется удовлетворительным для посетителей из Великобритании, США и Германии, но для пользователей, проживающих в других странах, оно намного выше.

Этап 6. Измерение эффективности миграции сайта

Когда измерять

Перенос сайта прошел успешно? Это вопрос на миллион долларов, на который все участники захотят узнать ответ, как только новый сайт заработает. В действительности, чем дольше вы ждете, тем яснее становится ответ, поскольку видимость в течение первых нескольких недель или даже месяцев может быть очень нестабильной в зависимости от размера и авторитета вашего сайта. Для небольших сайтов должно хватить 4–6 недель, прежде чем сравнивать видимость нового сайта со старым.Для крупных веб-сайтов перед измерением может потребоваться как минимум 2–3 месяца.

Кроме того, если новый сайт значительно отличается от предыдущего, пользователям потребуется некоторое время, чтобы привыкнуть к новому оформлению и привыкнуть к новой таксономии, путешествиям пользователей и т. Д. Такие изменения изначально имеют существенный недостаток. влияние на коэффициент конверсии сайта, который должен улучшиться через несколько недель, поскольку вернувшиеся посетители все больше и больше привыкают к новому сайту.В любом случае делать выводы о UX нового сайта на основе данных может быть рискованно.

Но это всего лишь общие правила, которые необходимо учитывать наряду с другими факторами. Например, если через несколько дней или недель после запуска нового сайта были внесены значительные дополнительные изменения (например, для решения технической проблемы), оценку миграции следует отложить.

Как измерить

Измерение производительности очень важно, и хотя заинтересованным сторонам бизнеса было бы интересно услышать только о доходах и влиянии трафика, существует множество других показателей, на которые следует обратить внимание.Например, может быть несколько причин снижения доходов после миграции сайта, включая сезонные тенденции, снижение интереса к бренду, проблемы UX, которые значительно снизили коэффициент конверсии сайта, низкая производительность мобильных устройств, плохое время загрузки страницы и т. Д. Помимо показателей органического трафика и доходов, обратите внимание на следующее:

Видимость на настольных и мобильных устройствах (из SearchMetrics, SEMrush, Sistrix)

Рейтинг компьютеров и мобильных устройств (с помощью любого надежного инструмента отслеживания рейтинга)

Вовлеченность пользователей (показатель отказов, среднее время на странице)

сеансов на тип страницы (т.е.е. страницы категорий ведут столько же сеансов, сколько раньше?)

Коэффициент конверсии по типу страницы (т. е. конвертируются ли страницы продукта так же, как и раньше?)

Коэффициент конверсии по устройствам (т. Е. Увеличился / уменьшился ли коэффициент конверсии для настольных компьютеров и мобильных устройств с момента запуска нового сайта?)

Просмотр нижеследующего также может быть очень полезным, особенно с точки зрения устранения технических неполадок:

Количество проиндексированных страниц (Search Console)

Отправленные и проиндексированные страницы в XML-файлах Sitemap (Search Console)

Страницы, получившие хотя бы одно посещение (аналитика)

Скорость сайта (PageSpeed Insights, Lighthouse, Google Analytics)

Только после того, как вы изучите все вышеперечисленные области, вы сможете с уверенностью сделать вывод, успешна ли миграция или нет.

Удачи, и если вам нужна консультация или помощь в переносе вашего сайта, свяжитесь с нами!

Контрольный список для переноса сайта

Актуальный контрольный список миграции сайта можно загрузить с нашего сайта. Обратите внимание, что контрольный список регулярно обновляется и включает все критические области для успешной миграции сайта.

Приложение: Полезные инструменты

Гусеничные

Screaming Frog: Швейцарский армейский нож SEO, идеально подходящий для сканирования сайтов малого и среднего размера.

Sitebulb: очень интуитивно понятное приложение для сканирования с аккуратным пользовательским интерфейсом, хорошо организованными отчетами и множеством полезных визуализаций данных.

Deep Crawl: облачный поисковый робот с возможностью сканирования промежуточных сайтов и сравнения их сканирования. Позволяет сравнивать разные обходы и хорошо справляется с большими веб-сайтами.

Botify: еще один мощный облачный сканер, поддерживающий исключительные возможности анализа файлов журнала сервера, которые могут быть очень полезными с точки зрения понимания того, как поисковые системы сканируют сайт.

On-Crawl: сканер и анализатор журналов сервера для корпоративного SEO-аудита со множеством удобных функций для определения бюджета сканирования, качества контента и производительности.

Надстройки Handy Chrome

Веб-разработчик: набор инструментов разработчика, включая простые способы включения / отключения JavaScript, CSS, изображений и т. Д.

Переключатель пользовательских агентов: переключение между различными пользовательскими агентами, включая Googlebot, мобильные и другие агенты.

Ayima Redirect Path: отличное средство проверки заголовков и перенаправлений.

SEO Meta в 1 клик: мета-атрибуты на странице, инспектор заголовков и ссылок.

Scraper: простой способ скопировать данные веб-сайта в электронную таблицу.

Инструменты для мониторинга объектов

Uptime Robot: бесплатный мониторинг работоспособности сайта.

Robotto: бесплатный инструмент для мониторинга robots.txt.

Инструменты Pingdom: отслеживает время работы сайта и скорость загрузки страниц от реальных пользователей (служба RUM).

SEO Radar: отслеживает все критические элементы SEO и выдает предупреждения при их изменении.

Инструменты для повышения производительности сайта

PageSpeed Insights: измеряет производительность страницы для мобильных и настольных устройств. Он проверяет, применены ли к странице общие передовые методы производительности, и предоставляет оценку от 0 до 100 баллов.

Lighthouse: удобное расширение Chrome для повышения производительности, доступности и аудита прогрессивных веб-приложений. Также может быть запущен из командной строки или как модуль Node.

Webpagetest.org: очень подробные тесты страниц из различных мест, подключений и устройств, включая подробные диаграммы водопада.

Инструменты тестирования структурированных данных

Мобильные средства тестирования

Источники данных обратных ссылок

Фреймворк «сайты» | Документация Django

Django поставляется с дополнительным фреймворком «сайты». Это крючок для ассоциации объекты и функции для определенных веб-сайтов, и это место хранения для доменные имена и «подробные» имена ваших сайтов на Django.

Используйте его, если ваша единственная установка Django поддерживает более одного сайта и вы нужно как-то различать эти сайты.

Фреймворк сайтов в основном основан на этой модели:

класс моделей. Участок ¶

Модель для хранения доменов и name атрибутов веб-сайта.

домен ¶

Полное доменное имя, связанное с сайтом. Например, www.example.com .

название ¶

Понятное «подробное» имя веб-сайта.

Параметр SITE_ID указывает идентификатор базы данных Site объект, связанный с этим конкретный файл настроек. Если параметр не указан, get_current_site () функция будет попытайтесь получить текущий сайт, сравнив домен с именем хоста из метод request.get_host () .

Как вы это используете, зависит от вас, но Django использует его несколькими способами автоматически с помощью пары соглашений.

Пример использования¶

Зачем вам нужны сайты? Лучше всего это объяснить на примерах.

Связывание контента с несколькими сайтами¶

Сайты LJWorld.com и Lawrence.com обслуживаются одними и теми же новостями. организация — газета Lawrence Journal-World в Лоуренсе, штат Канзас. LJWorld.com сосредоточился на новостях, а сайт Lawrence.com — на местных развлечениях. Но иногда редакторы хотели опубликовать статью на и сайтах.

Наивный способ решения проблемы — потребовать от производителей сайтов опубликовать одну и ту же историю дважды: один раз для LJWorld.com и снова для Lawrence.com. Но для производителей сайтов это неэффективно, а хранить несколько копий одной и той же истории в базе данных.

Лучшее решение устраняет дублирование контента: оба сайта используют одинаковые база данных статей, и статья связана с одним или несколькими сайтами. В Терминология модели Django, представленная ManyToManyField в артикуле модель:

с сайта импорта django.contrib.sites.models из django.модели импорта БД класс Article (models.Model): заголовок = models.CharField (max_length = 200) # ... sites = models.ManyToManyField (Сайт)

Это прекрасно выполняет несколько задач:

Это позволяет производителям сайтов редактировать весь контент — на обоих сайтах — в единый интерфейс (администратор Django).

Это означает, что одну и ту же историю не нужно публиковать дважды в база данных; в базе данных есть только одна запись.

Это позволяет разработчикам сайтов использовать один и тот же код представления Django для обоих сайтов.Код представления, отображающий данную историю, проверяет, что запрошенный история находится на текущем сайте. Выглядит это примерно так:

из django.contrib.sites.shortcuts import get_current_site def article_detail (запрос, article_id): пытаться: a = Article. objects.get (id = article_id, sites__id = get_current_site (request) .id) кроме статьи.DoesNotExist: поднять Http404 ("Статья не существует на этом сайте") # ...

Связывание контента с одним сайтом¶

Аналогичным образом вы можете связать модель с Площадка модель в отношениях «многие-к-одному», используя Иностранный ключ .

Например, если статья разрешена только на одном сайте, вы должны использовать модель как это:

с сайта импорта django.contrib.sites.models из моделей импорта django.db класс Article (models.Model): заголовок = models.CharField (max_length = 200) # ... site = models.ForeignKey (Сайт, on_delete = models.CASCADE)

Имеет те же преимущества, что описаны в последнем разделе.

Подключение к текущему сайту из просмотров¶

Вы можете использовать структуру сайтов в представлениях Django, чтобы конкретные вещи, основанные на сайте, на котором вызывается представление. Например:

из настроек импорта django.conf def my_view (запрос): если settings.SITE_ID == 3: # Сделай что-нибудь. проходить еще: # Сделайте что-нибудь еще. проходить

Жестко запрограммировать такие идентификаторы сайтов на случай, если они изменятся. В Более чистый способ сделать то же самое — проверить текущий сайт домен:

из django.contrib.sites.shortcuts import get_current_site def my_view (запрос): current_site = get_current_site (запрос) если current_site.domain == 'foo.com': # Сделай что-нибудь проходить еще: # Сделайте что-нибудь еще. проходить

Это также имеет то преимущество, что проверяет, установлен ли фреймворк сайтов, и вернуть экземпляр RequestSite , если это не так.

Если у вас нет доступа к объекту запроса, вы можете использовать get_current () метод сайта модель-менеджер. Затем вы должны убедиться, что ваш файл настроек действительно содержит настройка SITE_ID . Этот пример эквивалентен предыдущему:

с сайта импорта django.contrib.sites.models def my_function_without_request (): current_site = Site.objects.get_current () если current_site.domain == 'foo.com': # Сделай что-нибудь проходить еще: # Сделайте что-нибудь еще. проходить

Получение текущего домена для отображения¶

LJWorld.com и Lawrence.com имеют функцию оповещения по электронной почте, что позволяет читатели подписываются, чтобы получать уведомления о появлении новостей.Это довольно просто: A читатель регистрируется в веб-форме и сразу получает письмо по электронной почте: «Спасибо за подписку».

Было бы неэффективно и излишне внедрять этот код обработки регистрации. дважды, поэтому сайты используют один и тот же код за кулисами. Но «спасибо за Регистрация »должна быть разной для каждого сайта. Используя Площадка объектов, мы можем абстрагироваться от надписи «Спасибо», чтобы использовать значения имя текущего сайта и домен .

Вот пример того, как выглядит представление обработки формы:

из django.contrib.sites.shortcuts import get_current_site из django.core.mail импорт send_mail def register_for_newsletter (запрос): # Проверить значения формы и т. Д. И подписать пользователя. # ... current_site = get_current_site (запрос) Отправить письмо( "Спасибо за подписку на оповещения% s"% current_site.name, «Спасибо за подписку. Мы ценим это. \ N \ n-Команда% s. ' % ( текущий_сайт.имя, ), 'editor @% s'% current_site.domain, [user.email], ) # ...

На сайте Lawrence.com это письмо имеет тему «Спасибо за подписку на lawrence.com оповещения ». На LJWorld.com письмо имеет тему «Спасибо за подписка на оповещения LJWorld.com ». То же самое и с телом электронного письма.

Обратите внимание, что еще более гибкий (но более тяжелый) способ сделать это быть использовать систему шаблонов Django. Предполагая, что Lawrence. com и LJWorld.com есть различные каталоги шаблонов ( DIRS ), вы можете переместите в систему шаблонов так:

из django.core.mail импорт send_mail из загрузчика импорта django.template def register_for_newsletter (запрос): # Проверить значения формы и т. Д. И подписать пользователя. # ... subject = loader.get_template ('предупреждения / subject.txt'). render ({}) message = loader.get_template ('alerts / message.txt'). render ({}) send_mail (тема, сообщение, '[email protected]', [user.email]) #...

В этом случае вам нужно создать subject.txt и message.txt файлы шаблонов для каталогов шаблонов LJWorld.com и Lawrence.com. Это дает вам больше гибкости, но также и сложнее.

Хорошая идея — использовать сайт . объектов, насколько это возможно, чтобы убрать ненужную сложность и избыточность.

Получение текущего домена для полных URL¶

Соглашение Django get_absolute_url () удобно для получения ваших объектов. URL без имени домена, но в некоторых случаях вы можете захотеть отобразить полный URL — с http: // и доменом и всем остальным — для объекта.Для этого можно использовать фреймворк сайтов. Пример:

>>> с сайта импорта django.contrib.sites.models >>> obj = MyModel.objects.get (id = 3) >>> obj.get_absolute_url () '/ моямодель / объекты / 3 /' >>> Site.objects.get_current (). Domain example.com >>> 'https: //% s% s'% (Site.objects.get_current (). domain, obj.get_absolute_url ()) https://example.com/mymodel/objects/3/

Включение фреймворка сайтов¶

Чтобы включить структуру сайтов, выполните следующие действия:

Добавить 'django.contrib.sites ' в настройку INSTALLED_APPS .

Определите SITE_ID setting:

Выполнить Перенести .

django.contrib.sites регистрирует post_migrate обработчик сигнала, который создает сайт по умолчанию с именем example. com с доменом example.com . Этот сайт также будет создан после того, как Django создаст тестовую базу данных. Чтобы установить правильное имя и домен для вашего проекта, вы можете использовать перенос данных.

Чтобы обслуживать разные сайты в производственной среде, вы должны создать отдельный файл настроек с каждым SITE_ID (возможно, импорт из общих настроек файл, чтобы избежать дублирования общих настроек), а затем укажите соответствующий DJANGO_SETTINGS_MODULE для каждого сайта.

Кэширование текущего объекта
Site
Поскольку текущий сайт хранится в базе данных, каждый вызов Site.objects.get_current () может привести к запросу базы данных.Но Джанго — это немного умнее этого: по первому запросу текущий сайт кэшируется, и любой последующий вызов возвращает кэшированные данные вместо обращения к базе данных.

Если по какой-либо причине вы хотите принудительно выполнить запрос к базе данных, вы можете указать Django очистить кеш с помощью Site. objects.clear_cache () :

# Первый звонок; текущий сайт получен из базы данных. current_site = Site.objects.get_current () # ... # Второй звонок; текущий сайт извлечен из кеша. current_site = Сайт.objects.get_current () # ... # Форсировать запрос к базе данных для третьего вызова. Site.objects.clear_cache () current_site = Site.objects.get_current ()

The
CurrentSiteManager ¶

класс менеджеров. CurrentSiteManager ¶

Если Объект играет ключевую роль в вашем приложение, рассмотрите возможность использования полезного CurrentSiteManager в вашем модель (ы). Модельный менеджер, автоматически фильтрует свои запросы, чтобы включать только связанные объекты с текущим Сайт .

Обязательно SITE_ID

CurrentSiteManager можно использовать, только если SITE_ID настройка определяется в ваших настройках.

Используйте CurrentSiteManager , добавив его в ваша модель явно. Например:

с сайта импорта django.contrib.sites.models из django.contrib.sites.managers импортировать CurrentSiteManager из моделей импорта django.db класс Фото (models.Model): photo = models.FileField (upload_to = 'photos') фотограф_имя = модели.CharField (max_length = 100) pub_date = models.DateField () site = models.ForeignKey (Сайт, on_delete = models.CASCADE) objects = models.Manager () on_site = CurrentSiteManager ()

В этой модели Photo.objects.all () вернет все объекты Photo в база данных, но Photo.on_site.all () вернет только объекты Photo связанный с текущим сайтом, согласно настройке SITE_ID .

Другими словами, эти два утверждения эквивалентны:

Фото.objects.filter (site = settings.SITE_ID) Photo.on_site.all ()

Как появился CurrentSiteManager знать, какое поле Фото было Сайт ? По умолчанию, CurrentSiteManager ищет либо ForeignKey называется участок или а ManyToManyField называется сайтов для фильтрации. Если вы используете поле с именем, отличным от сайтов или сайтов , чтобы определить, какие Сайт объектов ваш объект связанных с, то вам необходимо явно передать имя настраиваемого поля как параметр для CurrentSiteManager на вашем модель.Следующая модель, в которой есть поле с именем publish_on , демонстрирует это:

с сайта импорта django.contrib.sites.models из django.contrib.sites.managers импортировать CurrentSiteManager из моделей импорта django.db класс Фото (models.Model): photo = models.FileField (upload_to = 'photos') фотограф_имя = models.CharField (max_length = 100) pub_date = models.DateField () publish_on = models.ForeignKey (Сайт, on_delete = models.CASCADE) objects = models.Manager () on_site = CurrentSiteManager ('publish_on')

Если вы попытаетесь использовать CurrentSiteManager и передать имя поля, которого не существует, Django вызовет ValueError .

Наконец, обратите внимание, что вы, вероятно, захотите сохранить нормальный (не зависит от конкретной площадки) Manager на вашей модели, даже если вы используете CurrentSiteManager . В качестве объяснено в документации менеджера, если вы определяете менеджера вручную, тогда Django не создаст автоматический objects = models.Manager () менеджер для вас. Также обратите внимание, что некоторые части Django, а именно сайт администратора Django и общие представления — используйте тот менеджер, который определен первым в модели, поэтому, если вы хотите ваш сайт администратора, чтобы иметь доступ ко всем объектам (а не только к конкретным единицы), положите объектов = модели.Manager () в вашей модели, перед вами определить CurrentSiteManager .

Промежуточное ПО сайта¶

Если вы часто используете этот шаблон:

с сайта импорта django.contrib.sites.models def my_view (запрос): site = Site. objects.get_current () ...

Чтобы избежать повторов, добавьте django.contrib.sites.middleware.CurrentSiteMiddleware с по ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ . Промежуточное ПО устанавливает атрибут сайта для каждого объект запроса, поэтому вы можете использовать запрос .site , чтобы получить текущий сайт.

Как Django использует структуру сайтов¶

Хотя использование платформы для сайтов не обязательно, поощряется, потому что Django использует это в нескольких местах. Даже если твой Установка Django работает только с одним сайтом, вы должны взять два секунд, чтобы создать объект сайта с вашим доменом и именем , и укажите к его идентификатору в настройке SITE_ID .

Вот как Django использует структуру сайтов:

В структуре перенаправления , каждый объект перенаправления связан с определенным сайтом.Когда Django ищет для перенаправления учитывается текущий сайт.

В рамке плоских , каждая плоская страница связана с определенным сайтом. Когда создается плоская страница, вы указываете его Сайт , а FlatpageFallbackСреднее ПО проверяет текущий сайт при получении плоских страниц для отображения.

В рамках синдикации , шаблоны для заголовок и описание автоматически получают доступ к переменная {{site}} , которая является Site объект, представляющий текущий сайт.Кроме того, ловушка для предоставления URL-адресов элементов будет использовать домен из текущий объект Site , если вы не укажите полный домен.

В структуре аутентификации , django.contrib.auth.views.LoginView передает текущий Сайт имя в шаблоне как {{site_name}} .

Вид ярлыка ( django.contrib.contenttypes.views.shortcut ) использует домен текущего Сайт объект при расчете URL объекта.

В административной структуре ссылка «Просмотр на сайте» использует текущий Сайт для разработки домена для сайт, на который он будет перенаправлен.

RequestSite объектов¶
Некоторые приложения django.contrib используют преимущества структура сайтов, но спроектирована таким образом, что не требует фреймворк сайтов, который будет установлен в вашу базу данных. (Некоторые люди не хотят, или просто не может установить дополнительную таблицу базы данных, которую сайты framework требует.) Для этих случаев фреймворк предоставляет django.contrib.sites.requests.RequestSite класс, который можно использовать как резервный вариант, когда платформа сайтов с поддержкой базы данных недоступна.

класс запросов. RequestSite ¶

Класс, использующий основной интерфейс Зона (т.е. домен и имя атрибутов), но получает свои данные от Django HttpRequest объект, а не из базы данных.

__init__ ( запрос )
¶

Устанавливает для атрибутов имя и домен значение get_host () .

Объект RequestSite имеет аналогичный интерфейс с обычным объектом Site , кроме его __init __ () принимает объект HttpRequest . Он способен вывести домен и имя , просмотрев домен запроса.Она имеет save () и delete () методы, соответствующие интерфейсу Сайт , но методы поднять NotImplementedError .

get_current_site ярлык¶
Наконец, чтобы избежать повторяющегося резервного кода, фреймворк предоставляет django.contrib.sites.shortcuts.get_current_site () функция.

ярлыков. get_current_site ( запрос ) ¶

Функция, проверяющая наличие файла django. contrib.sites установлен и возвращает либо текущий Сайт объект или объект RequestSite на основании запроса. Он ищет текущий сайт на основе request.get_host () , если SITE_ID Настройка не определена.

И домен, и порт могут быть возвращены request.get_host () , когда заголовок Host имеет порт явно указано, например example.com:80 . В таких случаях, если поиск не выполняется, потому что хост не соответствует записи в базе данных, порт удаляется, и поиск повторяется с доменной частью Только.Это не относится к RequestSite , который всегда использовать неизмененный хост.

Этот сайт опубликовал каждое лицо из видео Parler’s Capitol Riot

Когда на прошлой неделе хакеры воспользовались ошибкой в Parler для загрузки всего содержания правой платформы социальных сетей, они были удивлены, обнаружив, что многие изображения и видео содержали метаданные геолокации показывая, сколько именно пользователей сайта принимали участие во вторжении в здание Капитолия США всего за несколько дней до этого. Но видео, загруженные в Parler, также содержат столь же конфиденциальную информацию, которая находится у всех на виду: тысячи изображений лиц без масок, многие из которых участвовали в бунте Капитолия. Теперь один веб-сайт выполнил работу по каталогизации и публикации каждого из этих лиц в единой, удобной для просмотра линейке.

В конце прошлой недели в сети появился веб-сайт Faces of the Riot, на котором не было ничего, кроме огромной сетки из более чем 6000 изображений лиц, каждое из которых помечено только строкой символов, связанных с видео Parler, в котором оно появилось.Создатель сайта сообщает WIRED, что он использовал простое программное обеспечение для машинного обучения и распознавания лиц с открытым исходным кодом для обнаружения, извлечения и дедупликации каждого лица из 827 видео, которые были отправлены Парлеру изнутри и за пределами здания Капитолия 6 января, в день радикализации. Сторонники Трампа штурмовали здание в результате беспорядков, в результате которых погибли пять человек. Создатель Faces of the Riot говорит, что его цель — позволить любому легко отсортировать лица, взятые из этих видео, чтобы идентифицировать кого-то, кого они могут знать или узнать, кто принимал участие в мафии, или даже сослаться на собранные лица на разыскиваемых ФБР плакатах. и отправить наводку правоохранительным органам, если они кого-то заметят.

«Все, кто участвует в этом насилии, которое на самом деле равносильно восстанию, должны понести ответственность», — говорит создатель сайта, пожелавший остаться неназванным, чтобы избежать возмездия. «Вполне возможно, что многие люди, которые были на этом веб-сайте сейчас, столкнутся с реальными последствиями своих действий».

Помимо явной озабоченности по поводу конфиденциальности, которую это вызывает, неизбирательная публикация лиц Faces of the Riot не делает различий между нарушителями закона — которые топтали барьеры, вторгались в здание Капитолия и нарушали законодательные палаты — и людьми, которые просто присутствовали на протестах снаружи . Сегодняшнее обновление сайта добавляет гиперссылки с лиц на источник видео, так что посетители могут щелкнуть любое лицо и увидеть, что этот человек делал на Parler. Создатель Faces of the Riot, который говорит, что он студент колледжа в «большом округе Колумбия», намеревается добавить эту дополнительную функцию, чтобы помочь контекстуализировать включение каждого лица на сайт и различать прохожих, мирных протестующих и агрессивных мятежников.

Он признает, что он и его соавтор все еще работают, чтобы вычистить лица «не бунтовщиков», включая присутствовавших полицейских и представителей прессы.Сообщение в верхней части сайта также предостерегает от расследований со стороны линчевателей, вместо этого предлагая пользователям сообщать о тех, кого они узнают, в ФБР со ссылкой на страницу с советами ФБР. «Если вы зайдете на сайт и увидите кого-то из своих знакомых, вы можете узнать что-нибудь о родственнике», — говорит он. «Или вы могли бы сказать: о, я знаю этого человека, а затем передайте эту информацию властям».

«Все, кто участвует в этом насилии, которое на самом деле равносильно восстанию, должны понести ответственность.

Создатель Faces of the Riot

Несмотря на заявления об отказе от ответственности и ограничения, Faces of the Riot представляет собой серьезную угрозу конфиденциальности, связанную с повсеместной технологией распознавания лиц, — говорит Эван Грир, директор кампании некоммерческой организации «Борьба за будущее» за цифровые гражданские свободы. «Независимо от того, используется ли эта технология отдельным лицом или государством, эта технология имеет серьезные последствия для прав человека и свободы выражения мнения», — говорит Грир, чья организация борется за законодательный запрет на технологии распознавания лиц.«Я думаю, что было бы огромной ошибкой, если бы мы выйдем из этого момента, прославляя или превознося технологию, которая, в широком смысле, несоразмерно вредит цветным сообществам, сообществам с низким доходом, сообществам иммигрантов, мусульманским сообществам, активистам .

No related posts.

Поделится

Facebook

Twitter

Google +

Stumbleupon

LinkedIn

Pinterest

Версия сайта	Образец абзаца	Улучшение удобства использования (относительно контрольного условия)
Рекламное письмо (контрольное условие) с использованием слова «marketese», которое можно найти на многих коммерческих сайтах	Небраска наполнена всемирно признанными достопримечательностями, которые неизменно привлекают большие толпы людей каждый год. В 1996 году одними из самых популярных мест были Государственный парк Форт-Робинсон (355 000 посетителей), Национальный памятник Скоттс-Блафф (132 166), Государственный исторический парк и музей Арбор-Лодж (100 000), Кархендж (86 598), Музей Штур Пионер прерий ( 60 002) и Государственный исторический парк Buffalo Bill Ranch (28 446).	0% (по определению)
Краткий текст с примерно половиной количества слов в качестве условия управления	В 1996 году шестью наиболее посещаемыми достопримечательностями Небраски были Государственный парк Форт Робинсон, Национальный памятник Скоттс-Блафф, Государственный исторический парк и музей Арбор-Лодж, Кархендж, Музей Пионера прерий Штур и Государственный исторический парк Ранчо Баффало Билла.	58%
Макет для сканирования с использованием того же текста, что и условие управления в макете, который облегчил сканирование	Небраска наполнена всемирно признанными достопримечательностями, которые неизменно привлекают большие толпы людей каждый год.В 1996 году одними из самых популярных мест были: Государственный парк Форт Робинсон (355 000 посетителей) Национальный памятник Скоттс Блафф (132 166) Государственный исторический парк и музей Arbor Lodge (100 000) Кархендж (86,598) Stuhr Museum of the Prairie Pioneer (60 002) Государственный исторический парк ранчо Буффало Билла (28 446).	47%
Объективный язык Использование нейтральной, а не субъективной, хвастливой или преувеличенной формулировки (в остальном то же, что и контрольное условие)	Небраска имеет несколько достопримечательностей. В 1996 году одними из самых посещаемых мест были Государственный парк Форт Робинсон (355 000 посетителей), Национальный памятник Скоттс-Блафф (132 166), Государственный исторический парк и музей Арбор-Лодж (100 000), Кархендж (86 598), Музей Пионера Прерии (60 002), и Государственный исторический парк Ранчо Буффало Билла (28 446).	27%
Комбинированная версия , использующая вместе все три улучшения стиля письма: краткое, с возможностью сканирования и объективное	В 1996 году шесть самых посещаемых мест в Небраске были: Государственный парк Форт Робинсон Национальный памятник Скоттс-Блафф Государственный исторический парк и музей Arbor Lodge Carhenge Stuhr Museum of the Prairie Pioneer Государственный исторический парк ранчо Буффало Билла	124%

МОБИЛЬНЫЙ	Скорость	FCP	DCL	Оптимизация	Оценка оптимизации
Домашняя страница	Быстро	0. 7 с	1,4 с	Хорошо	81/100
Страница категории	Медленно	1,8 с	5,1 с	Средний	78/100
Страница подкатегории	Среднее	0.9 с	2,4 с	Средний	69/100
Страница продукта	Медленно	1,9 с	5,5 с	Хорошо	83/100

С сайта: как бесплатно спарсить и извлечь данные с сайта — SEO на vc.ru

Related Articles

Цель набора персонала: Понятие, цели, задачи отбора и найма персонала. Источники найма персонала на современном предприятии

Что снимать на ютуб: 40+ идей для видео на YouTube

Н хилл: Наполеон Хилл — Новинки книг 2020 – скачать или читать онлайн

как бесплатно спарсить и извлечь данные с сайта — SEO на vc.ru

Как бесплатно спарсить и извлечь данные с сайта (веб-скрейпинг)

BatchURLScraper

Извлечение данных со страниц сайтов в примерах

Примеры кода для извлечения данных

Как скопировать защищенный текст с сайта с помощью Google Chrome

Узнайте как фиксировать точки выхода с сайта и загрузку файлов

С сайта Роспотребнадзора исчезла новость об ищущих коронавирус собаках :: Общество :: РБК

Я хочу стянуть информацию с сайта. Как это сделать?

Библиотека requests

API

BS4

Selenium Web Driver

А что делать, если там авторизация?

А что, если сайт банит за много запросов?

С сайта Центра Мейерхольда удалили страницу актрисы, поддержавшей Навального

Как работает Интернет — Изучите веб-разработку

Оценка информации в Интернете

Суффикс домена

Полномочия

Валюта

Ссылки

URL

Сравнение

Как пользователи читают в Интернете

Измерение эффекта от улучшения веб-письма

Полный отчет

Как долго пользователи остаются на веб-страницах?

Оставление веб-страниц: функция опасности Вейбулла

Отрицательное старение: быстро уйти или остаться надолго

Справочная и связанная литература

Руководство по миграции веб-сайта: SEO-стратегия, процесс и контрольный список

Что такое миграция сайта?

Ссылки быстрого доступа

Примеры миграции сайта

Развенчание мифа о «ожидаемом спаде трафика»

Примеры неудачных миграций сайтов

Примеры успешных миграций сайтов

Типы миграции сайта

Миграция перемещения сайта

Изменение протокола

Изменение субдомена или подпапки

Изменение доменного имени

Изменение домена верхнего уровня

Изменения в структуре сайта

Другие виды миграции

Переплатформенность

Перенос содержимого

Изменения в мобильной настройке

Структурные изменения

Редизайн сайта

Гибридные миграции

Общие ошибки при переносе сайтов

Плохая стратегия

Плохое планирование

Недостаток ресурсов

Отсутствие консультации по SEO / UX

Позднее участие

Отсутствие тестирования

Медленный ответ на исправление ошибки

Шкала занижения

Процесс миграции сайта

Этап 1: Объем и планирование

Разработать объем проекта

Подготовить план проекта

Этап 2: Предпусковая подготовка

Wireframes

Подготовка технических спецификаций SEO

Определение приоритетных страниц

Как сканировать старый сайт

Как определить индексируемые страницы

Как определить самые эффективные страницы

Бенчмаркинг

Отслеживание рейтинга ключевых слов

Производительность сайта