Изменить на лету URL


Что такое динамические ссылки (URL) и динамические страницы

Что такое динамические ссылки

Если бы сейчас существовал такой поисковик, как Апорт (сайт есть, но поисковика нет — «ищет Яндексом») и вы бы решили добавить туда сайт (по аналогии с Яндекс.Вебмастер), то выдалось бы предупреждение, что динамические ссылки индексируются выборочно. Что это за ссылки такие?

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

Параметры выглядят следующим образом (начинаются со знака вопроса и перечисляются через амперсанд — &): ?a_1=значение_1&a_2=значение_2…&a_n=значение_n (где a_n — это переменная) и добавляются к концу ссылки, например: http://maps.google.ru/maps?hl=ru&tab=wl. Для чего они нужны? С помощью них веб-сервер получает так называемые GET-запросы, после обработки которых он формирует т.н. динамические страницы.

Содержимое таких страниц генерируется «на лету» (потому они и динамические) с помощью языков серверного программирования (например, PHP). Часто это содержимое берётся из базы данных как, например, в WordPress (установка WordPress на Denwer). Основная особенность таких страниц в том, что физически их нет (т.е. на сервере нет файлов этих документов).

К примеру, в том же WordPress URL такого типа http://web-ru.net/prodvizhenie-sajta/seo/gramotnyj-podbor-klyuchevyx-slov-i-analiz-zaprosov-v-yandeks-wordstat.html выглядят как ссылки на обычные HTML-документы, хотя если зайти на хостинг и посмотреть в папке с сайтом, то никаких HTML-страниц там найти не получится. На самом деле данный документ является динамической страницей и имеет такой вид: http://web-ru.net/?p=749.

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

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

Кстати, почему динамические ссылки могут индексироваться поисковыми системами выборочно? На самом деле, уже все современные поисковики учитывают любые URL, это раньше у них бывали трудности.

В наше время проблемы начинаются тогда, когда 2 ссылки, имеющие разные GET-параметры, ведут на страницу с одним и тем же содержимым — происходит дублирование контента, что ухудшает сайт в глазах поисковых роботов. Данная проблема решается с помощью использования канонических URL, а также особой настройкой файла Robots.txt или же полным переходом на псевдостатические страницы (например, как в WordPress с использованием ЧПУ и .html на конце URL).

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

Изменить HTTP URL на лету

December 2020

365 раз

Можно ли изменить запрос HTTP пользователей к

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

После того, как прибегая к помощи всю ночь, у меня нет свинца, но еще несколько вопросов:

  1. Мне не нужно, чтобы перехватить все пакеты через сеть. С некоторыми помогает как IPTables, я могу отфильтровать пакет я хочу. Я сделал это перед использованием IPTables. Тем не менее, пакет не равен HTTP поток. Нужно ли мне делать HTTP заново построить?
  2. Если я успешно найти способ изменить содержимое URL запроса HTTP, я все еще должен положить его обратно в сетевой поток. Как я знаю, что TCP-пакеты имеют контрольную сумму и после того, как я могу изменить содержание должно быть неправильным. Как вычислить новую контрольную сумму и поставить пакет обратно в сеть?

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

2 ответы

Это зависит от того, что вы делаете HTTP / 1.0 или HTTP / 1.1 и будет ли сво первоначального запроса вам нужно изменить или все запросы в 1.1 сессии одного HTTP.

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

Однако, если это поток HTTP / 1.1, то множественные запросы будут посылают через одно соединение TCP и в этом случае в будущих запросах URL-адрес может также быть разделен на два пакетов TCP.

Если вы можете, возможно, заставить HTTP / 1.0 или, возможно, если изменить начальное или все запросы HTTP / 1.0, то вы можете быть уверены, что первый пакет будет соответствовать первому пакету потока TCP и что вы вряд ли см раскол URL над несколькими пакетами, что означает отсутствие реконструкции и возможность просто сделать замену.

Однако это произойдет на стоимости новых соединений TCP, который является довольно неэффективным.

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

Правильный URL WordPress

Сегодняшний пост посвящен размышлению о том, какими должны быть URL («урлы») постов и категорий сайта или блога на движке WordPress. Рассмотрим следующие вопросы:

  • Надо ли использовать ЧПУ (человеко-понятные урлы)?
  • Можно ли использовать кириллические URL?
  • Нужно ли удалять название категорий из URL?
  • Следует ли дописывать .html в конце урла поста?
  • Какие ярлыки должны быть у категорий (рубрик)?
  • Надо ли укорачивать URL?
  • Как изменить структура сайта?

В Интернете можно найти множество сайтов, которые себя неплохо чувствуют, хотя и не используют человеко-понятные урлы (ЧПУ). Применительно к WordPress, ссылка может иметь следующий вид https://mukhutdinov.com/?p=1700 (подобную ссылку можно получить, нажав в редакторе на кнопку «Получить короткую ссылку»). Плюс короткой ссылку кроется в её названии — она короткая и без проблем может быть опубликована в сообщении на любой сайте, например в Twitter (ограничение на длину сообщения в Twitter составляет 140 символов). Минусом является то, что по тексту ссылки не понятно, на какой именно документ она ведет. При использовании ЧПУ, ссылка выглядит более информативно https://mukhutdinov.com/skolko-mozhet-zarabotat-novichok-na-svoem-sajte.html — ясно, что она ведет на статью посвященную заработку на сайте.

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

«Желательно, чтобы вид URL давал представление о том, что содержится на соответствующей странице. Использование транслитерации в адресах страниц также позволит роботу понять, о чем может быть страница. Например, один только URL http://download.yandex.ru/company/experience/Baitin_Korrekciya%20gramotnosti.pdf дает поисковому роботу множество информации о документе: его можно скачать; формат, скорее всего, PDF; документ, вероятно, релевантен запросу «коррекция грамотности» и так далее.»

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

Ключевые слова из запроса, содержащиеся в URL, подсвечиваются в сниппете

Вывод: ЧПУ надо использовать, так как это полезно для пользователей, а что хорошо для пользователей, то хорошо и для поисковиков.

Кириллица в URL

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

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

Нужно ли прописывать категорию в URL?

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

Плюсы

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


Минусы

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

Робот Яндекса «не увидел» категорий на сайте

Теперь посмотрим на структуру сайта, в урлах которого присутствуют названия категорий.

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

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

1) Структура сайта site.ru, с точки зрения робота Яндекса, не содержит категорий, хотя категории есть и во многих из них более 10 публикаций. Я сделал вывод, что это связано с тем, что в URL документов не отображаются категории. Правильный ли вывод я сделал?

2) Насколько важна, с точки зрения робота Яндекса, разница между URL http://site.ru/dog.html и http://site.ru/animals/dog.html ?

Топ-пост этого месяца:  Почему стоит использовать CSS фреймворки вместо Grid Layout плюсы и минусы

Никакой разницы нет.

3) Если второй вариант правильный, то имеет ли смысл менять структуру URL, учитывая, что проиндексировано более 100 документов?

Нет, смысла менять структуру нет.

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

Цитата из справки Яндекса:

«Поддерживайте четкую ссылочную структуру на сайте. Каждый документ должен относиться к своему разделу.»

Если в урле содержится название категорий и подкатегорий, то по URL можно определить, к какому разделу относится документ.

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

Наличие .html в конце URL

Я не могу достоверно сказать, кто и когда додумался в конце динамической страницы, создаваемой WordPress, дописывать .html, однако идея прижилась. Для многих веб-мастеров, в том числе и для меня, наличие в конце урла .html является знаком того, что это пост (запись), а например, не категория или страница WordPress. На мой взгляд, подобное окончание урлов постов WordPress, снимает необходимость думать о том, должен ли присутствовать слэш в конце URL или нет. Соответственно, нет необходимости размышлять о 301-редиректе с URL без слэша на URL со слэшем и наоборот. С другой стороны, я бы сильно удивился, если бы увидел подобный подход на Яндексе или Google.

На сайте CNN.com, по умолчанию (основной URL) слеша в конце URL нет, но если его добавить, то страница доступна и по адресу со слешем: http://edition.cnn.com/v .

На сайте www.artlebedev.ru (студия Артемия Лебедева), кроме главной страницы, все URL заканчиваются слешем.

Итак, возможные варианты настройки ЧПУ для WordPress (в URL прописывается категория):

  1. /%category%/%postname%.html — в конце урла .html
  2. /%category%/%postname%/ — в конце урла слэш
  3. /%category%/%postname% — в конце урла не будет слэша (URL будет выглядеть так, как на большинстве топовых сайтов).

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

Ярлыки рубрик WordPress

В меню, названия рубрик могут быть написаны на кириллице, но ярлыки должны быть на латинице. При наличии плагина Rus-To-Lat, процесс транслитерации происходит автоматически. Однако во многих случаях, есть смысл укорачивать ярлыки, тем самым обеспечив меньшую длину URL (если категории прописываются в урле). Также, иногда, следует использовать английские слова, а не транслит. Возможные варианты:

  • Продвижение сайтов — «seo», а не «prodvizhenie-sajtov»;
  • Программное обеспечение — «soft», а не «programmnoe-obespechenie»;
  • Статьи — «articles», а не «stati»;
  • Книги — «books», а не «knigi».

Укорачивание урлов

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

Длину URL можно сократить как за счет ярлыка категории, так и за счет части, формирующейся на основе заголовка страницы (как правило, это заголовок уровня H1).

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

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

При изменение структуры сайта, воспользуйтесь справкой Яндекса:

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

Изменить HTTP-URL на лету

Можно ли изменить HTTP-запрос пользователя на

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

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

  1. Мне не нужно перехватывать каждый пакет через сеть. С помощью некоторых подсказок, таких как iptables, я могу отфильтровать нужный пакет. Я сделал это, прежде чем использовать iptables. Однако пакет не равен потоку HTTP. Нужно ли делать HTTP-перестройку?
  2. Если я успешно найду способ изменить содержимое URL-адреса HTTP-запроса, я все равно должен вернуть его в сетевой поток. Как я знаю, TCP-пакеты имеют контрольную сумму, и после того, как я изменяю содержимое, это должно быть неправильно. Как рассчитать новую контрольную сумму и вернуть пакет в сеть?

Я впервые занимаюсь сетевым программированием или обработкой пакетов. Любое предложение ценится.

2 ответа

Это зависит от того, выполняете ли вы HTTP / 1.0 или HTTP / 1.1 и является ли это первоначальным запросом, который нужно изменить, или всеми запросами в одном сеансе HTTP 1.1.

Если у вас есть пакет, и вы можете изменить его до того, как он будет отправлен, и вы пытаетесь изменить только запрос, то с учетом длины типичного пакета и расположения URL-адреса в потоке HTTP-запросов (в самом начале) и факт, что это будет первое, что будет отправлено в потоке TCP, я думаю, вы можете с уверенностью предположить, что он будет присутствовать в первых N байтах первого отправленного пакета и, следовательно, не будет разделен на несколько пакетов.


Однако, если это поток HTTP / 1.1, то через одно и то же TCP-соединение будут отправляться несколько запросов, и в этом случае в будущих запросах URL может быть разделен на два TCP-пакета.

Если вы можете принудительно установить HTTP / 1.0 или, возможно, измените первоначальный или все запросы на HTTP / 1.0, то вы можете быть совершенно уверены, что первый пакет будет соответствовать первому пакету потока TCP и что вы вряд ли увидеть URL-адрес, разделенный на несколько пакетов, что означает отсутствие реконструкции и возможность просто заменить.

Однако это будет стоить новых TCP-соединений, что довольно неэффективно.

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

[Решено] Поиск с точным совпадением (добавить кавычки)

Есть 2 записи с названиями «good day» и «good nice day» и если вписать в поиске good day то в результатах выведется 2 записи

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

Решение: в запросе достаточно добавить словосочетание в кавычки

Вопрос: как добавить чекбокс, который в результатах поиска в адресной строке добавит кавычки ?

Настройка ЧПУ в MODX Revo

Последнее изменение поста: 23 октября 2020 в 20:12

Сегодня же мы продолжим настраивать MODX, а если конкретнее, то настроим человеко понятные URL адреса (ЧПУ) в MODX, иными словами сделаем читаемыми URL адреса (пример: Заголовок страницы «О компании», сейчас выглядит так: /index.php? >

Настройка ЧПУ MODX

Первым делом идем в корневую папку сайта и переименовываем файл ht.access в .htaccess. Сделать это можно штатными средствами из админки, для того в дереве ресурсов, перейдите на вкладку «Файлы», кликаем по ht.access правой кнопкой мыши и выбираем переименовать, в открывшемся окошке пишем новое имя .htaccess и сохраняем.

Точно также переименовываем ht.access в .htaccess, который находиться в директории core.

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

Автоматически генирировать псевдоним – Да

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

Максимальная длина псевдонима — 70

Выше 70 символов не имеет смысла – слишком длинный адрес страницы.

Создавать ЧПУ-псевдоним (так называемые «дружественные URL») «на лету» — да

Генерирует псевдоним в реальном времени.

Транслитерация псевдонимов — russian

Просто прописываем «russian», должен быть установлен пакет дополнений «translit», который мы установили в уроке: Установка пакетов MODX.

Использовать дружественные URL — Да

Включаем URL вида /o-nas.html, а не параметрические, вроде /index.php?p=3 (для поддержки опции на некоторых хостингах нужны соответствующие настройки веб-сервера Apache в файле .htaccess или в конфиг-файле Nginx).

Строгий режим дружественных URL — Да

Использовать вложенные URL — Да

Чтобы в URL учитывался псевдоним родителя, а не его замороженный URL

Чуть не забыл! ВАЖНО! Не забываем про требования к серверу:
На сервере (Apache) должна быть включена функция Mod_Rewrite, иначе ЧПУ работать скорее всего не будут.

IIS — изменяем размер картинок на лету

Почти в каждом веб-проекте мы сталкиваемся с задачей показывать те или иные изображения в разных размерах. Всё просто — изображение должно показываться в размере, требуемом контекстом. Если вы разрабатываете каталог с разными представлениями, то таких контекстов может быть много. А возможно, что потребуется сделать размер картинки адаптивным по отношению к размеру окна браузера (например, так делают Picasa Web Albums).

Я расскажу о способе решить эту проблему раз и навсегда.

Что мы хотим

Это должно отображать картинку размером 100 x 100.

Реализация

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

Итак, чтобы всё работало, нам понадобится собственно сам класс модуля и одна строчка в Web.config .

Модуль хоть и невелик, но выкрадывать сюда простыню кода смысла тоже большого нет.
Поэтому я создал gist c кодом. Скопируйте этот код себе в проект (например в App_Code ).

Теперь короткие настройки в вашем Web.config . Добавьте в тег или (последний, если вы используете ASP.NET Devopment Server) такую строчку:

Используем

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

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

  • s — модуль не будет увеличивать картинку, если она меньше требуемых размеров.
  • c — модуль будет следить чтобы размер результирующей картинки был строго требуемого размера — если необходимо, он добавит белые поля по горизонтали или вертикали.
  • p — модуль вернёт PNG вместо JPEG.

Например вот так: /img/[email protected]

Тонкие настройки и модификация

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


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

Правильный URL WordPress

Сегодняшний пост посвящен размышлению о том, какими должны быть URL («урлы») постов и категорий сайта или блога на движке WordPress. Рассмотрим следующие вопросы:

  • Надо ли использовать ЧПУ (человеко-понятные урлы)?
  • Можно ли использовать кириллические URL?
  • Нужно ли удалять название категорий из URL?
  • Следует ли дописывать .html в конце урла поста?
  • Какие ярлыки должны быть у категорий (рубрик)?
  • Надо ли укорачивать URL?
  • Как изменить структура сайта?

В Интернете можно найти множество сайтов, которые себя неплохо чувствуют, хотя и не используют человеко-понятные урлы (ЧПУ). Применительно к WordPress, ссылка может иметь следующий вид https://mukhutdinov.com/?p=1700 (подобную ссылку можно получить, нажав в редакторе на кнопку «Получить короткую ссылку»). Плюс короткой ссылку кроется в её названии — она короткая и без проблем может быть опубликована в сообщении на любой сайте, например в Twitter (ограничение на длину сообщения в Twitter составляет 140 символов). Минусом является то, что по тексту ссылки не понятно, на какой именно документ она ведет. При использовании ЧПУ, ссылка выглядит более информативно https://mukhutdinov.com/skolko-mozhet-zarabotat-novichok-na-svoem-sajte.html — ясно, что она ведет на статью посвященную заработку на сайте.

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

«Желательно, чтобы вид URL давал представление о том, что содержится на соответствующей странице. Использование транслитерации в адресах страниц также позволит роботу понять, о чем может быть страница. Например, один только URL http://download.yandex.ru/company/experience/Baitin_Korrekciya%20gramotnosti.pdf дает поисковому роботу множество информации о документе: его можно скачать; формат, скорее всего, PDF; документ, вероятно, релевантен запросу «коррекция грамотности» и так далее.»

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

Ключевые слова из запроса, содержащиеся в URL, подсвечиваются в сниппете

Вывод: ЧПУ надо использовать, так как это полезно для пользователей, а что хорошо для пользователей, то хорошо и для поисковиков.

Кириллица в URL

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

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

Нужно ли прописывать категорию в URL?

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

Плюсы

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

Минусы

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

Робот Яндекса «не увидел» категорий на сайте

Теперь посмотрим на структуру сайта, в урлах которого присутствуют названия категорий.

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

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

1) Структура сайта site.ru, с точки зрения робота Яндекса, не содержит категорий, хотя категории есть и во многих из них более 10 публикаций. Я сделал вывод, что это связано с тем, что в URL документов не отображаются категории. Правильный ли вывод я сделал?

2) Насколько важна, с точки зрения робота Яндекса, разница между URL http://site.ru/dog.html и http://site.ru/animals/dog.html ?

Никакой разницы нет.

3) Если второй вариант правильный, то имеет ли смысл менять структуру URL, учитывая, что проиндексировано более 100 документов?

Нет, смысла менять структуру нет.

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

Цитата из справки Яндекса:

«Поддерживайте четкую ссылочную структуру на сайте. Каждый документ должен относиться к своему разделу.»

Если в урле содержится название категорий и подкатегорий, то по URL можно определить, к какому разделу относится документ.

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

Наличие .html в конце URL

Я не могу достоверно сказать, кто и когда додумался в конце динамической страницы, создаваемой WordPress, дописывать .html, однако идея прижилась. Для многих веб-мастеров, в том числе и для меня, наличие в конце урла .html является знаком того, что это пост (запись), а например, не категория или страница WordPress. На мой взгляд, подобное окончание урлов постов WordPress, снимает необходимость думать о том, должен ли присутствовать слэш в конце URL или нет. Соответственно, нет необходимости размышлять о 301-редиректе с URL без слэша на URL со слэшем и наоборот. С другой стороны, я бы сильно удивился, если бы увидел подобный подход на Яндексе или Google.

На сайте CNN.com, по умолчанию (основной URL) слеша в конце URL нет, но если его добавить, то страница доступна и по адресу со слешем: http://edition.cnn.com/v .

На сайте www.artlebedev.ru (студия Артемия Лебедева), кроме главной страницы, все URL заканчиваются слешем.

Итак, возможные варианты настройки ЧПУ для WordPress (в URL прописывается категория):

  1. /%category%/%postname%.html — в конце урла .html
  2. /%category%/%postname%/ — в конце урла слэш
  3. /%category%/%postname% — в конце урла не будет слэша (URL будет выглядеть так, как на большинстве топовых сайтов).

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


Ярлыки рубрик WordPress

В меню, названия рубрик могут быть написаны на кириллице, но ярлыки должны быть на латинице. При наличии плагина Rus-To-Lat, процесс транслитерации происходит автоматически. Однако во многих случаях, есть смысл укорачивать ярлыки, тем самым обеспечив меньшую длину URL (если категории прописываются в урле). Также, иногда, следует использовать английские слова, а не транслит. Возможные варианты:

  • Продвижение сайтов — «seo», а не «prodvizhenie-sajtov»;
  • Программное обеспечение — «soft», а не «programmnoe-obespechenie»;
  • Статьи — «articles», а не «stati»;
  • Книги — «books», а не «knigi».

Укорачивание урлов

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

Длину URL можно сократить как за счет ярлыка категории, так и за счет части, формирующейся на основе заголовка страницы (как правило, это заголовок уровня H1).

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

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

При изменение структуры сайта, воспользуйтесь справкой Яндекса:

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

Как одной командой изменить ссылки в базе данных или файлах

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

К примеру, у вас сайт на WordPress, использует БД MySQL и за несколько лет уже накопил тысячу статей. Править контекстные ссылки в каждой из статей будет долго, процесс можно автоматизировать, используя простой SQL -запрос и функцию REPLACE .

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

Вторым аргументом в функции REPLACE идет старый вариант адреса, третьим — новый адрес сайта. Не используйте здесь лишь части URL (например, протокол или доменную зону), так как вы можете затронуть и испортить другие ссылки в базе, которые вели не на ваш сайт. Лучше использовать ссылки в полном виде.

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

SQL -запрос для замены адресов в базе сайта на WordPress

В стандартной версии WordPress адреса хранятся лишь в двух местах. Это таблица wp_posts и колонки post_content и gu >SQL -запроса.

Консольные команды для замены ссылок в файлах

А что по поводу файлов с шаблонами? Для работы с ними я использую консоль (на Unix-подобных системах или под Mac). Для поиска и замены нужных текстовых участков в файлах можно использовать команду perl или sed (текстовый редактор), эти утилиты чаще всего уже установлены в системе.

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

Так как регулярные выражения используют слеши как разделители, то слеши в адресах ваших страниц нужно экранировать обратным слешем. Расширение .tpl дано для примера, у вас шаблоны могут храниться в php-файлах.

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

find . — type f -name «*.tpl» — exec sed -i » -e ‘ s / http: \/ \/ site . ru / https: \/ \/ site.ru / g ‘ < >\;

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

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

Изменить HTTP URL на лету

Можно ли изменить запрос HTTP пользователей на

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

После прибегая к помощи всю ночь, у меня нет свинца, но еще несколько вопросов:

  1. мне не нужно перехватывать каждый пакет через сеть. С некоторыми помогает, как iptables, я могу отфильтровать пакет, который я хочу. Я сделал это перед использованием iptables. Однако пакет не равен потоку HTTP. Нужно ли мне перестраивать HTTP?
  2. Если я успешно нашел способ изменения содержимого URL-адреса HTTP-запроса, я все равно должен вернуть его в сетевой поток. Поскольку я знаю, что TCP-пакеты имеют контрольную сумму, и после того, как я изменяю контент, это должно быть неправильно. Как вычислить новую контрольную сумму и вернуть пакет обратно в сеть?

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

Создан 05 окт. 12 2012-10-05 13:54:54 Alex Chen

Как использовать простые правила перезаписи на уровне сервера? Они должны быть подходящими для добавления параметров. – arkascha 05 окт. 12 2012-10-05 13:56:46

См. [Fiddler2] (http://www.fiddler2.com/fiddler2/) ‘Автоответчик’. AFAIK, вы можете использовать его библиотеки C#. – L.B 05 окт. 12 2012-10-05 14:01:28

@arkascha Правила перезаписи не могут удовлетворить мою потребность. Сайт не работает в моей компании, и я не могу его контролировать. – Alex Chen 05 окт. 12 2012-10-05 14:12:16

Тогда следите за тем, чтобы вы не поднимали никаких юридических вопросов. Перехват и изменение кого-либо elses communcation можно считать серьезным преступлением очень быстро . – arkascha 05 окт. 12 2012-10-05 14:14:58

@ L.B Интересно, как программист .net Я, Fiddler используется почти каждый день. Тем не менее, 30000 пользователей и более 1 миллиона активных подключений, возможно, немного перегружены для Fiddler? И я боюсь, что трудно использовать скрипт прозрачным для моих пользователей интрасети. – Alex Chen 05 окт. 12 2012-10-05 14:16:39

@arkascha Спасибо за внимание. Правовые вопросы не будут проблемой. Владелец сайта говорит нам, что больше не будет поддерживать свой продукт, и они предлагают нам делать то, что я ответил, как обходной путь. Как жаль, что они не могут предложить дальнейшую техническую поддержку в их «обходном пути». – Alex Chen 05 окт. 12 2012-10-05 14:19:55

Это ваше решение. Nevermhess позаботится о том, чтобы перехватить общение, как правило, делалось с добрыми намерениями, но общение защищено четкими законами. Просто потому, что вы и владелец сайта согласны с решением, это не значит, что это законно 🙂 – arkascha 05 окт. 12 2012-10-05 14:23:18

@arkascha Да, мне кажется, что моему боссу нужен какой-то закон, проделайте следующие работы: D – Alex Chen 05 окт. 12 2012-10-05 14:46:06

Это выполнимо, хотя есть вопросы. 1. Вы хотите только перехватить входящий запрос и дать ответ вернуться без вмешательства? Другой способ заключается в том, что вы сидите как средний человек, то есть получаете запросы, изменяете их, получаете ответ и отправляете обратно клиентам. Если это иначе, даже тогда вам нужно будет пересчитать контрольную сумму. 2. Какой язык? У некоторых есть api для пересчета контрольной суммы, которую вы можете записать при соответствующем смещении в пакете. tcprewrite — это одна утилита, которая позволяет переписывать контрольные суммы, но выполняется на файлах pcap, а не на лету. – fayyazkl 11 окт. 12 2012-10-11 11:52:44

Также вы можете настроить себя (т. е. узел в середине, который изменяет запрос как прокси). Конфигурация требуется на клиенте, чтобы использовать ваш как прокси-узел. В этом случае это было бы легко сделать. Прошу прояснить все эти вещи, и, надеюсь, вы сможете собрать базовый код для вас. – fayyazkl 11 окт. 12 2012-10-11 12:00:39

@fayyazkl Я хочу, чтобы все, что я делаю, прозрачно для конечного пользователя. Таким образом, прокси-сервер не может быть хорошим решением. Учитывая, что Linux-сервер с промежуточным сервером работает, C или C++ будут единственным выбором, который я знал достаточно хорошо. – Alex Chen 11 окт. 12 2012-10-11 16:44:17

@AntiGameZ Вы еще не ответили на другой вопрос. Ваш средний сервер получит запрос, изменит его и отправит. Получит ли средний сервер также ответ и придется отправить его окончательному клиенту? Или вы хотите, чтобы ответ был напрямую отправлен на клиентский и средний сервер, только перехватывает входящий запрос – fayyazkl 12 окт. 12 2012-10-12 07:30:57

Единственный вариант, который я вижу до сих пор, — это обратный прокси. Если прежний владелец больше не будет использовать сайт, возможно, вы, возможно, измените настройки DNS, чтобы указать на свой прокси-сервер, чтобы пользователи не думали, что они работают с оригинальным сайтом. – Stan 12 окт. 12 2012-10-12 17:57:12

Обращение к ** будет прозрачным **. Не делайте невидимым действие человека посередине. Верните HTTP-перенаправление HTTP 302. Это облегчает вашу работу. – Colonel Panic 12 окт. 12 2012-10-12 20:57:42

Здесь есть несколько серьезных архитектурных вопросов. Но я не думаю, что ваши намерения/цели четко заявлены, чтобы дать какой-либо полезный ответ. – Michael Brown 14 окт. 12 2012-10-14 12:20:12

@fayyazkl Мой запрос на межсетевой сервер только от моего внутреннего пользователя к внешнему сервису и заметил ответ с внешней службы. – Alex Chen 15 окт. 12 2012-10-15 07:52:17

@ColonelPanic Я попытался использовать nginx для решения проблемы. Nginx не может работать в зависимости от очень сложного детектора трансформации и состояния. – Alex Chen 15 окт. 12 2012-10-15 07:54:09

2 ответа

Это зависит от того, выполняете ли вы HTTP/1.0 или HTTP/1.1, и должен ли его первоначальный запрос изменять или все запросы в одном сеансе HTTP 1.1.

Если у вас есть пакет и вы можете его изменить до его отправки, и вы пытаетесь изменить только запрос, то укажите длину типичного пакета и местоположение URL-адреса в потоке запросов HTTP (очень близко к начало) и тот факт, что это будет первое, что отправлено в потоке TCP. Я думаю, что вы можете справедливо благополучно предположить, что он будет присутствовать в первых N байтах первого отправленного пакета и поэтому не будет разделен на несколько пакеты.

Однако, если это поток HTTP/1.1, то по одному и тому же TCP-соединению будет отправлено несколько запросов, и в этом случае в будущем запросы могут быть разделены на два TCP-пакета.

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

Однако это будет стоить новых TCP-соединений, которые довольно неэффективны.

Если вы этого не сделаете, и вы оставите его как HTTP/1.1, тогда URL-адрес может быть в любой случайной точке любого будущего запроса и, следовательно, разбит на несколько TCP-пакетов (два с реалистичным учетом размера URL-адреса).

Создан 12 окт. 12 2012-10-12 22:25:21 AntonyM

Добавить комментарий