Должен быть указан url с протоколом что это значит

Простым языком об HTTP

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

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

Аббревиатура HTTP расшифровывается как HyperText Transfer Protocol, «протокол передачи гипертекста». В соответствии со спецификацией OSI, HTTP является протоколом прикладного (верхнего, 7-го) уровня. Актуальная на данный момент версия протокола, HTTP 1.1, описана в спецификации RFC 2616.

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

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

Также HTTP часто используется как протокол передачи информации для других протоколов прикладного уровня, таких как SOAP, XML-RPC и WebDAV. В таком случае говорят, что протокол HTTP используется как «транспорт».

API многих программных продуктов также подразумевает использование HTTP для передачи данных — сами данные при этом могут иметь любой формат, например, XML или JSON.

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

Как отправить HTTP-запрос?

Самый простой способ разобраться с протоколом HTTP — это попробовать обратиться к какому-нибудь веб-ресурсу вручную. Представьте, что вы браузер, и у вас есть пользователь, который очень хочет прочитать статьи Анатолия Ализара.

Предположим, что он ввёл в адресной строке следующее:

Соответственно вам, как веб-браузеру, теперь необходимо подключиться к веб-серверу по адресу alizar.habrahabr.ru.

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

telnet alizar.habrahabr.ru 80

Сразу уточню, что если вы вдруг передумаете, то нажмите Ctrl + «]», и затем ввод — это позволит вам закрыть HTTP-соединение. Помимо telnet можете попробовать nc (или ncat) — по вкусу.

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

Для того, чтобы сформировать HTTP-запрос, необходимо составить стартовую строку, а также задать по крайней мере один заголовок — это заголовок Host, который является обязательным, и должен присутствовать в каждом запросе. Дело в том, что преобразование доменного имени в IP-адрес осуществляется на стороне клиента, и, соответственно, когда вы открываете TCP-соединение, то удалённый сервер не обладает никакой информацией о том, какой именно адрес использовался для соединения: это мог быть, например, адрес alizar.habrahabr.ru, habrahabr.ru или m.habrahabr.ru — и во всех этих случаях ответ может отличаться. Однако фактически сетевое соединение во всех случаях открывается с узлом 212.24.43.44, и даже если первоначально при открытии соединения был задан не этот IP-адрес, а какое-либо доменное имя, то сервер об этом никак не информируется — и именно поэтому этот адрес необходимо передать в заголовке Host.

Стартовая (начальная) строка запроса для HTTP 1.1 составляется по следующей схеме:

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

Метод (в англоязычной тематической литературе используется слово method, а также иногда слово verb — «глагол») представляет собой последовательность из любых символов, кроме управляющих и разделителей, и определяет операцию, которую нужно осуществить с указанным ресурсом. Спецификация HTTP 1.1 не ограничивает количество разных методов, которые могут быть использованы, однако в целях соответствия общим стандартам и сохранения совместимости с максимально широким спектром программного обеспечения как правило используются лишь некоторые, наиболее стандартные методы, смысл которых однозначно раскрыт в спецификации протокола.

URI (Uniform Resource Identifier, унифицированный идентификатор ресурса) — путь до конкретного ресурса (например, документа), над которым необходимо осуществить операцию (например, в случае использования метода GET подразумевается получение ресурса). Некоторые запросы могут не относиться к какому-либо ресурсу, в этом случае вместо URI в стартовую строку может быть добавлена звёздочка (астериск, символ «*»). Например, это может быть запрос, который относится к самому веб-серверу, а не какому-либо конкретному ресурсу. В этом случае стартовая строка может выглядеть так:

Версия определяет, в соответствии с какой версией стандарта HTTP составлен запрос. Указывается как два числа, разделённых точкой (например 1.1).

Для того, чтобы обратиться к веб-странице по определённому адресу (в данном случае путь к ресурсу — это «/»), нам следует отправить следующий запрос:

GET / HTTP/1.1
Host: alizar.habrahabr.ru

При этом учитывайте, что для переноса строки следует использовать символ возврата каретки (Carriage Return), за которым следует символ перевода строки (Line Feed). После объявления последнего заголовка последовательность символов для переноса строки добавляется дважды.

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

Если вы хотите отправить запрос в точном соответствии со спецификацией, можете воспользоваться управляющими последовательностями \r и \n:

Как прочитать ответ?

Стартовая строка ответа имеет следующую структуру:

Версия протокола здесь задаётся так же, как в запросе.

Код состояния (Status Code) — три цифры (первая из которых указывает на класс состояния), которые определяют результат совершения запроса. Например, в случае, если был использован метод GET, и сервер предоставляет ресурс с указанным идентификатором, то такое состояние задаётся с помощью кода 200. Если сервер сообщает о том, что такого ресурса не существует — 404. Если сервер сообщает о том, что не может предоставить доступ к данному ресурсу по причине отсутствия необходимых привилегий у клиента, то используется код 403. Спецификация HTTP 1.1 определяет 40 различных кодов HTTP, а также допускается расширение протокола и использование дополнительных кодов состояний.

Пояснение к коду состояния (Reason Phrase) — текстовое (но не включающее символы CR и LF) пояснение к коду ответа, предназначено для упрощения чтения ответа человеком. Пояснение может не учитываться клиентским программным обеспечением, а также может отличаться от стандартного в некоторых реализациях серверного ПО.

После стартовой строки следуют заголовки, а также тело ответа. Например:

Тело ответа следует через два переноса строки после последнего заголовка. Для определения окончания тела ответа используется значение заголовка Content-Length (в данном случае ответ содержит 7 восьмеричных байтов: слово «Wisdom» и символ переноса строки).

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

В заголовке Location передан новый адрес. Теперь URI (идентификатор ресурса) изменился на /users/alizar/, а обращаться нужно на этот раз к серверу по адресу habrahabr.ru (впрочем, в данном случае это тот же самый сервер), и его же указывать в заголовке Host.

GET /users/alizar/ HTTP/1.1
Host: habrahabr.ru

В ответ на этот запрос веб-сервер Хабрахабра уже выдаст ответ с кодом 200 и достаточно большой документ в формате HTML.

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

А что с безопасностью?

Сам по себе протокол HTTP не предполагает использование шифрования для передачи информации. Тем не менее, для HTTP есть распространённое расширение, которое реализует упаковку передаваемых данных в криптографический протокол SSL или TLS.

Название этого расширения — HTTPS (HyperText Transfer Protocol Secure). Для HTTPS-соединений обычно используется TCP-порт 443. HTTPS широко используется для защиты информации от перехвата, а также, как правило, обеспечивает защиту от атак вида man-in-the-middle — в том случае, если сертификат проверяется на клиенте, и при этом приватный ключ сертификата не был скомпрометирован, пользователь не подтверждал использование неподписанного сертификата, и на компьютере пользователя не были внедрены сертификаты центра сертификации злоумышленника.

На данный момент HTTPS поддерживается всеми популярными веб-браузерами.

А есть дополнительные возможности?

Протокол HTTP предполагает достаточно большое количество возможностей для расширения. В частности, спецификация HTTP 1.1 предполагает возможность использования заголовка Upgrade для переключения на обмен данными по другому протоколу. Запрос с таким заголовком отправляется клиентом. Если серверу требуется произвести переход на обмен данными по другому протоколу, то он может вернуть клиенту ответ со статусом «426 Upgrade Required», и в этом случае клиент может отправить новый запрос, уже с заголовком Upgrade.

Такая возможность используется, в частности, для организации обмена данными по протоколу WebSocket (протокол, описанный в спецификации RFC 6455, позволяющий обеим сторонам передавать данные в нужный момент, без отправки дополнительных HTTP-запросов): стандартное «рукопожатие» (handshake) сводится к отправке HTTP-запроса с заголовком Upgrade, имеющим значение «websocket», на который сервер возвращает ответ с состоянием «101 Switching Protocols», и далее любая сторона может начать передавать данные уже по протоколу WebSocket.

Что-то ещё, кстати, используют?

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

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

Опубликованный в ноябре 2012 года черновик спецификации протокола HTTP 2.0 (следующая версия протокола HTTP после версии 1.1, окончательная спецификация для которой была опубликована в 1999) базируется на спецификации протокола SPDY.

Многие архитектурные решения, используемые в протоколе SPDY, а также в других предложенных реализациях, которые рабочая группа httpbis рассматривала в ходе подготовки черновика спецификации HTTP 2.0, уже ранее были получены в ходе разработки протокола HTTP-NG, однако работы над протоколом HTTP-NG были прекращены в 1998.

На данный момент поддержка протокола SPDY есть в браузерах Firefox, Chromium/Chrome, Opera, Internet Exporer и Amazon Silk.

И что, всё?

В общем-то, да. Можно было бы описать конкретные методы и заголовки, но фактически эти знания нужны скорее в том случае, если вы пишете что-то конкретное (например, веб-сервер или какое-то клиентское программное обеспечение, которое связывается с серверами через HTTP), и для базового понимания принципа работы протокола не требуются. К тому же, всё это вы можете очень легко найти через Google — эта информация есть и в спецификациях, и в Википедии, и много где ещё.

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

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

Источник

15 тривиальных фактов о правильной работе с протоколом HTTP

Внимание! Реклама! Пост оплачен Капитаном Очевидность!

Ниже под катом вы найдёте 15 пунктов, описывающих правильную организацию ресурсов, доступных по протоколу HTTP — веб-сайтов, «ручек» бэкенда, API и прочая. «Правильный» здесь означает «соответствующий рекомендациям и спецификациям». Большая часть ниженаписанного почти дословно переведена из официальных стандартов, рекомендаций и best practices от IETF и W3C.

Вы не найдёте здесь абсолютно ничего неочевидного. Нет, серьёзно, каждый веб-разработчик теоретически эти 15 пунктов должен освоить где-то в районе junior developer-а и/или второго-третьего курса университета.

Однако на практике оказывается, что великое множество веб-разработчиков эти азы таки не усвоило. Читаешь документацию к иным API и рыдаешь. Уверен, что каждый читатель таки найдёт в этом списке что-то новое для себя.

1. URL идентифицирует ресурс — некоторую разделяемую сущность. Файл — ресурс. Ручка, которая что-то ищет — ресурс. Вызов метода — не ресурс. Если вы хотите шарахнуть из пушки по Луне, то вот так делать не надо:

Заведите ресурс «шарахалка», и тогда у вас всё будет логично:

Почему POST, а не GET? Читай ниже.

2. URL состоит из схемы (протокола), хоста, пути (path), запроса (query) и фрагмента. Путь используется для организации иерархических ресурсов, запрос — для неиерархических ресурсов и для параметров операции. Фрагмент идентифицирует подчинённый ресурс, не имеющий прямого URL.

Если на вашем сайте «Няшные котики» есть каталог по породам, то его вполне логично организовать в виде частей path, поскольку каждый котик принадлежит ровно к одной породе. А вот доставлять одного котика можно в несколько городов, поэтому фильтр «с доставкой в город N» следует организовать через query.

3. Обращение по HTTP состоит из применения метода (глагола) к URL. Результатом такого применения должно быть — сюрприз-сюрприз! — то, что в глаголе написано. То есть GET возвращает представление ресурса, DELETE удаляет и т.п.

4. Методы GET, HEAD, OPTIONS — безопасные. Предполагается, что вызов этих методов состояния ресурса не изменяет. Поэтому многие сетевые агенты — такие, например, как префетчер ссылок в браузере или мессенджере — считают себя вправе по таким ссылкам ходить без явного волеизъявления пользователя. ИЧСХ, никаких стандартов не нарушают.

5. По умолчанию методы GET и HEAD кэшируются, OPTIONS, POST, PUT, PATCH, DELETE — нет. Поэтому если вы шарахнули по Луне методом POST, вы можете быть (почти) уверены, что этот запрос выполнится. Если вы шарахаете методом GET, какой-нибудь промежуточный прокси может ВНЕЗАПНО отдать вам ответ из кэша, и шарах в реальности не произойдёт.

6. Операции GET, PUT, DELETE симметричны. PUT кладёт нечто по URL-у (создавая новый ресурс или перезаписывая старый), GET по этому URL-у возвращает представление того, что положил PUT, DELETE удаляет ресурс.
Метод HEAD синонимичен по семантике методу GET, но не возвращает тело ответа, а только его заголовки (метаинформацию о ресурсе).

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

Если клиенту генерировать id не разрешено, ему придётся делать POST на ресурс уровнем выше по иерархии:

И этот ресурс сам создаст новое сообщение.
Обратите внимание, если вы по ошибке или вследствие сетевых проблем повторите POST запрос — создастся второе сообщение в треде, идентичное первому. PUT вы можете делать хоть 100500 раз, результат не изменится. Это свойство называется идемпотентностью.
Ладно создание постов на форуме. Вот если вы делаете тяжёлую и дорогую операцию по пользовательскому запросу — очень рекомендуется выполнять для этого идемпотентный запрос. А то может получиться как на картинке:

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

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

9. Коды ответа нужны в первую очередь для того, чтобы клиент мог понять, что ему делать дальше. 3хх говорит, что для успешного выполнения запроса нужно выполнить дополнительное действие. 4хх говорит, что клиент, составляя запрос, сделал что-то неправильно и, обычно, о том, что умолять бесполезно — повторное выполнение запроса всё равно выкинет ошибку. В 4хх крайне рекомендуется включать информацию о том, что конкретно клиент сделал не так. 5хх говорит о том, что клиент всё сделал правильно — проблема на стороне сервера.

Обычно при успешном выполнении операции сервер отвечает на GET — 200, на PUT — 201 Created (если ресурс создан) или 200 (ресурс обновлён), на DELETE — 204 (операция успешна, возвращать нечего), на POST — 200 или 201 (во втором случае в заголовке, обычно Location, указывается URL созданного ресурса).

11. Существует особый подкласс URL-ов, которые кодируют в себе и ресурс, и действие над ним. В англоязычной литературе их принято называть Capability URLs. Классический пример такого URL — ссылки на восстановление паролей, а также всевозможные «секретные» прямые ссылки на всяческие ресурсы.

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

15. Всё описанное выше существует в стандартах исключительно в форме рекомендации, и принудить кого-либо к строгому исполнению этих рекомендаций нельзя. Я уже не первый раз рассказываю про всю эту тривию, и часто слышу в ответ «да плевать я на всё это хотел, придумали какой-то ненужной ерунды; как у меня работали все сервисы только на GET, так и дальше будут, мучайтесь со своими PUT-ами и DELETE-ми сами».

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

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

Но даже не это главное. Допустим, ваши HTTP-пакеты гуляют в строго контролируемой среде. Как вы собираетесь объяснять другим разработчикам, какие рекомендации вы нарушили и почему? Как ваш коллега должен понять, что вот этот GET-запрос повторять нельзя, а статус 400 вовсе не означает клиентскую ошибку? Отступая от рекомендаций, вы, фактически, каждый раз создаёте какой-то свой диалект HTTP с собственной семантикой. Не забудьте его хотя бы задокументировать 😉

Источник

Какими должны быть URL на сайте: 15 советов оптимизации ссылок

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

Правильный SEO URL — это не волшебная таблетка, а лишь кусочек огромного пазла под названием «поисковое продвижение сайта». Не стоит сильно фокусироваться на чем-то одном. Развивайте ваш проект комплексно.

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

Что такое URL

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

Согласно Wikipedia, URL — единообразный локатор ресурса. А если сказать более простыми словами, то это способ обозначения адресов документов, подчиненный определенному стандарту. Этот стандарт определяет необходимый набор составных частей.

Протокол

Самая первая часть, встречающаяся в адресе. Наверняка вы обращали внимание на http:// или https:// в начале каждой ссылки. Этот элемент называется «протокол» и его значение на самом деле велико.

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

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

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

Домен

Следующая часть является самым идентифицирующим элементом адреса — доменное имя. В примере это reforge.ru. Оно является идентификатором ресурса, перейдя по которому вы попадете на главную страницу.

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

Путь документа (страницы)

Если вы хотите зайти на главную страницу, то для этого достаточно только домена: https://reforge.ru. А вот каждая отдельная страница или файл, расположенные на домене, будут иметь свой уникальный URL. Вот, например, ссылка на наш блог: https://reforge.ru/blog.

Часть адреса после доменной зоны и косой линии (слэша) называется путь. Он указывает браузеру на определенный раздел, документ или файл.

15 советов оптимизации ссылок

Итак, с основами мы разобрались и самое время взяться за оптимизацию ссылок. На самом деле не существует 100% действенного метода. Я часто встречаю в топе разные подходы к формированию URL. Тем не менее я выделил 15 закономерностей, свойственных для всех топов. Следование им не гарантирует попадание в ТОП, но значительно увеличивает шансы на это.

1. Папка или поддомен — что выбрать?

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

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

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

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

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

Глобально ссылки разделяются на два типа:

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

И если сравнивать оба типа, то первый понятен как посетителям, так и поисковым машинам. Простой пример:

Обе страницы рассказывают про рестораны в Смоленске. Оба находятся в индексе Яндекса. Однако проект со статичными URL находится в топ-3, а с динамическим где-то на 7 странице.

Понятные ссылки ещё называют ЧПУ (человеко понятный урлы). Если у вас установлен WordPress, настроить такое отображение можно в разделе Настройки — Постоянные ссылки

3. Создавайте логичную структуру

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

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

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

4. Уменьшайте уровень вложенности

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

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

5. Длинные или короткие — что лучше?

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

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

6. Используйте ключевые слова

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

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

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

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

7. Избегайте заглавных букв

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

Если используется Microsoft, то никаких проблем — ссылки не будут чувствительны к регистру. Но на Linux/UNIX имеет значение используются ли заглавные буквы URL. С точки зрения этой системы эти страницы будут являться разными: page.html, Page.html, PAGE.html. Таким образом если в адресе используется заглавная буква, то при написании строчными она работать не будет и выдаст 404 ошибку.

8. Разделяйте слова через тире

Тут все просто. Для разделения слов лучше использовать знак тире «-», нежели нижнее подчеркивание «_». Ходят слухи, что поисковые системы уже одинаково хорошо относятся к обоим. Однако пока что мало кто рискует использовать непроверенный способ.

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

Ещё один момент касается разделения слов пробелом. С технической точки зрения это будет работать. Но каждый пробел в адресе будет заменен на комбинацию «%20», что, согласитесь, смотрится немного неудобно: /blog/razdelenie%20slov%20probelom.html. Поэтому я не рекомендую этот способ.

9. Откажитесь от кириллицы в адресах

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

Поэтому в URL я рекомендую использовать только латинские буквы.

10. Не используйте стоп-слова и лишние символы

Если в H1 или Title используются стоп-слова (от, из, в, на, под, для и т.п.), то нет ничего критичного, если поместить их в Урл.

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

Как видно, и без «для» легко понять о чем эта статья. Скорее всего она посвящена сбору семантического ядра. Поэтому согласно совету №5 из этой статьи (меньше = лучше) можем запросто убрать это стоп-слово.

Какие символы можно использовать в URL адресах?

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

Я рекомендую использовать в названиях Урлов только безопасные буквы и цифры:

11. Канонические URL

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

Вот как это работает. Допустим, вы создали пост о лучших автомобилях Италии и разместили его на сайте. Урл выглядит примерно так: …/best-itaian-cars

Спустя какое-то время ваш проект вырос, в нём появилось много материалов на различные тематики и вы решили сделать категории. Ваш пост добавили в раздел «Авто». И в этот момент появился дубликат вашей статьи с примерно такой ссылкой: …/auto/best-itaian-cars

Теперь у вас на два уникальных Урла, ведущих на одной и ту же страницу:

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

Если избавиться от них не получится (например, у вас отдельная версия страницы для печати), нам на помощь приходит атрибут

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

12. Перейдите на безопасный протокол HTTPS

Как я упоминал в начале этой статьи, HTTP — это протокол передачи гипертекста. Дополнительная буква «S» означает «secure», т.е. «безопасный». Все данные, переданные между сервером и браузером, зашифрованы и находятся в безопасности.

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

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

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

13. Объедините разные версии вашего сайта

Как правило, существует две версии сайта: версии с www. и без www. перед доменом. К этому можно добавить предыдущий совет. HTTP и HTTPS тоже считаются разными версиями, хоть поисковые системы и отдают предпочтение безопасному протоколу. И сточки зрения поисковиков эти версии являются разными. А как мы уже знаем, Яндекс и Google негативно относятся к дублированному контенту. Особенно когда клоном является весь сайт. Что же делать?

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

Раньше был способ склейки через вебмастер Яндекс и Google, но с обновлением сервисов этот способ упразднили. Самым действенным способом склейки сейчас остается 301-й редирект.

14. Сократите количество редиректов до двух или меньше

Если посетитель или поисковой робот запрашивает URL 1, а его перенаправляет на URL 2, то в этом нет ничего страшного. И даже если URL 2 впоследствии перекидывает на URL 3 (конечно, идеально сразу настроить перенаправление с 1 на 3). Но если количество редиректов превышает два, то это уже негативно сказывается на SEO.

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

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

Поэтому используйте редиректы осмысленно и не пренебрегайте ими.

15. Создайте карту сайта sitemap.xml

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

Что это

XML Sitemap (карта сайта) — это список всех Урлов вашего проекта, который можно и нужно отправить поисковым системам на индексирование. И для этого есть две причины:

Какие страницы следует включить в карту

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

Как создать sitemap.xml

В большинстве современных CMS эта функция либо есть по умолчанию, либо легко добавляется при помощи плагинов и расширений. Например, для WordPress я бы порекомендовал Google XML Sitemaps. Он простой и требует лишь активации. После этого карта сайта будет доступна по адресу …/sitemap.xml.

Как прописать URL в WordPress

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

Генерация SEO URL

Рекомендую установить плагин Cyr-to-Lat. Он в автоматическом режиме переводит заголовок в транслит и формирует на его основе адрес. Единственное, что остается сделать — это внести улучшения на основе изученных 15 советов из этой статьи.

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

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

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

Источник