Как сделать ссылку в html на другую страницу: Правила вложений для тега

Согласно Руководству Google для веб-мастеров, любые ссылки, за которые вы платите, должны иметь статус nofollow (или использовать более новый атрибут «rel=sponsored»).

(Почему? Google хочет, чтобы все ваши ссылки были заработаны .)

Например, если вы платите за рекламный баннер на веб-сайте, Google требует, чтобы ссылка в баннере была nofollow.

В противном случае Big G может оштрафовать ваш сайт.

Помогают ли ссылки Nofollow в SEO?

Некоторые люди говорят: «Ссылки nofollow не влияют на SEO».

Другие утверждают: «Ссылки nofollow не так эффективны, как ссылки dofollow… но они все равно помогают».

Что правда?

Во-первых, что говорит Google о ссылках nofollow?

«Вообще мы за ними не следим».

«Вообще»?

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

Далее давайте рассмотрим действительно интересный пример.

Адам Уайт хотел ранжировать свой блог по ключевому слову «программное обеспечение для обратных ссылок».

Что он сделал?

Он купил кучу nofollow-ссылок на качественном сайте в сфере SEO.

И все эти ссылки имели в качестве анкорного текста «программное обеспечение для обратных ссылок».

Итак: что случилось?

Его рейтинг подскочил с 19-го места… до 1-го места в Google по его целевому ключевому слову.

В-третьих, давайте проверим еще один классный маленький эксперимент.

На этот раз руководитель SEO-отдела SurveyMonkey решил ответить на вопрос: «Действительно ли Google переходит по nofollow-ссылкам».

Чтобы выяснить это, он добавил ссылку nofollow на одну из 404 страниц SurveyMonkey.

Эта ссылка вела на страницу, которая еще не была проиндексирована.

Теоретически Google должен игнорировать эту ссылку.

Но этого не произошло.

Вместо этого Google перешел по ссылке… и проиндексировал страницу в течение 48 часов.

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

И они обнаружили, что как dofollow, так и общее количество обратных ссылок (включая ссылки nofollow) оказывают одинаковое влияние на ранжирование.

Итог? Ссылки nofollow, кажется, имеют некоторую ценность для SEO… особенно если эти ссылки с связанных сайтов. Google также может использовать анкорный текст из ссылок nofollow в своем алгоритме.

Каковы преимущества ссылок Nofollow?

Давайте посмотрим:

1. Ссылки nofollow могут напрямую помочь вам в SEO.

Как вы только что видели, эксперименты и отраслевые исследования показали, что ссылки nofollow могут привести к более высокому рейтингу в Google. Хотя данные об этом не ясны.

2. Ссылки nofollow могут принести вам трафик.

Не забывайте: правильная ссылка nofollow может направлять целевой трафик на ваш сайт.

Например, я разместил это на Facebook некоторое время назад:

Как видите, там есть ссылка nofollow на мой сайт.

Поможет ли этот тип ссылки nofollow в моем SEO?

Вероятно, нет.

Тем не менее, ссылка прислала мне 2745 посетителей:

Тот же подход применим к оставлению полезных комментариев в блоге.

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

(Особенно, если вы один из первых, кто прокомментирует пост.)

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

И эти комментарии принесли мне горстку целевых посетителей.

3. Ссылки nofollow могут = ссылки dofollow.

Nofollow с популярного сайта может привести к десяткам ссылок dofollow.

Поясню на примере…

Недавно я написал гостевой пост для блога Ноа Кагана.

Я не уверен на 100%, почему, но Ной nofollows все его исходящие ссылки…

….включая обратную ссылку на мой сайт.

Значит, эта ссылка совершенно бесполезна?

К счастью, нет.

Я получил кучу реферального трафика с этого поста.

Но что еще более важно:

Многие люди, которые нашли меня по этому посту, в конечном итоге ссылались на меня:

(С dofollow-ссылками.)

И эти dofollow-ссылки действительно помогли моему рейтингу в поисковой выдаче.

Давайте рассмотрим еще один пример…

Некоторое время назад я опубликовал масштабное исследование факторов ранжирования в Google.

Благодаря успешной PR-кампании мое исследование попало в Forbes.com.

Но эта ссылка была… nofollow.

К счастью, многие люди читают мое исследование благодаря этой ссылке nofollow.

И эти люди процитировали мое исследование в своем блоге… со ссылками dofollow:

4. Ссылки nofollow являются частью профиля естественных ссылок.

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

Как оказалось, nofollow-ссылки являются важной частью естественного ссылочного профиля.

Например, посмотрите на YouTube.

По данным Semrush, 23% их ссылок являются nofollow.

Это не значит, что вам нужно, чтобы 23% ваших ссылок были nofollow.

Это просто показывает, что профили с естественными ссылками имеют приличное количество ссылок nofollow.

В чем разница между Nofollow и Noindex?

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

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

Как использовать ссылки Nofollow на моем сайте?

Краткий ответ: это зависит от технологии, на которой работает ваш сайт.

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

Существуют также плагины WordPress, которые могут сделать все ваши ссылки nofollow.

В противном случае необходимо поработать с разработчиком, чтобы вручную или автоматически добавить тег rel=»nofollow» к вашим внешним ссылкам.

Теперь ваша очередь

Теперь я хотел бы услышать от вас:

Каков ваш опыт работы с обратными ссылками nofollow?

Или, может быть, у вас есть вопрос о чем-то.

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

Что происходит, когда вы вводите URL-адрес в адресную строку браузера?

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

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

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

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

Веб-сайты, серверы, IP-адреса, о боже!

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

Когда вы указываете в своем браузере URL-адрес, например https://jennapederson.dev/hello-world, ваш браузер должен выяснить, на каком сервере в Интернете размещен сайт. Для этого он просматривает домен jennapederson.dev, чтобы найти адрес.

Каждое устройство в Интернете — серверы, сотовые телефоны, ваш умный холодильник — имеют уникальный адрес, называемый IP-адресом. IP-адрес состоит из четырех пронумерованных частей:

203.0.113.0

Но такие числа трудно запомнить! Вот тут-то и появляются доменные имена. jennapederson.dev гораздо легче запомнить, чем 203.0.113.0, верно? Представьте себе, что вам нужно запомнить все телефонные номера ваших контактов, не имея приложения «Контакты» на вашем телефоне. Приложение «Контакты» позволяет искать телефонные номера по имени.

Мы делаем то же самое в Интернете. Система доменных имен, или DNS, похожа на приложение «Контакты» на нашем телефоне. DNS помогает нашему браузеру (и нам) находить серверы в Интернете. Мы можем выполнить поиск DNS, чтобы найти IP-адрес сервера на основе доменного имени jennapederson.dev. Подробнее о DNS можно прочитать здесь.

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

Процесс

Чтобы показать, как все эти шаги сочетаются друг с другом, я буду использовать инстанс Amazon Lightsail и зону DNS Lightsail. Я использую Lightsail, потому что это один из самых простых сервисов для управления виртуальными частными серверами (VPS) и DNS в одном месте, но эти концепции работают для любого сервиса VPS и DNS.

1. Вы вводите https://jennapederson.dev/hello-world в браузере и нажимаете Enter

Давайте разберем части этого URL-адреса, который вы ввели, чтобы попасть сюда.

https://jennapederson.dev/hello-world

Схема

https:// это схема. HTTPS расшифровывается как безопасный протокол передачи гипертекста. Эта схема указывает браузеру установить соединение с сервером с использованием безопасности транспортного уровня или TLS. TLS — это протокол шифрования для защиты связи через Интернет. С помощью HTTPS данные, которыми обмениваются ваш браузер и сервер, такие как пароли или информация о кредитной карте, шифруются. Возможно, вы также видели ftp:// , mailto:// или file:// . Это другие протоколы, с которыми браузеры умеют работать.

Домен

jennapederson.dev — доменное имя сайта. Это запоминающийся адрес, который указывает на IP-адрес определенного сервера. Если вы посмотрите на зону DNS Lightsail ниже, вы увидите запись DNS A, указывающую на экземпляр Lightsail, jennapedersondev-static-ip , которая представляет собой статический IP-адрес экземпляра Lightsail.

Путь

Иногда в URL присутствует дополнительный путь к ресурсу. Например, для этого URL-адреса https://jennapederson.dev/the-path-to/hello-world , the-path-to — это путь на сервере к запрашиваемому ресурсу, hello-world . . Вы можете думать об этом как о структуре каталогов файлов и других каталогов на вашем компьютере. Это способ организовать ваши ресурсы, будь то статический HTML, CSS, Javascript или файлы изображений или динамически генерируемый контент. Общие примеры путей: блог , сообщения , теги или изображения , каждый из которых группирует разные ресурсы.

Ресурс

Когда вы вводите этот URL-адрес в браузере, hello-world — это имя ресурса на веб-сайте, который вы хотите просмотреть. Иногда вы увидите это с расширением файла, например .html , которое указывает, что это статический файл на сервере с содержимым HTML. Без расширения, такого как этот URL-адрес, он обычно указывает, что сервер сгенерировал этот контент. Например, новостной сайт покажет вам настроенный, актуальный и местный новостной контент, что он может сделать только тогда, когда знает, кто вы или откуда пришел запрос.

2. Браузер ищет IP-адрес для домена

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

Поскольку DNS сложен и должен быть невероятно быстрым, данные DNS кэшируются на разных уровнях между вашим браузером и в разных местах в Интернете. Ваш браузер проверяет собственный кеш, кеш операционной системы, кеш локальной сети на вашем маршрутизаторе и кеш DNS-сервера в вашей корпоративной сети или у вашего интернет-провайдера (ISP). Если браузер не может найти IP-адрес ни на одном из этих уровней кэша, DNS-сервер в вашей корпоративной сети или у вашего интернет-провайдера выполняет рекурсивный поиск DNS. Рекурсивный поиск DNS запрашивает несколько DNS-серверов в Интернете, которые, в свою очередь, запрашивают DNS-запись у большего количества DNS-серверов, пока она не будет найдена.

Как только браузер получит DNS-запись с IP-адресом, ему пора найти сервер в Интернете и установить соединение.

3. Браузер инициирует TCP-соединение с сервером

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

Вместо этого многие сайты используют сеть доставки контента или CDN для кэширования статического и динамического контента ближе к браузеру. В нашем примере я установил экземпляр Lightsail jennapedersondev в качестве источника для распространения CDN.

CDN — это глобально распределенная сеть серверов кэширования, которые повышают производительность вашего сайта или приложения (источника), приближая контент к вашим пользователям. CDN Lightsail использует CloudFront, который является частью глобальной сети AWS. Запросы от клиентского браузера могут использовать преимущества этой частной сети со сверхнизкой задержкой и высокой доступностью. Чтобы отслеживать переходы, которые выполняет запрос с моего компьютера на jennapederson.dev, мы можем использовать трассировка . На изображении ниже первый переход (первая строка) относится к моему маршрутизатору. Переходы в первом блоке находятся в сети моего интернет-провайдера, а переходы во втором блоке — в глобальной сети AWS.

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

Как только браузер находит сервер в Интернете, он устанавливает TCP-соединение с сервером и, если используется HTTPS, для защиты связи выполняется рукопожатие TLS. TCP и TLS — чрезвычайно важные темы, но мы рассмотрим их в другом посте.

На изображении ниже это соединение (начальное соединение) заняло 130,30 мс.

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

4. Браузер отправляет HTTP-запрос на сервер

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

Строка запроса содержит следующее:

• метод запроса, который является одним из GET, POST, PUT, PATCH, DELETE или несколькими другими глаголами HTTP
• путь, указывающий на запрошенные ресурсы
• версия HTTP для связи с

Строка запроса для запроса URL выглядит так:

ПОЛУЧИТЬ /hello-world HTTP/1.1

Строка запроса сообщает серверу, что вы хотите ПОЛУЧИТЬ ресурс в /hello-world и для связи с HTTP/1.1 .

Помните, что HTTP-глаголы выражают смысловое значение вашего запроса. Вы также можете использовать методы POST, PUT или PATCH для отправки данных на сервер для хранения либо для создания новых данных, либо для обновления существующих данных по пути запроса. Метод DELETE удалит ресурс по заданному пути. Однако важно знать, что серверам не обязательно поддерживать все глаголы. Сервер может ответить 200 OK на метод DELETE и ничего не делать с ресурсом.
Следующая часть запроса — заголовки запроса. Заголовки передают дополнительную информацию от клиента, которая помогает маршрутизировать запрос, указывает, какой тип клиента делает запрос (пользовательский агент), и может использоваться для поддержки A/B-тестирования, синего/зеленого развертывания и канареечного развертывания.
Заголовки представляют собой такие пары ключ-значение:

 Хост: jennapederson.dev
Пользовательский агент: curl/7.64.1
Принять: */* 

Последняя часть запроса — тело. Тело (обычно) пустое для GET-запроса, подобного нашему. Для запроса, который манипулирует ресурсами, такими как POST, PUT или PATCH, тело будет содержать данные от клиента для создания или обновления.
Тело запроса может быть в разных форматах, и сервер понимает формат на основе заголовка запроса, Content-Type .
Вот пример полного запроса URL со строкой запроса и заголовками (без тела, так как это GET):

 ПОЛУЧИТЬ /привет-мир/ HTTP/1.1
Ведущий: jennapederson.dev
Соединение: Keep-alive
Прагма: без кеша
Кэш-контроль: без кеша
sec-ch-ua: "Не бренд";v="99", "Chromium";v="90", "Google Chrome";v="90"
сек-ч-уа-мобиль: ?0
Обновить-небезопасные-запросы: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, например Gecko) Chrome/90.0.4430.212 Safari/537.36
Принять: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3; р=0,9Sec-Fetch-Site: того же происхождения
Sec-Fetch-Mode: навигация
Sec-Fetch-Пользователь: ?1
Sec-Fetch-Dest: документ
Реферер: 
Accept-Encoding: gzip, deflate, br
Принять-Язык: en-US,en;q=0.9
днт: 1
сек-гпк: 1 

После того, как сервер получил запрос от клиента, он обрабатывает его и отправляет ответ.

5.

Сервер обрабатывает запрос и отправляет ответ

Сервер принимает запрос и на основе информации в строке запроса, заголовках и теле запроса решает, как обработать запрос. По запросу GET /hello-world/ HTTP/1.1 , сервер получает содержимое по этому пути, создает ответ и отправляет его обратно клиенту. Ответ содержит следующее:

• строка состояния, сообщающая клиенту о статусе запроса
• заголовки ответа, сообщающие браузеру, как обрабатывать ответ
• запрошенный ресурс по этому пути, будь то содержимое, такое как HTML, CSS, Javascript или файлы изображений, или данные

Строка состояния содержит как версию HTTP, так и числовое и текстовое представление статуса запроса. Ответ выглядит так:

 HTTP/1.1 200 ОК
Дата: вторник, 25 мая 2021 г., 19:40:59 по Гринвичу
Сервер: Апач
Параметры X-Frame: SAMEORIGIN
X-Powered-By: Экспресс
Cache-Control: max-age=0, без кеша
Тип содержимого: текст/html; кодировка = utf-8
Варьировать: Accept-Encoding
X-Mod-Pagespeed: 1. 13.35.2-0
Кодировка содержимого: br
Keep-Alive: таймаут=1, макс=100
Соединение: Keep-Alive
Передача-кодирование: по частям


<голова>
    ОСТАЛЬНАЯ ЧАСТЬ HTML 

Браузер считает код состояния из 200 успешным. Ответ был 200, поэтому браузер знает, что нужно отобразить ответ.
Ресурсы могут быть статическими файлами, текстовыми (например, index.html ) или нетекстовыми данными (например, logo.img ). Однако браузеры не всегда запрашивают статические файлы. Часто это динамические ресурсы, генерируемые во время запроса, и файл, связанный с ресурсом, отсутствует. Собственно, в этом запросе именно это и происходит. Нет файла hello-world , но сервер все равно знает, как обработать запрос. Сервер создает динамический ресурс, создавая HTML-код из фрагментов или шаблонов и комбинируя его с динамическими данными для отправки в ответ в виде текста, чтобы браузер мог отобразить страницу.
Теперь, когда вы знаете, как сервер формирует ответ для отправки обратно в браузер, давайте посмотрим, как браузер обрабатывает ответ.

6. Браузер отображает содержимое

После того, как браузер получил ответ от сервера, он проверяет заголовки ответа на предмет информации о том, как отображать ресурс. Заголовок Content-Type выше сообщает браузеру, что он получил ресурс HTML в теле ответа. К счастью для нас, браузер знает, что делать с HTML!
Первый запрос GET возвращает HTML, структуру страницы. Но если вы проверите HTML-код страницы (или любой веб-страницы) с помощью инструментов разработчика вашего браузера, вы увидите, что он ссылается на другие ресурсы Javascript, CSS, изображения и запрашивает дополнительные данные для отображения веб-страницы в соответствии с дизайном.
Когда браузер анализирует и отображает HTML, он делает дополнительные запросы на получение Javascript, CSS, изображений и данных. Он может делать многое из этого параллельно, но не всегда, и это история для другого поста.

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

Подведение итогов

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

1. Вы вводите URL-адрес в браузере и нажимаете Enter
2. Браузер ищет IP-адрес для домена
3. Браузер инициирует TCP-соединение с сервером
4. Браузер отправляет HTTP-запрос на сервер
5. Сервер обрабатывает запрос и отправляет ответ
6. Браузер отображает содержимое

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