Урл гугл: Sorry, this page can’t be found.

Содержание

Google «убивает» URL-адреса

Инженеры Google намерены устроить очередную реформу в интернете. Браузер Google Chrome уже искореняет протокол HTTP, помечая использующие его сайты как небезопасные и заставляя администраторов переходить на HTTPS с функцией шифрования. Как пишет Wired, что до конца второй половины 2019 года компания придумает замену стандартным URL-адресам.

Нужны ли нам URL-адреса?

Компания считает, что придуманный в 1990 году способ перехода на веб-сайты уже устарел. С развитием интернета URL-адреса стали длиннее, поэтому пользователи не всегда видят адрес сайта полностью. Это позволяет злоумышленникам заманивать их на вредоносные сайты, например, меняя домен .com на .info. Жертва может не заметить разницы и потерять важные данные.

Гарантия безопасности

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

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

История повторяется, но не стоит на месте

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

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

Чтобы оставаться в курсе событий, подписывайтесь на нашу E-mail рассылку.

Больше новостей и видео дайджестов на нашем Youtube канале. Подписывайтесь на наш Ютуб канал чтобы не пропустить новости. 

Источник: wired

Инженеры Google оставили попытки сократить URL-адреса в адресной строке — «Хакер»

Эксперимент Google, в рамках которого из адресной строки Chrome скрывали  части URL-адресов, окончательно провалился и был завершен.

Напомню, что в последние годы разработчики Chrome не раз возвращались к этой теме. К примеру, еще в 2018 году разработчики пытались в очередной сделать интерфейс браузера проще и удобнее, отказавшись от «сложных и ненужных» частей URL, которые лишь запутывают пользователей. Так, по мнению разработчиков, чтение URL-адресов усложняли отображающиеся в строке адреса мобильные поддомены, WWW и прочие элементы. Якобы людям сложно понять, какой именно части адреса нужно доверять и уделять внимание, чем, в частности, пользуются фишеры и другие преступники.

Подобное «упрощение» не понравилось многим само по себе, но специалисты также обнаружили множество багов, связанных с реализацией новой функциональности. Например, конструкция subdomain.www.domain.com не должна превращаться в subdomain.domain.com, а http://www.example.www.example.com не должен образовывать example.example.com, однако происходило именно это.

С июня 2020 года по июнь 2021 года специалисты Google проводили очередную фазу этого эксперимента. На страницу параметров chrome://flags добавили ряд параметров, после включения которых в адресной строке отображалось только основное доменное имя сайта.

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

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

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

«Данный эксперимент не повлиял на соответствующие показатели безопасности, поэтому мы не собираемся запускать [эти изменения на постоянной основе]», — пишет Эмили Старк, инженер по безопасности Chrome и одна из основных сторонниц идеи упрощения URL-адресов.

deleting a whole bunch of code that I really don’t want to delete :'(

— Emily Stark (@estark37) May 27, 2021

Это далеко не первый раз, когда Google, казалось бы, отказывается от упрощения URL. Еще в 2014 году разработчики провели первый эксперимент в этой области, который точно так же собрал исключительно негативные отзывы пользователей.

Использование IMPORTFEED в Google Таблицах для получения фида с URL

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

Функция IMPORTFEED — Синтаксис

Вот синтаксис IMPORTFEED в Google Таблицах:

IMPORTFEED(url, [query], [headers], [num_items])
  • url — это URL-адрес канала RSS или ATOM веб-сайта. Обратите внимание, что вам нужно добавить протокол http: // или https: // перед URL-адресом веб-сайта. Кроме того, URL-адрес должен быть заключен в двойные кавычки.
  • [query] — запрос, это необязательный аргумент, в котором вы можете указать, что вы хотите получить из фида. Например, вы можете получить заголовок сообщения, резюме, автора и т. Д. Если вы не укажете этот аргумент, все детали будут извлечены из ленты.
  • [headers] — заголовки, это необязательный аргумент, в котором вы можете указать, нужны ли вам заголовки или нет. Если вы сделаете это ИСТИНА, функция автоматически добавит вверху строку с заголовками. По умолчанию это ЛОЖЬ.
  • num_items — это необязательный аргумент, в котором вы можете указать количество элементов фида, которое вы хотите получить в результате. Например, вы можете использовать 5, чтобы получить последние пять сообщений из ленты. Если он не указан, извлекаются все элементы из фида.

Теперь давайте посмотрим на несколько полезных примеров использования функции IMPORTFEED в Google Таблицах.

Пример 1. Получение всех элементов из URL-адреса фида

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

Вот формула, которая будет извлекать элементы из ленты Tech Crunch:

=IMPORTFEED("https://techcrunch.com/feed",,TRUE)

Обратите внимание, что в приведенной выше формуле я привел два аргумента:

  • URL-адрес канала
  • TRUE (ИСТИНА) для заголовков, чтобы в результатах отображалась дополнительная строка с заголовком.

Ниже приведен результат.

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

Предположим, у меня есть URL-адрес канала Tech Crunch в ячейке A1, я могу использовать следующую формулу:

=IMPORTFEED(A1,,TRUE)

Вот результат:

Обратите внимание, что количество элементов по умолчанию, которые вы получаете на листе, будет варьироваться в зависимости от настроек канала. Например, в случае Tech Crunch приведенная выше формула вернет 20 элементов, как это было установлено веб-мастером Tech Crunch. С другой стороны, я установил 10 элементов по умолчанию для области производительности, и, следовательно, формула будет возвращать только последние 10 сообщений.

Пример 2 — Получение указанного количества элементов из URL-адреса фида

В приведенном выше примере формула извлекла все элементы в фиде.

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

Вот формула, которая будет извлекать пять лучших результатов из фида:

=IMPORTFEED("https://techcrunch.com/feed",,TRUE,5)

В приведенной выше формуле я указал количество элементов как 5 (это последний аргумент формулы).

Обратите внимание: если вы укажете число, превышающее количество элементов в фиде, будет возвращено только число по умолчанию. Например, в канале этой области производительности максимальное количество отображаемых элементов установлено равным 10. Даже если вы укажете аргумент num_items как 20, он все равно будет отображать только 10 каналов.

Пример 3 — Получение определенных элементов из URL-адреса фида

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

Вот формула, которая будет извлекать заголовок сообщения из URL-адреса канала:

=IMPORTFEED("https://techcrunch.com/feed","items title",TRUE)

Часть формулы «заголовок элементов» возвращает заголовки сообщений элементов в ленте.

Результат будет выглядеть, как показано ниже:

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

Вот формула, которая вернет URL из фида:

=IMPORTFEED("https://techcrunch.com/feed","items URL",TRUE)

Шаблон для отслеживания новых сообщений в Google Таблицах

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

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

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

Теперь на отдельном листе вы можете создать раскрывающийся список с названиями этих веб-сайтов (как показано ниже).

Рядом с ним вы можете использовать формулу IMPORTFEED для получения заголовка и URL-адреса канала. Ниже приведена формула, которую я использовал для получения заголовка фида:
=IMPORTFEED(VLOOKUP(A1,'Website Names'!$A$2:$B$6,2,0),"items title",TRUE,10)
Я использовал формулу VLOOKUP (ВПР) для получения URL-адреса канала на основе имени веб-сайта (массив таблиц для функции VLOOKUP находится на другом листе «Имена веб-сайтов»). Затем этот URL-адрес используется в функции IMPORTFEED для получения заголовков.

Точно так же другая функция IMPORTFEED используется в соседней ячейке для извлечения URL-адреса сообщения из канала.

Навигация по записям

Первые шаги Google по отказу от привычного URL

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

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

Пока усилия команды Chrome сводятся к тому, чтобы выяснить, как обнаруживать подозрительные URL-адреса. Для этого они разрабатывают инструмент с открытым исходным кодом TrickURI – он будет помогать разработчикам проверять, отображает ли их программное обеспечение URL точно и последовательно. Цель проекта – предоставить программистам инструмент для тестирования: чтобы они видели, как в разных ситуациях у пользователей будет отображаться URL. Кроме того, Старк вместе с коллегами работает над созданием предупреждений для пользователей Chrome, если URL будет казаться вредоносным. Проект пока находится на стадии внутреннего тестирования.

Фото: Wired

Для пользователей Google пока первой линией защиты от фишинга остается платформа Safe Browsing. Однако команда Chrome работает над дополнениями к сервису, которые в частности фокусируются на определении подозрительных URL.

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

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

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

Источник. 


Материалы по теме:

Хакеры выложили в сеть базу с 773 млн почтовых адресов и 22 млн паролей

Кибербезопасность – это не только защита от хакеров

Ваши старые твиты выдают о вас больше информации, чем вы думаете

Что такое фишинг и как от него защититься

Google Analytics: исключение URL-параметров запроса…

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

Пример url с параметрами запроса:

https://site.ru/shop/kuhonnye-stoly/?yclid=1219874450235987626&PAGEN_1=2
https://site.ru/?orderId=ad546fef-3839-7b79-b88b-503800345388&lang=ru
https://site.ru/?ThemeId=8904&iPathId=38715

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

Строка запроса

ThemeId=8904&iPathId=38715

состоит из следующих двух параметров запроса:

ThemeId=8904
iPathId=38715

Параметр запроса ThemeId=8904 состоит из ключа: ThemeId и значения: 8904.

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

Например, для Google Analytics следующая страница будет учитываться, как две разные страницы. Так как в url перехода присутствует параметр запроса с разными значениями:

https://site.ru/?ThemeId=8904
https://site.ru/?ThemeId=8905

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

Анализ отчётов с таким отображением данных сильно затрудняет работу по оптимизации сайта. Поэтому необходимо исключить параметры запроса из отчётов.
Для этого необходимо перейти в настройки представления аккаунта Гугл Аналитикс

В поле «Исключить параметры запроса URL» указать через запятую необходимые параметры запроса

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

 

Провести Аудит РК!

Подпишись и следи за выходом новых статей в нашем монстрограмме

Остались вопросы?

Не нашли ответ на интересующий Вас вопрос? Или не нашли интересующую Вас статью?  Задавайте в комментариях вопросы и темы статей, которые Вас интересуют.

Получайте бесплатные уроки и фишки по интернет-маркетингу

HTML/URL-схема «chrome://»

Синтаксис

chrome://<страница>

Описание

URL-схема «chrome://» открывает служебные страницы браузера Google Chrome или браузеров использующих движок Gecko.

Примечание

Вместо схемы «chrome://», так же возможно использование схемы «about:».


Поддержка браузерами

Chrome

Поддерж.[1]

IExplorer

Поддерж.

  • [1] ‒ ссылки с данной схемой блокируются. Схема работает только при непосредственной вставке URL в адресную строку браузера.

URL-составляющие

chrome://
Информация о браузере.

<страница>

accessibility
Доступность.
appcache-internals
Внутренние кэш приложений.
apps
Сервисы (Интернет-магазин Chrome, Документы Google, Диск Google, Gmail, Поиск Google, YouTube и так далее).
blob-internals
Внутреннее Хранилище Больших Двоичных Объектов.
bookmarks
Диспетчер закладок.
cache
Объекты находящиеся в кэш памяти.
chrome
О программе.
chrome-urls
Список URL-адресов Chrome (URL-адреса отображены в данной таблице).
components
Компоненты.
conflicts
Модули, загруженные в Google Chrome.
crashes
Страница экстренного завершения работы программы. Отчеты о сбоях.
credits
Стороннее программное обеспечение.
devices
Устройства.
dns
Список DNS с краткой информацией о них.
downloads
Скачанные файлы (загрузки).
extensions
Расширения.
flags
Экспериментальные функции.
flash
О платформе Flash.
gcm-internals
Внутренний GCM (Google Cloud Messaging) для Android.
gpu
Информация о компьютерной графике (видеокарте).
help
О программе.
histograms
Статистика, накопленная от запуска браузера до предыдущей загруженной страницы.
history
История (просмотренные страницы).
indexeddb-internals
IndexedDB.
inspect
Отображает подключённые к компьютеру устройства с включённой функцией «отладки по USB». Позволяет с компьютера управлять и производить отладку страницы на Android устройстве (в Android браузере Chrome). Подробнее…
invalidations
Аннулирования Отладочной Информации.
ipc
(Страница не доступна.)
media-internals
Медиа устройства.
memory
memory-redirect
Память, используемая открытыми браузерами.
memory-internals
Память, используемая Chrome за данный рабочий сеанс.
nacl
Информация о Native Client (Машинный/местный клиент).
net-internals
Net данные.
newtab
Новая вкладка.
omnibox
Страница Отладки Омнибокса.
password-manager-internals
Менеджер паролей.
plugins
Плагины.
policy
Правила.
predictors
Страница функции предугадания значений (автозаполнения).
print
Страница подготовки к печати.
profiler
Страница профилировщика.
quota-internals
Внутренние квоты.
serviceworker-internals
Сервисный менеджер.
settings
Настройки.
settings/autofill
Настройки автозаполнения.
signin-internals
Информация о вхождении в систему.
stats
Статистика.
suggestions
(Страница не доступна.)
sync-internals
Синхронизации.
system
О системе.
terms
Условия предоставления услуг Google Chrome.
thumbnails
Эскизы (скриншоты) сайтов.
tracing
Отслеживание.
translate-internals
Настройки перевода страниц.
user-actions
Действия Пользователя с Отладкой Страниц.
version
Сведения о версии браузера.
view-http-cache
HTTP адреса сохранённых в кэше объектов.
voicesearch
О Голосовом поиске.
webrtc-internals
WebRTC Internals.
webrtc-logs
Журналы WebRTC.
Страницы для отладки

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

crash
Страница с сообщением: «Не удалось открыть веб-страницу. Попробуйте обновить ее или перейдите на другую страницу».
crashdump
Страница с сообщением: «Веб-страница недоступна».
kill
Страница с сообщением: «Выполнение процесса этой веб-страницы было прекращено. Это может быть вызвано тем, что Chrome не хватает памяти, или иными причинами. Чтобы продолжить, обновите страницу или перейдите на другой URL».
hang
shorthang
gpuclean
gpucrash
Крах GPU.
gpuhang
Зависание GPU.
ppapiflashcrash
ppapiflashhang
quit/
Закрывает браузер.
restart/
Перезапускает браузер.

Как влияет длина URL на SEO, максимальная длина

Среди SEO-специалистов есть миф, что длина URL учитывается Google при ранжировании. Это не так. Однако его длина все равно может быть важна. В каких случаях? Рассказывает представитель Google Джон Мюллер.

Читайте также:

URL адрес документа: что это, виды и форматы указателей, советы по созданию

Длина URL и SEO

Сам Джон Мюллер предпочитает ограничивать URL 1 000 символов. Он считает, что так проще отслеживать данные. Вместе с этим он уверяет, что длина URL для Google не важна, за исключением одного случая.

Джон Мюллер, представитель Google

«Нет, длина URL не имеет значения. URL — это просто идентификатор, неважно, какой он длины. Я предпочитаю ограничивать его 1 000 символов, но лишь для упрощения отслеживания данных. Количество косых черт также не имеет значения».

Когда длина URL важна

Единственное направление, где длина URL важна — это канонизация. Когда имеется много похожих URL со схожим контентом на странице, Google будет объединять сигналы со всех страниц под одним URL.

Этот URL будет считаться каноническим, именно он и демонстрируется в поисковой выдаче.

Читайте также:

4 метатега, которые стоит использовать: Robots, Rel canonical, Hreflang, Schema.org

В процессе выбора страницы, которая будет демонстрироваться в поисковой выдаче, Google может учитывать длину URL. По словам Мюллера, система предпочитает более короткий и ясный URL.

Однако он подчеркивает, что канонизация никак не связана с ранжированием. Длина URL может повлиять только на отображение в сниппетах.

Мюллер советует выбирать структуру URL, которую будет удобно поддерживать долгое время.

Он коснулся еще одного популярного мифа — количества косых черт в URL. Некоторые считают, что URL с меньшим количеством косых черт ранжируются лучше. Однако это так же не влияет на SEO, как и длина URL.

Продвижение сайта в ТОП-10

  • Оплата по дням нахождения в ТОП
  • Подбираем запросы, которые приводят реальных покупателей!

Переместить веб-сайт и изменить URL-адрес

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

  • URL-адрес изменяется с HTTP на HTTPS
  • Изменение имени домена, например, с example.com на example.net или объединение нескольких доменов или имен хостов
  • изменений URL-адресов: пример .com/page.php?id=1 от до example.com/widget , или example.com/page.html от до example.com/page.htm
URL-адреса не меняются? Если вы вносите изменения на сайт без видимых изменений URL, вместо этого начните здесь.

Обзор

  1. Базовый обзор информация о перемещении сайта . Знайте, чего ожидать и как это может повлиять ваши пользователи и рейтинг. При переходе с HTTP на HTTPS просмотрите лучшие практики для HTTPS.
  2. Подготовьте новый сайт и тщательно протестируйте его.
  3. Подготовить сопоставление URL-адресов из текущих URL-адресов с соответствующий им новый формат.
  4. Запустите перемещение сайта , настроив сервер на перенаправить со старых URL на новые.
  5. Мониторинг трафика как по старому, так и по новому URL.

Часто задаваемые вопросы по всем перемещениям сайта с изменением URL

  • Рекомендует ли Google перемещать все вместе или можно перемещать по частям?
    Перемещение по секциям нормально.
  • Как проверить, сколько страниц было проиндексировано?
    Проверяйте данные по каждому ресурсу отдельно в Search Console. Использовать Статус индекса доклад для широкого взгляда. Использовать карты сайта отчет, чтобы просмотреть, сколько URL-адресов, представленных в карте сайта, было проиндексировано.
  • Сколько времени потребуется Google, чтобы распознать изменения URL?
    Фиксированных частот сканирования нет; это зависит от размера вашего сайта и скорости ползание это возможно.Перемещение происходит для каждого URL-адреса.
  • Вы теряете кредит для ссылок при перенаправлении на новые URL-адреса?
    Нет, перенаправления 301 или 302 не приводят к потере PageRank.

Миграция с HTTP на HTTPS

  • Ознакомьтесь с рекомендациями по HTTPS.
  • Обязательно добавьте свойство HTTPS в Search Console. Консоль поиска обрабатывает HTTP и HTTPS отдельно; данные для этих ресурсов не публикуются в Search Console.Поэтому, если у вас есть страницы в обоих протоколах, у вас должен быть отдельный ресурс Search Console для каждый.

Часто задаваемые вопросы о переходе с HTTP на HTTPS

Повлияет ли эта миграция HTTPS на ранжирование?

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

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

Можно ли перенести только некоторые страницы на HTTPS?

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

Если вы переходите с HTTP на HTTPS по частям и хотите избежать индексация поэтапных URL-адресов, мы рекомендуем использовать rel=canonical , а не перенаправления.Если вы используете перенаправления, вы не сможете протестировать перенаправленные страницы.

Будет ли тег
rel=canonical гарантировать, что URL-адрес HTTP индексируется?

Нет, но это очень сильный сигнал при выборе проиндексированного URL.

Какой сертификат рекомендует Google?

Для поиска Google допустим любой современный сертификат, который принимается современными браузерами.

Изменяются ли ключевые слова для поиска после перехода на HTTPS?

Это не изменится с HTTPS; вы по-прежнему можете видеть поисковые запросы в Search Console.

Как проверить, сколько страниц было проиндексировано?

Подтвердите HTTP и HTTPS отдельно в Search Console и используйте Показатель Отчет о покрытии, чтобы увидеть, какие страницы были проиндексированы.

Сколько времени займет переход с HTTP на HTTPS?

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

Мы ссылаемся на наши карты сайта HTTP в файле robots.txt. Должны ли мы обновить файл robots.текст на включить наши новые карты сайта HTTPS?

Мы рекомендуем отдельные файлы robots.txt для HTTP и HTTPS. Каждый файл robots.txt должен указывать на отдельный файл карты сайта. Мы также рекомендуем перечислить каждое конкретное URL вашего сайта только в одной карте сайта.

Какая карта сайта должна отображать раздел в пробной версии HTTPS?

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

Какие URL-адреса должны быть указаны в наших картах сайта, если у нас есть перенаправления (с HTTP на HTTPS или обратный)?

Перечислите все URL-адреса HTTP в карте сайта HTTP и все URL-адреса HTTPS в карте сайта HTTPS, независимо от редиректов, когда пользователь посещает страницу.Наличие страниц в вашем Карта сайта независимо от редиректов поможет поисковым системам обнаружить новые URL-адреса. Быстрее.

Есть ли какие-либо другие конкретные вещи, которые нам нужно добавить в robots.txt для HTTPS? версия?
Должны ли мы поддерживать HSTS?

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

Мы используем единую карту сайта Новостей Google для всего нашего сайта. Что нам делать, если мы переносите наш сайт по частям?

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

Есть ли конкретные рекомендации по Центр издателей Новостей Google с миграцией HTTPS?

Google News Publisher Center прозрачно обрабатывает переходы с HTTP на HTTPS. В как правило, вам не нужно ничего делать с точки зрения Новостей Google, если только вы не также используя файлы Sitemap для новостей.В таком случае, связаться с командой новостей и сообщить им об изменении. Вы также можете сообщить команде об изменении разделы, например, если вы переходите на HTTPS, вы можете указать, что вы перемещение http://example.com/section в https://example.com/section .

Подготовить новый сайт

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

  • Настройте новую систему управления контентом (CMS) и добавьте в нее контент.
  • Передача изображений и загрузок (например, PDF-документов), которые вы сейчас размещаете.
    Возможно, они уже получают трафик из поиска Google или ссылок, и полезно сообщить пользователям и роботу Googlebot об их новом местоположении.
  • Для перехода на HTTPS получите и настройте необходимые сертификаты TLS на своем сервере.

Настройте файл robots.txt для вашего нового сайта

Файл robots.txt для сайта определяет, какие области может сканировать робот Googlebot.Убедитесь, что директивы в файле robots.txt нового сайта правильно отражают части, которые вы хотите заблокировать от ползания.

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

Укажите ошибки для удаленного или объединенного содержимого

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

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

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

Проверьте правильность настроек Search Console

Успешный перенос сайта зависит от правильных и актуальных настроек Search Console.

Если вы еще этого не сделали, подтвердите что у вас есть как старый, так и новый сайты в Search Console.Обязательно проверьте все варианты как старого, так и нового сайтов. Например, проверить www.example.com и example.com , включая HTTPS и Варианты сайта HTTP, если вы используете URL-адреса HTTPS. Сделайте это как для старых, так и для новых сайтов.

Просмотрите подтверждение Search Console

Убедитесь, что ваша проверка Search Console продолжит работать после переноса сайта. Если вы используете другой метод подтверждения, имейте в виду, что токены подтверждения могут отличаться при изменении URL.

Если вы используете HTML file, чтобы подтвердить право собственности на свой сайт в Search Console, убедитесь, что вы не забудьте включить текущий файл подтверждения в новую копию сайта.

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

Просмотрите все настроенные параметры в Консоль поиска

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

  • URL параметры: если вы настроили параметры URL для управления сканированием или индексированием ваши старые URL-адреса, убедитесь, что настройки также применяются к новому сайту, если это необходимо.
  • Геотаргетинг: Ваш старый сайт может иметь явный геотаргетинг, например домен с геотаргетингом или национальный домен верхнего уровня (например, .co.uk ). Примените ту же настройку к новый сайт, если вы хотите продолжить таргетинг на тот же регион.Однако, если ваш сайт move призван помочь вашему бизнесу расширяться по всему миру, и вы не хотите, чтобы ваш сайт связанный с какой-либо страной или регионом, выберите Unlisted в раскрывающемся списке список на странице настроек сайта.
  • Скорость сканирования: Мы рекомендуем не ограничивать скорость сканирования Googlebot в Search Console как для старых, так и для новые URL-адреса. Мы также рекомендуем не настраивать скорость сканирования. Только сделать это если вы знаете, что ваш сайт не может справиться с объемом сканирования роботом Googlebot.Если у тебя есть уже ограничил скорость сканирования вашего старого сайта роботом Googlebot, рассмотрите возможность его удаления. У Google есть алгоритмы, которые автоматически определяют, что перемещение сайта было осуществлено, и мы изменяем Поведение робота Googlebot при сканировании, чтобы наше индексирование быстро отражало перемещение сайта.
  • Отклонено обратные ссылки: если вы загрузили файл для отклонения ссылок на своем старом сайте, мы рекомендуем что вы повторно загрузите его, используя учетную запись Search Console нового сайта.
Очистите недавно купленный домен

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

  • Руководство действие для предыдущего спама. Для сайтов, которые не соответствуют нашим Веб-мастер Руководящие принципы, Google готов принять ручные меры, например понизить их или даже полное удаление их из наших результатов поиска.Проверьте страницу «Действия вручную» в поиске. Консоль, чтобы узнать, применялись ли какие-либо ручные действия к новому сайту, и устранить любые проблемы, перечисленные там до подачи пересмотр запрос.
  • Удалено URL-адреса. Убедитесь, что от предыдущего владельца не осталось удалений URL, особенно удаление URL-адресов для всего сайта. Кроме того, перед отправкой запросов на удаление URL для вашего содержание, убедитесь, что вы понимаете когда не использовать инструмент удаления URL.

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

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

Убедитесь, что на вашем сервере достаточно вычислительных ресурсов

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

Обновление маркера данных

Если вы использовали Данные Маркер для сопоставления ваших старых страниц, обязательно повторите сопоставление для вашего нового сайта.

Обновление ссылок на приложения

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

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

Подготовить сопоставление URL

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

1.Определите ваши текущие URL-адреса

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

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

  • Начните с важных URL-адресов .Чтобы найти их:
    • Посмотрите в своих картах сайта потому что наиболее важные URL-адреса, скорее всего, были отправлены в Search Console таким образом
    • Проверьте журналы вашего сервера или аналитическое программное обеспечение на наличие URL-адресов, которые получают наибольший трафик
    • Проверить ссылки на функцию вашего сайта в Search Console для страниц с внутренними и внешними ссылками
  • Используйте свою систему управления контентом, которая обычно обеспечивает простой способ получения список всех URL-адресов, на которых размещен контент.
  • Проверьте журналы сервера на наличие URL-адресов, которые недавно посещались хотя бы один раз. Выберите период времени, который имеет смысл для вашего сайта с учетом сезонных колебаний трафика.
  • Включить изображения и видео — Убедитесь, что вы включили URL встроенного контента в планы перемещения вашего сайта: видео, изображения, файлы JavaScript и CSS. Эти URL необходимо переместить так же, как и весь другой контент на вашем веб-сайте.

2. Создать сопоставление старых и новых URL-адресов

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

3. Обновить все сведения об URL

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

  1. Обновление аннотаций в записи HTML или карты сайта для каждой страницы:
    1. Каждый целевой URL должен иметь ссылку на себя rel="canonical" <ссылка> тег.
    2. Если сайт, который вы переместили, содержит многоязычные или многонациональные страницы, аннотированные с помощью rel-alternate-hreflang аннотаций, обязательно обновите аннотации, чтобы использовать новые URL-адреса.
    3. Если сайт, который вы переместили, имеет мобильный аналог, обязательно обновите rel-alternate-media аннотаций.Узнайте больше в наших рекомендациях по веб-сайтам для смартфонов.
  2. Обновление внутренних ссылок.
    Измените внутренние ссылки на новом сайте со старых URL-адресов на новые URL-адреса. Вы можете использовать сопоставление, созданное ранее, чтобы помочь найти и обновить ссылки по мере необходимости.
  3. Создание и сохранение карты сайта и списков ссылок.
    Сохраните следующие списки для вашего последнего хода:
    • Файл карты сайта, содержащий новые URL-адреса в сопоставлении
    • Файл карты сайта, содержащий старые URL-адреса в сопоставлении
    • Список сайтов, ссылающихся на ваш текущий контент

    Узнайте больше о картах сайта.

4. Подготовьтесь к 301 редиректу

Когда у вас есть сопоставление и ваш новый сайт готов, следующим шагом будет настройка HTTP 301 перенаправляет на ваш сервер от старых URL-адресов к новым URL-адресам, как вы указали в своем сопоставлении.

Имейте в виду следующее:

  • Использовать переадресацию HTTP 301. Хотя робот Googlebot поддерживает несколько видов перенаправлений, мы рекомендуется использовать перенаправления HTTP 301, если это возможно.
  • Избегайте цепочек перенаправлений. Хотя робот Googlebot и браузеры могут следовать «цепочке» несколько перенаправлений (например, Страница 1 > Страница 2 > Страница 3), мы рекомендуем перенаправлять на пункт назначения. Если это невозможно, оставьте количество редиректов в цепочке низкий, в идеале не более 3 и менее 5. Цепочка перенаправлений увеличивает задержку для пользователей, и не все браузеры поддерживают длинные цепочки перенаправлений.
  • Проверить перенаправления. Вы можете использовать Инструмент проверки URL для тестирования отдельных URL-адресов или инструментов командной строки или сценариев для тестирования больших чисел или URL-адреса.

Начать перемещение сайта

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

  1. Решите, как вы будете перемещать свой сайт — все сразу или по частям:
    • Малые и средние сайты: Мы рекомендуем переместить все URL-адреса на вашем сайте одновременно, вместо того, чтобы перемещать одну секцию за раз.Это помогает пользователям взаимодействовать с сайт лучше в новой форме и помогает нашим алгоритмам обнаруживать перемещение сайта и обновить наш индекс быстрее.
    • Крупные сайты: Вы можете перемещать более крупные сайты по одному разделу за раз. время. Это может упростить мониторинг, обнаружение и быстрое устранение проблем.
  2. Обновите файлы robots.txt :
    • На старом сайте удалить все роботов.txt директивы. Это позволяет роботу Googlebot обнаруживать все перенаправления на новый сайт и обновлять наш индекс.
    • На новом сайте убедитесь, что файл robots.txt разрешает все сканирование. Это включает сканирование изображений, CSS, JavaScript и других страниц. активы, за исключением URL-адресов, которые вы точно не хотите сканировать.
  3. Настройте старый веб-сайт на перенаправления пользователей и Googlebot на новый сайт на основе сопоставления URL.
  4. Отправить Изменение адреса в Search Console для старого сайта . Если вы переводите свой сайт с HTTP на HTTPS, вам не нужно использовать Средство смены адреса .
  5. На старом сайте отправьте две карты сайта, которые вы подготовили ранее содержащие старый и новый URL-адреса. Это помогает нашим сканерам обнаруживать перенаправления со старого URL-адреса на новые URL-адреса и облегчает перемещение сайта.
  6. Сохраняйте перенаправления как можно дольше , обычно не менее 1 года. Этот временной интервал позволяет Google передавать все сигналы на новые URL-адреса, включая повторное сканирование. и переназначение ссылок на другие сайты, которые указывают на ваши старые URL-адреса.

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

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

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

Обновление входящих ссылок

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

  • Внешние ссылки: попробуйте связаться с сайтами в сохраненном списке сайтов, ссылающихся на ваш текущий содержание, попросив их обновить свои ссылки на ваш новый сайт. Подумайте о том, чтобы расставить приоритеты усилия по количеству входящих посещений по каждой ссылке.
  • Ссылки на профили, такие как Facebook, Twitter и LinkedIn.
  • рекламных кампаний, указывающих на новые целевые страницы.

Мониторинг трафика

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

Используйте Search Console для мониторинга трафика

Многие функции Search Console помогают отслеживать перемещение сайта, в том числе:

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

Использование других инструментов для мониторинга трафика

Следите за доступом к серверу и журналами ошибок.В частности, проверьте на сканирование Googlebot, любые URL-адреса, которые неожиданно возвращают коды состояния ошибки HTTP, и обычный пользовательский трафик.

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

Устранение неполадок при перемещении сайта

Ниже приведены некоторые распространенные ошибки при переносе сайта с изменением URL-адреса (в том числе с HTTP на HTTPS). Эти ошибки могут помешать полной индексации вашего нового сайта.

Распространенные ошибки

noindex или блоки robots.txt

Не забудьте удалить все noindex или robots.txt блоки, которые были только нужно для миграции.

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

Для проверки:

  • Изучите файл robots.txt на своем HTTPS-сайте и посмотрите, нужно ли что-то измененный.
  • Использовать проверку URL инструмент для любых страниц, которые кажутся отсутствующими в Google на новом сайте.

Неправильные перенаправления

Проверьте перенаправления со старого сайта на новый. Мы часто видим людей перенаправление на неправильные (несуществующие) URL-адреса на новом сайте.

Другие ошибки сканирования

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

Недостаточная мощность

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

Не обновляются ссылки на приложения

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

Карты сайта не обновляются

Убедитесь, что все ваши карты сайта обновлены новыми URL-адресами.

Выделение данных не обновляется

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

Сохраняйте простую структуру URL  | Документация  | Разработчики Google

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

По возможности используйте в URL-адресах читаемые слова, а не длинные идентификационные номера.

Рекомендуется — простые описательные URL-адреса:

 http://en.wikipedia.org/wiki/Авиация 

Не рекомендуется — сложные, неописательные URL:

 https://www.example.com/index.php?id_sezione=360&sid=3a5ebc944f41daa6f849f730f1 

Рассмотрите возможность использования знаков препинания в URL-адресах. Это помогает пользователям и поисковым системам идентифицировать концепции в URL проще.

Рекомендуемые — ключевые слова в URL, разделенные пунктуация:

 https://www.example.com/green-dress 

Не рекомендуется — ключевые слова в URL объединены вместе:

 https://www.example.com/greendress 

Мы рекомендуем использовать дефисы ( - ) вместо подчеркивания ( _ ) в ваши URL-адреса.

Рекомендуется — дефисы ( - ):

 https://www.example.com/summer-clothing/filter?color-profile=темно-серый 

Не рекомендуется — символы подчеркивания ( _ ):

 https://www.example.com/summer_clothing/filter?color_profile=dark_grey 

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

Распространенные причины этой проблемы

Слишком большое количество URL-адресов может быть вызвано рядом проблем. К ним относятся:

  • Аддитивная фильтрация набора элементов. Многие сайты предоставляют разные представления один и тот же набор элементов или результатов поиска, что часто позволяет пользователю фильтровать этот набор с помощью определенные критерии (например: покажите мне отели на пляже).Когда фильтры можно комбинировать аддитивно (например: отели на пляже и с фитнес-центром), количество URL-адресов (представлений данных) на сайтах резко возрастает. Создание большого количества немного отличающихся друг от друга списки отелей избыточны, так как роботу Googlebot нужно просмотреть только небольшое количество списков из которой он может достичь страницы для каждого отеля. Например:
    • Гостиничная недвижимость по «стоимостным ценам»:
       https://www.example.com/hotel-search-results.jsp?Ne=292&N=461 
    • гостиничных объектов на пляже по выгодным ценам:
       https://www.example.com/hotel-search-results.jsp?Ne=292&N=461+4294967240 
    • гостиничных объектов по выгодным ценам на пляже и с фитнес-центром:
       https://www.example.com/hotel-search-results.jsp?Ne=292&N=461+4294967240+4294967270 
  • Динамическое формирование документов. Это может привести к небольшим изменениям, поскольку счетчиков, временных меток или рекламы.
  • Проблемные параметры в URL. Идентификаторы сеанса, например, могут создавать огромное количество дублирования и большее количество URL-адресов.
  • Параметры сортировки. Некоторые крупные торговые сайты предоставляют несколько способов сортировать одни и те же элементы, что приводит к гораздо большему количеству URL-адресов. Например:
     https://www.example.com/results?search_type=search_videos&search_query=tpb&search_sort=relevance&search_category=25 
  • Нерелевантные параметры в URL-адресе, такие как параметры перехода. Например:
     https://www.example.com/search/noheaders?click=6EE2BF1AF6A3D705D5561B7C3564D9C2&clickPage=OPD+Product+Page&cat=79 
     https://www.example.com/discuss/showthread.php?referrerid=249406&threadid=535913 
     https://www.example.com/products/products.asp?N=200063&Ne=500955&ref=foo%2Cbar&Cn=Аксессуары. 
  • Проблемы с календарем. Динамически созданный календарь может генерировать ссылки на будущие и предыдущие даты без ограничений по датам начала и окончания. Например:
     https://www.example.com/calendar.php?d=13&m=8&y=2011 
  • Неработающие относительные ссылки. Неработающие относительные ссылки часто могут приводить к бесконечным пространства.Часто эта проблема возникает из-за повторяющихся элементов пути. Например:
     https://www.example.com/index.shtml/discuss/category/school/061121/html/interview/category/health/070223/html/category/business/070302/html/category/community/070413/html /FAQ.htm 

Решить эту проблему

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

  • Рассмотрите возможность использования файла robots.txt, чтобы заблокировать доступ робота Googlebot к проблемным URL-адресам.Как правило, рассмотрите возможность блокировки динамических URL-адресов, таких как URL-адреса, которые генерируют поиск результаты или URL-адреса, которые могут создавать бесконечные пространства, такие как календари. Используя обычные выражения в файле robots.txt позволяют легко блокировать большое количество URL-адресов.
  • По возможности избегайте использования идентификаторов сеансов в URL-адресах. Вместо этого рассмотрите возможность использования файлов cookie. Проверьте нашего веб-мастера Руководство по дополнительной информации.
  • По возможности сокращайте URL-адреса, удаляя ненужные параметры.
  • Если на вашем сайте есть бесконечный календарь, добавьте nofollow атрибут для ссылок на динамически создаваемые будущие страницы календаря.
  • Проверьте свой сайт на неработающие относительные ссылки.

Инструмент параметров URL Google прекращает свое существование

Компания Google объявила о том, что инструмент параметров URL прекращает свое существование в следующем месяце, сославшись на то, что этот инструмент имеет небольшую или низкую ценность. Google отключит эту функцию 26 апреля 2022 г., и после этой даты вы больше не сможете получить доступ к инструменту.

Что такое инструмент параметра URL. Инструмент параметров URL, запущенный в 2009 году как инструмент обработки параметров, способ сообщить Google, чтобы он игнорировал определенные URL-адреса или комбинации параметров URL-адресов. Два года спустя, в 2011 году, Google обновил инструмент, чтобы обрабатывать гораздо больше сценариев параметров.

Инструмент, по сути, позволяет запретить Google индексировать URL-адреса на вашем сайте.

В настоящее время вы можете получить доступ к инструменту здесь до 26 апреля.

Почему он уходит. В Google заявили, что «намного лучше угадывают, какие параметры полезны на сайте, а какие — попросту говоря — бесполезны». Google добавил, что «только около 1% конфигураций параметров, которые в настоящее время указаны в инструменте параметров URL, полезны для сканирования». «Из-за низкой ценности этого инструмента как для пользователей Google, так и для пользователей Search Console мы прекращаем поддержку инструмента «Параметры URL» через 1 месяц», — заявили в Google.

Что мне делать дальше. Гугл сказал, что делать особо нечего.Google сказал: «В будущем вам не нужно ничего делать, чтобы указать функцию параметров URL на вашем сайте, сканеры Google научатся работать с параметрами URL автоматически». Google сказал, что вы всегда можете использовать правила robots.txt «или использовать hreflang , чтобы указать языковые варианты контента», добавил Google. Кроме того, Google заявил, что ваши CMS и платформы в наши дни обрабатывают качественные URL-адреса.

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


Новое в Search Engine Land

Об авторе

Барри Шварц, пишущий редактор Search Engine Land и член группы программистов для мероприятий SMX.Он владеет RustyBrick, нью-йоркской веб-консалтинговой фирмой. Он также ведет Search Engine Roundtable, популярный поисковый блог по очень сложным темам SEM. Личный блог Барри называется Cartoon Barry, и за ним можно следить в Твиттере здесь.

Формат шаблона URL-адреса корпоративной политики

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

Допустимые спецификации шаблона имеют одну из следующих форм (без кавычек):

  • «*»
    • Этот шаблон соответствует любому URL-адресу с любой схемой, портом и путем.
  • «схема://домены:порт/путь»
    • Поддерживаются схемы «http» и «https».
    • Схему можно не указывать вместе с разделителем схем «://», чтобы соответствовать любой схеме. В качестве альтернативы для того же эффекта можно использовать подстановочный знак «*».
    • За доменом следует домен верхнего уровня, перед которым может стоять один или несколько поддоменов. В качестве альтернативы можно использовать хост (например, localhost).
      • Домен может иметь префикс подстановочного знака «[*.]», чтобы соответствовать домену или любому из его поддоменов. Рассматриваемый домен может быть поддоменом любого уровня. Обратите внимание на тот факт, что за подстановочным знаком «[*.]» не следует точка, и он должен ставиться непосредственно перед доменом/субдоменом.
      • Домен без подстановочного префикса будет соответствовать только этому домену, а не каким-либо субдоменам.
    • Номер порта находится в диапазоне 0-65535. Его можно опустить вместе с разделителем портов «:» или заменить подстановочным знаком «*» для соответствия любому порту.
    • Точно так же путь можно опустить вместе с разделителем частей «/» или заменить подстановочным знаком «*», чтобы он соответствовал любому пути.
    • Подстановочные знаки нельзя использовать для частичного соответствия схеме, домену, хосту, порту или пути.
    • Поддерживается использование нескольких подстановочных знаков в одном шаблоне (например, *://google.com:*/*).
  • «схема://a.b.c.d:port/path»
    • Вместо домена IPv4-адрес в виде «a.b.c.d» можно использовать. Хотя правила для схем, портов и путей остаются такими же, как и для URL-адресов домена, подстановочные знаки вообще нельзя использовать для IP-адресов.
  • «схема://[a:b:c:d:e:f:g:h]:port/path»
    • Адрес IPv6 также может использоваться в форме «[a:b:c :d:e:f:g:h]». Скобки обязательны. Как и в случае с адресами IPv4, подстановочные знаки не поддерживаются. Правила для схем, портов и путей остаются такими же, как и для доменных URL-адресов и адресов IPv4.
  • «file://path»
    • Если используется схема «file», путь должен начинаться с «/», поэтому «file://dir/myfile.html» является недопустимым шаблоном. Вместо этого необходимо использовать «file:///dir/myfile.html» (с тремя косыми чертами после «file:»). Единственным допустимым подстановочным знаком URL-адреса файла является «file:///*», который соответствует любому допустимому URL-адресу файла.
    • Доменная часть URL-адреса файла должна быть пустой и соответствовать любому домену (или локальному хосту).Например, «file:///file.html» будет соответствовать «file://localhost/file.html» и «file://mysite.com/file.html».
    • Порты использовать нельзя.

Лучше всего, чтобы Google обнаружил ваш новый сайт с внешними ссылками по отправке URL-адреса

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

Джон Мюллер сказал мне, что в прошлую пятницу на видеовстрече на отметке 7:56. Я объяснил, что завел совершенно новый блог, а не SEO (у меня уже есть два таких). Блог называется Lucid Insider — он посвящен новому производителю электромобилей Lucid Motors и его первому седану EV под названием Lucid Air. Итак, я начал вести блог пару недель назад, в основном потому, что хотел снова начать что-то совершенно новое с нуля и посмотреть, как это пойдет.Конечно, это поможет мне с контекстом для моего SEO-текста, но также будет интересно просто начать что-то новое.

Итак, я спросил Джона, рекомендует ли он отправлять новые URL-адреса по мере их публикации с помощью инструмента проверки URL-адресов Google Search Console, запрашивать функцию индексации? Это для нового блога, без ссылок на него, с XML-картой сайта.

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

Затем он пошутил, что я знаю некоторые блоги, на которые я могу ссылаться, сказав: «Так что, вероятно, вы знаете кого-то еще, кто ведет блог, и вы можете работать вместе с ними и, возможно, получить ссылку на свой сайт — что-то в этом роде. Это, вероятно, сделает намного больше, чем переход в консоль поиска с сообщением, что я хочу, чтобы этот URL был проиндексирован.»

Итак, я сказал, нет, я хочу, чтобы это произошло естественным образом. Так что это может быть первая ссылка на блог Lucid Insider, но прямо сейчас он получает трафик через социальные сети. Сообщество Lucid напоминает мне о первых днях SEO-сообщество — теперь инсайдеры знают о блоге. Вторник, 18 сентября 2012 г. • Обновлено

Разрешения хоста и сопоставление сценариев контента основаны на наборе URL-адресов, определяемых шаблонами соответствия.Шаблон сопоставления — это URL-адрес, начинающийся с разрешенной схемы ( http , https , file или ftp , который может содержать символы ‘ * ‘. Специальный шаблон соответствует любому URL-адресу, который начинается с разрешенной схемы. Каждый шаблон соответствия состоит из 3 частей:

  • схема — например, http или файл или *

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

  • хост — например, www.google.com или *.google.com или * ; если схема файл , то хост часть

  • путь отсутствует — например, /* , /foo* , или /foo* . Путь должен присутствовать в разрешении хоста, но всегда рассматривается как /* .

Вот основной синтаксис:

   := <схема>://<хост><путь> 
<схема> := '*' | 'http' | 'https' | 'файл' | 'фтп' | 'urn'
<хост> := '*' | '*.' <любой символ, кроме '/' и '*'>+
:= '/' <любые символы>

Значение ‘ * ‘ зависит от того, находится ли он в схеме , хост , или путь часть. Если схема это *, то ей соответствует либо http либо https , а не файл , ftp , или urn .Если хост — это просто * , то он соответствует любому хосту. Если хост — это *._hostname_ , то он соответствует указанному хосту или любому из его поддоменов. В разделе пути каждый « * » соответствует 0 или более символам. В следующей таблице показаны некоторые допустимые шаблоны.

Примечание: URN Схема доступна с Chrome 91.

Узор Что он делает Примеры сопоставления URL
HTTPS: // * / * соответствует любому URL использует схему https https://www.google.com/
https://example.org/foo/bar.html
https://*/foo* Соответствует любому URL-адресу, который использует схему https на любом хосте, как пока путь начинается с /foo https://example.com/foo/bar.html
https://www.google.com/foo
https://*.google .com/foo*bar Соответствует любому URL-адресу, который использует схему https и находится на хосте google.com (например, www.google.com, docs.google.com или google.com), если путь начинается с /foo и заканчивается bar https://www.google.com/foo/baz/bar
https://docs.google.com/foobar
https://example.org/foo/bar.html Соответствует указанному URL-адресу https://example.org/foo/bar .html
file:///foo* Соответствует любому локальному файлу, путь которого начинается с /foo file:///foo/bar.html
file:///foo
http://127.0.0.1/* Соответствует любому URL, использующему схему http и находящемуся на хосте 127.0.0.1 0 http://127.0.0.1 http://127.77 .0.1/
http://127.0.0.1/foo/bar.html
*://mail.google.com/* Соответствует любому URL-адресу, который начинается с http://mail.google .com или https://mail.google.com . http://mail.google.com/foo/baz/bar
https://mail.google.com/foobar
urn:* Соответствует любому URL-адресу, который начинается с urn: . URN: UUID: 54723BEA-C94E-480E-80C8-A69846C3F582
URN: UUID: CFA40AFF-07DF-45B2-9F95-E023BCF4A6DA
соответствует любому URL-адресу, которое использует разрешенную схему. (См. в начале этого раздела список разрешенных схем.) http://example.org/foo/bar.html
file:///bar/baz.html

Вот несколько примеров из неверный шаблон соответствует:

Неверный шаблон Почему это плохо
https://www.google.com No path
https://*foo/bar ‘*’ на хосте может сопровождаться только знаком ‘.’ или ‘/’
https://foo.*.bar/baz Если ‘*’ находится в хосте , это должен быть первый символ
0 http:0/bar Отсутствует разделитель схемы ("/" должен быть "//")
foo://* Недопустимая схема

Говорите как гуглер: части URL

Гм, вся эта статическая/динамическая штука… наверняка она распадается на две части? Страницы и URL, ведущие на них. Каждый из них может быть статическим или динамическим.

Технология того, как URL доставляет веб-страницу, я думаю, не имеет значения. Я могу настроить сервер Apache таким же образом, чтобы он отвечал на запросы index.shtml, index.asp, index.htm, и мне решать, как будет обслуживаться это содержимое — из файла, включенных файлов или полностью вне базы данных.Так что я могу (и делаю) радостно доставлять index.asp из полностью статического файла или index.html как страницу, управляемую исключительно базой данных, неотличимую от файла.

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

Статические URL-адреса и динамические URL-адреса отличаются тем, что один или несколько параметров влияют на страницу, которую вы в конечном итоге видите. Для многих (большинства?) Интернет-магазинов и некоторых (обычно более старых CMS) вы выбираете страницу или продукт, сохраняя прежний корневой URL-адрес и изменяя параметр; изменение «?pageid=XXXXX» или подобное. Вы получаете другую страницу в результате изменения *только* параметра.

Если изменение или удаление параметров приводит к тому же содержимому страницы (по модулю динамических частей, таких как AJAX), то параметры не делают URL-адрес динамическим.Если изменение или удаление параметров приводит к другому содержимому (например, вы видите корень интернет-магазина или другой продукт), то это динамический URL-адрес. Если файл cookie изменяет запрошенный вами контент… это тоже динамический контент.

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

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

Прошло много лет с тех пор, как я читал «Дублинское ядро»… Разве это не «Идентификатор»?

Мэтт. Вы проверяете приемлемость предложения веб-мастерам приблизиться к Dublin Core? Там определенно есть кое-что, что может помочь улучшить индексы для сотрудничающих сайтов.

Leave a Reply