- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Друзья, прошу Вашей помощи с WordPress.
Суть проблемы:
Был старый сайт с урловой структурой вида - site .ru/?page=1037#scroll или же site .ru/?page=1037 - это одно и то же, страница при обоих вариантах урла отдавала код 200 и открывала нужную страницу.
Сделали новый сайт с урловой структурой вида - site .ru/lechenie-boli/
Выкатили сайт в htaccess добавляем код:
Redirect 301 /?page=1050.* https://site .ru/narushenie-rechi/
Redirect 301 /?page=1054.* https://site .ru/lechenie-autizma/
И так далее, всего примерно 70 редиректов.
Что происходит:
Вышенаписанные правила 301 редиректа не работают, а работает что-то непонятное из WordPress - урл вида site .ru/?page=1037#scroll он тупо редиректит на https://site .ru/page/1037/#scroll при этом показывает главную и отдает код 200 OK (т.е. по сути открывается страница с листингом или пейджингом - как угодно). И так по каждой странице и это жесть жесткая, ведь в индексе обоих ПС именно эти кривые урлы, и они не клеятся с новыми урлами, т.к. код то 200 OK.
Пошел искать решение в сети, причем даже не знаю как сформулировать то эту проблему (поэтому сабж в заголовке такой кривой). Кое как нашел похожую ситуацию у Вити Карпенко (seo profy) тут https://seoprofy .ua/blog/sobytiya/kak-nas-zabanil-google-no-potom-pomiloval
Пункт №1 в ТЗ для прогера - 1) Убрать дубли (не понятно, почему они были, но были и это факт)
Такого плана:
https://seoprofy .ua/page/1
https://seoprofy .ua/page/2
В итоге они решили добавить в код правило, что если есть в главная и пагинация отдавать 404. НО нам то такой вариант не подходит, ведь нам надо конкретный старый урл посадить на новый правильный урл.
В итоге они решили, что это произошло из-за плагина который убирает /category/ из адреса рубрик. Но и это тоже не верно, потому что единственный плагин, который мог это сделать стоит Yoast seo. Мы его тупо отключили, чтобы проверить в нем ли проблема и она НЕ исчезла, т.е. плагин Yoast здесь не при чем. Это Что-то внутреннее из самого WordPress, что именно вопрос?
Самый ппц, что эта проблема есть у 99.99% сайтов на WP - можете проверить на своем если интересно - просто добавьте к урлу page123456 ,т.е. просто page и любой набор цифр - будет отдавать главную и 200 OK.
Подскажите, пожалуйста, что тут можно вообще сделать, чтобы наш редирект заработал и страницы из индекса склеились с новыми.
Я понимаю, что тут просто не фартануло со старыми урлами через page=12345, но решать задачу все-равно как-то нужно.
Если есть вопросы/уточнения - прошу в каменты.
Выкатили сайт в htaccess добавляем код:
Redirect
Это всё выкнуть нафик - ВП сам сделает редирект.
Сделали новый сайт с урловой структурой вида - site .ru/lechenie-boli/
Это всё выкнуть нафик - ВП сам сделает редирект.
WP-телепат? ))
В итоге они решили добавить в код правило, что если есть в главная и пагинация отдавать 404. НО нам то такой вариант не подходит, ведь нам надо конкретный старый урл посадить на новый правильный урл.
Можно раздуть .htaccess, можно прописать сопоставления старый URL-> новый URL и редиректить в PHP ещё до включения WP (а также любой другой CMS)..
Либо использовать какой-нибудь плагин (? стандартную функцию WP) для редиректа по REQUEST_URI. Думаю, SeVlad навскидку подскажет.. )
Вон, redirection нагуглился (работает с PHP 5.4 & higher))
WP-телепат? ))
Вполне возможно, если новый создан "на базе" старого.
Контент-то тот же. Вряд ли его копипастили вручную.
Но да... я упустил, что может быть и такой случай.
В таком случае нужны уточнения как сделан "новый".
Или хотя бы просто проверить для начала.
Не помешает и адрес сайта.
Вон, redirection нагуглился (работает с PHP 5.4 & higher))
фтопку плагины редиректа :)
онли хтацеес
фтопку плагины редиректа
Я там по соседству ссылку приводил.. как ни парадоксально (на первый взгляд?), реализация редиректа средствами PHP (возможно, и без плагинов Wordpress) может работать быстрее, нежели через .htaccess средствами сервера..
Вышенаписанные правила 301 редиректа не работают,
Так вы не правильно их установили.
Пример:
И ставьте свои правила выше правил WP. Так они будут приоритетнее.
Пример:
И так далее, всего примерно 70 редиректов.
Конечно это не очень хорошо.
---------- Добавлено 20.08.2019 в 20:11 ----------
Кстати, если домен не поменялся, можете так сделать:
---------- Добавлено 20.08.2019 в 20:36 ----------
fackest1, еще учтите, что в таком исполнении ссылки вида "/?page=12" и "/?page=12&что-то" будут редиректить на один и тот же url. Если такое не нужно, можно так сделать:
реализация редиректа средствами PHP (возможно, и без плагинов Wordpress) может работать быстрее, нежели через .htaccess средствами сервера..
Не может. Потому что не может быть никогда серверный редирект произойдет раньше, чем запуститься php и тем более отработает движок.
Что там по ссылке на форуме ВП я не осилил
Gerga, всё спалил. Теперь не узнаем что ТС натворил :)
Спасибо большое всем ответившим, особенно очень очень сильно благодарю Gerga, вопрос решен, спасибо Вам большое:
Редирект вида:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{QUERY_STRING} page=561
RewriteCond %{QUERY_STRING} page=520
RewriteRule ^/?$ https://site.ru/detskiy-nevrolog/? [R=301,L]
</IfModule>
Не сработал.
Правило прописал самым первым в htaccess - отдавал всё то же самое site.ru/page/561 показывается главная, код 200 ok. На сайте используется плагин WPRocket и он много чего прописывает в htaccess своего, но как уже написал, правило стояло первым и оно не работало.
Зато сработало вот это правило:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{QUERY_STRING} ^/?page=561$
RewriteRule ^/?$ detskiy-nevrolog/? [R=301,L]
</IfModule>
Уточнения - сам домен не менялся, но старый был на http, а новый на httpS и старый сайт был НЕ на WP.
Спасибо большущее очень хорошему человеку Gerga.
и старый сайт был НЕ на WP.
ааа.. Ну вот с этого надо было начинать. Тогда конечно ВП сам не сделает редирект и наверное лучше сделать в хтацессе.
Но наверное можно было и при импорте контент заполнить old_slug..
Ида. код на форум помещай в ббкод [code][/code]. Кнопка # в расширенном редакторе.
Не может. Потому что ...
Теоретик же )))))
с десяток регекспов в .htaccess // чего уж говорить про ...
... примерно 70 редиректов.
и построчное сравнение (поиск по ключу в массиве) на быстром php7.* ))
* без обработки этих регекспов (да и вообще, без загрузки mod_rewrite.. для каждого запроса... ;))
p.s. Можно было и осилить для начала..
p.p.s Можно и в .htaccess использовать сравнение строк, но в подавляющем большинстве примеров (и, как следствие - рабочих сайтов) используются регулярки..
Спасибо большое всем ответившим, особенно очень очень сильно благодарю Gerga, вопрос решен, спасибо Вам большое:
Пожалуйста :)
Gerga, всё спалил. Теперь не узнаем что ТС натворил
От блин, все испортил 🤣
да и вообще, без загрузки mod_rewrite.. для каждого запроса...
Так mod_rewrite полюбому будет загружаться. Хоть делайте на php, хоть через .htaccess. Удобнее конечно эти редиректы хранить не в .htaccess.
70 RewriteRule для каждого запроса и + 70 RewriteCond для главной - это много, я не знаю как это может сказаться.
Мне самому больше нравится вариант с делегированием в обработчик, а он уже пусть разбирается, кого-куда перенаправлять.