Permalinks — постоянные ссылки — являются одним из важных аспектов в технической поисковой оптимизации сайта на основе движка WordPress. Поисковые роботы при индексации сайта отдают предпочтение постоянным ссылкам, заканчивающимся расширением .html, по сравнению с динамическими.

По умолчанию динамическая ссылка в WordPress имеет вид http://your-site.ru/?p=39  (1,2,3,4 и т.д.).  В адресной строке браузера, методом запроса GET, через параметр p= передаётся идентификатор (номер) статьи (поста),  в данном случае — 39 (p=39), и движок сайта извлекает статью с таким номером из базы данных, формирует готовую страницу с ней, и выдаёт пользователю в браузере.

То же самое справедливо и для статических страниц сайта, динамические ссылки которых имеют вид — http://your-site.ru/?page_id=56, где идентификатор статической страницы в базе данных передаётся так же через метод GET в параметре page_id=.

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

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

И второе: с учётом поисков и архивов ссылка на один и тот же материал может иметь совершенно разный вид. Например: простая динамическая ссылка на материал — http://your-site.ru/?p=39. А вот так эта же страница будет выглядеть, найденная через поиск на сайте: http://your-site.ru/?s=кафельная+плитка, в данном случае через параметр s= будет передан поисковый запрос «кафельная плитка», и база данных выдаст тот же самый материал, но уже под другой ссылкой.

Или ещё пример: — http://test1.ru/?tag=kafelnaya-plitka, тут уже идёт поиск по тегам, которые указываются к каждому посту или странице при написании. То же самое относится к временным и к авторским архивам, методом GET через адресную строку браузера передаётся тот или иной параметр, и движок в базе данных по нему ищет релевантный (соответствующий) контент, выдавая его под той или иной ссылкой.

С точки-же зрения поисковой системы, все эти ссылки выглядят как РАЗНЫЕ страницы, с совершенно одинаковым контентом, что может быть воспринято поисковиком, как  СПАМ. В результате — угроза Бана. А это не есть гуд. И если в последнее время эту проблему стало возможным решить с помощью канонических ссылок — в шапке таких страниц прописывается единый адрес — то проблемы распыления ссылочного веса между ненужными ссылками (вместо передачи его на одну основную) это не решает.

Поэтому выходом из ситуации является замена динамических ссылок на постоянные.  Эта функция предусмотрена в WordPress, и реализуется следующим образом: в админ. панели переходим в раздел — параметры — постоянные ссылки, и указываем в общих настройках — произвольно. Указываем вид ссылок: — /%postname%.html.

Теперь все страницы с постами будут иметь вид http://your-site.ru/(название поста).html. Стоит уточнить, что для реализации этой функции ОБЯЗАТЕЛЬНО использование плагина RusToLat, который переводит русские символы в английские в URLе страницы.

Так же, к виду постоянных ссылок можно привести и ссылки на статические страницы сайта, для этого требуется установить плагин .html on PAGES, и тогда статические страницы так же будут иметь вид постоянных ссылок http://your-site.ru/(название страницы).html.

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