Головна › ПЗ › Як у PHP задати редирект на інший URL до завантаження сторінки? Євроліга чоловіки ucp php redirect

Як у PHP задати редирект на інший URL до завантаження сторінки? Євроліга чоловіки ucp php redirect

6.1K

Припустимо, що ви хочете, щоб користувачам, які переходять на сторінку https://example.com/initial.php, відображалася сторінка https://example.com/final.php . Це можна зробити за допомогою кілька методів PHP, JavaScript та HTML . У цій статті ми розповімо про кожен з методів, які можна використовувати для перенаправлення PHP на іншу сторінку.

Ось кілька змінних, які ми використовуватимемо:

Використання функції PHP header() для редиректу URL-адреси

Якщо хочете додати редирект з initial.php до final.php , можна помістити на веб-сторінці initial.php наступний код. Він відправляє в браузер новий заголовок location:

Тут ми використовуємо PHP-функцію header() , щоб створити редирект. Потрібно помістити цей код перед будь-яким HTML чи текстом. Інакше ви отримаєте повідомлення про помилку, пов'язану з тим, що заголовок вже надіслано. Також можна використовувати буферизацію виводу, щоб не допустити цю помилку надсилання заголовків. У наступному прикладі даний спосіб перенаправлення PHP показаний у дії:

Щоб виконати переадресацію за допомогою функції header() , функція ob_start() має бути першою в PHP-скрипті. Завдяки цьому не виникатимуть помилки заголовків.

В якості додаткового заходу можна додати die() або exit() відразу після редиректу заголовка, щоб решта коду веб-сторінки не виконувалася. В окремих випадках пошукові роботи або браузери можуть не звертати уваги на вказівку в заголовку Location. Що таїть у собі потенційні загрози для безпеки сайту:

Щоб прояснити ситуацію: die() чи exit() не мають відношення до редиректів. Вони використовуються для запобігання виконанню решти коду на веб-сторінці.

При перенаправленні PHP на сторінку рекомендується використовувати абсолютні URL-адреси при вказівці значення заголовка Location . Але відносні URL-адреси теж працюватимуть. Ви також можете використовувати цю функцію для перенаправлення користувачів на зовнішні сайти або веб-сторінки.

Виведення коду JavaScript-редиректу за допомогою функції PHP echo()

Це не є чистим рішенням PHP . Тим не менш, воно також є ефективним. Ви можете використовувати функцію PHP echo() для виведення коду JavaScript, який оброблятиме редирект.

Якщо ви скористаєтеся цим рішенням, то не доведеться використовувати буферизацію висновку. Що також запобігає виникненню помилок, пов'язаних із відправкою заголовків.

Нижче наведено кілька прикладів, у яких використані різні методи JavaScript для редагування з поточної сторінки на іншу:

Єдиним недоліком цього методу перенаправлення на інший сайт PHP є те, що JavaScript працює на стороні клієнта. А у ваших відвідувачів може бути відключений JavaScript.

Використання метатегів HTML для редиректу

Також можна використовувати базовий HTML для виконання редагування. Це може здатися непрофесійним, але це працює. І не потрібно турбуватися про те, що в браузері відключений JavaScript або раніше була відправлена помилка заголовків:

Також можна використовувати останній рядок з попереднього прикладу, щоб автоматично оновлювати сторінку кожні n секунд. Наприклад, наступний код автоматично оновлюватиме сторінку кожні 8 секунд.

Привіт друзі. Сьогодні хотілося б обговорити дуже заїжджену, але завжди актуальну тему – це 301 Редирект (Permanent Redirect 301) – у seo-тусовці і без формальностей саме це мається на увазі під словом «редирект». Технічно це є відповіддю сервера на звернення до нього, ця відповідь має код 301, що означає, що адреса звернення була змінена назавжди (moved permanently). В результаті всіх цих хитрих махінацій ми повинні отримати якусь нову кінцеву адресу.

Я вважаю, що вам не потрібні ці технічні аспекти, а тому хочу поговорити про прикладні речі – коли і в яких ситуаціях краще використовувати редирект, як і за допомогою яких команд можна налаштувати правила переадресації і т.д. А також розглянемо інструменти та послуги, за допомогою яких можна перевірити правильність редиректів.

Так як пост вийшов дуже великим, то я вирішив зробити зміст для вашої зручності:

Коли НЕОБХІДНО робити 301 редирект

Насамперед редирект застосовується, коли сторінка (група сторінок чи цілий розділ) змінила свою адресу — найчастіше це трапляється при зміні структури сайту, перейменуванні основотворчої частини URL або зміні принципу формування адрес (простіше кажучи, ЧПУ). На жаль, не всі про це замислюються, коли щось змінюють на сайті, і зрештою виникає купа дублів, що призводить до втрати позицій або навіть накладення санкцій з боку пошукових систем. По своїй роботі я дуже часто стикаюся з такими ситуаціями, і це коштує багато нервів, щоби все виправити і нівелювати наслідки. Від себе можу порекомендувати перед будь-якою роботою зі зміни типу ЧПУ чи переробці структури скласти план поточної структури сайту, всіх його розділів та прикладів кінцевих сторінок. Все це необхідно буде перевірити після завершення робіт, щоб при переході на стару адресу ми потрапляли на нову, а сервер віддавав редирект з кодом 301 (а не 302).

Наступний випадок використання 301 редиректу – зміна адреси сайту або склеювання дзеркал. Якщо ви вирішили змінити адресу сайту у зв'язку з ребрендингом компанії або зареєстрували новий красивіший і короткий домен для вказівки його на друкованій промо-продукції — дуже важливо, щоб при зверненні до адреси на старому домені користувач потрапляв на ту саму сторінку (а не на головну сторінку), але на новому домені. Що стосується промо-сайтів, то зазвичай вони складаються з однієї-двох сторінок, посилання з яких ведуть на основний сайт, або ж при переході на промо-сайт відразу відбувається редирект на спеціальну сторінку основного сайту. Ще іноді при створенні сайту реєструється відразу кілька доменів, наприклад, через неоднозначне написання імені компанії на латиниці. Щоб інтуїтивно набираючи адресу, користувач потрапив куди треба, і реєструються кілька доменів – дуже важливо, щоб з усіх «допоміжних» доменів відбувався 301 редирект на одну основну адресу. У жодному разі не можна допустити, щоб на всі адреси був доступний один і той же сайт.

І ще про дзеркала – може статися так, що ваш сайт буде доступний за адресами http://www.site.ru, http://site.ru та https://site.ru (останнє рідко, але буває) – це всі класичні помилки, яких не можна допускати, і в їх вирішенні якраз бере участь 301 редирект. Так само як і у випадку з різними адресами сайтів, необхідно визначитися з головним дзеркалом (з www або без www) та налаштувати редиректи на основне дзеркало. Звичайно, пошукові системи не дурні і в таких ситуаціях часто самі справляються, а так само їм можна допомогти, зробивши правильні налаштуванняу панелях вебмайстра та в robots.txt (для Яндекса, директива Host). Але seo - справа тонка, і я не став би покладатися на удачу, а скористався перевіреним способом!

Іноді трапляється дуже неприємна ситуація, коли копія сайту виявляється доступною не тільки при введенні в адресному рядку назви домену, але й IP-адреси сервера. Така ситуація навряд чи може статися на віртуальному хостингу, а от якщо у вас виділений сервер, то просто. Це може бути причиною некоректного налаштування сервера - вирішити проблему допоможе відключення можливості доступу при зверненні до ip-адреси, але найкраще тут виручить 301-редирект на рівні веб-вервера (apache або nginx). Кілька місяців тому у мене трапилася саме така ситуація – у мене був виділений сервер, на якому висіла частина сайтів, але під один із сайтів я вирішив взяти ще один окремий сервер. Я переніс сайт, все працювало як годинник, і ось одного разу натикаюся у видачі Гугла на клон мого сайту - шок, паніка - виявилося, що це ip адреса мого нового сервера і, зрозуміло, на ньому живе мій сайт, а при зверненні сервер дає відповідь 200 OK, і Google проіндексував його повністю. На попередньому сервері такої проблеми не було, там спочатку був налаштований 301-редирект з IP на домен, зазначений як основний для цього IP. Тепер я навчений гірким досвідом і завжди перевіряю такі речі – будьте в курсі і ви не повторюйте помилок. Проблему вирішили шляхом додавання до конфіг веб-сервера nginx 301 редиректа на основний домен, приклад коду покажу в практичній частині посту нижче.

Ситуація подібна до попередньої – коли копія сайту знаходиться і доступна через службовий тестовий домен, наприклад, виду site.hosting.ru. Такі випадки в моїй практиці теж трапляються, і, на відміну від попереднього випадку, це властиво для віртуального хостингу. Навіщо таке існує? Наприклад, у вас ще не куплений домен або ви переносите сайт з одного хостингу на інший, а NS сервера для домену не змінили або ще не оновилися запису DNSу провайдера. У таких ситуаціях і роблять тестові адреси, де ви можете все налаштувати та встановити, перш ніж перенаправляти адресу сайту на новий хостинг. І ось деякі хостери грішать тим, що не закривають доступ до таких технічних адрес і навіть не забороняють їх індексацію. Якщо і у вас трапилася ця неприємна ситуація, варто спробувати прописати 301-редирект з технічної адреси на основний у файлі.htaccess.

Ну і, звичайно, 301 редирект дуже люблять застосовувати правильні сеошники для боротьби з різними дублями сторінок. Чому лише правильні сеошники? Та тому, що неправильні хуй забили на сайт клієнта і, що цілком імовірно, навіть не заходячи на сайт стали закуповувати посилання – на жаль, це не рідкість. До мене періодично звертаються замовники, які хочуть перевірити сумлінність своїх підрядників/співробітників, які відповідають за оптимізацію та просування сайту, наскільки якісно йде робота – і поки що жодного разу не було такого, щоб я не знайшов на сайтах помилок чи недоробок. Тож майте на увазі – я завжди радий вам допомогти. Повернімося до дублів – я вважаю, що замість того, щоб закривати дублі від індексації, необхідно робити редирект на основну адресу, а це вже не так цікаво. Зрозуміло, існує безліч випадків, коли дублі вимушені, і тоді без канонізації не обійтися, але якщо є можливість зробити редирект, обов'язково робіть його. Часті випадки дублів, які необхідно перевіряти завжди: адреси зі слішем на кінці та без, адреси з параметрами та мітками – як це вирішувати, я розповім нижче.

Коли МОЖНА робити 301 редирект

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

Redirect 301 можна використовувати як відповідь сервера замість помилки 404 Not Found– іншими словами, користувач, перейшовши за неправильним посиланням або на неіснуючу сторінку, побачить не повідомлення, мовляв, «Вибачте, такої сторінки немає», а буде переміщений на іншу існуючу сторінку. Це дуже спірний момент серед фахівців, а тому я свою думку нікому не нав'язую. Але я волію використовувати саме редирект замість 404 помилки, і тут є кілька варіантів розвитку подій… Дивіться, є 2 категорії 404 помилок: перша – класична, коли сторінку дійсно видалили, друга – коли поява помилки пов'язана із кривими зовнішніми посиланнями. У першому випадку, напевно, не варто робити редирект, а залишити 404 помилку як вона є. А ось у другому випадку варто подбати редиректом на правильну URL-адресу, якщо її можна відновити з битого посилання, або редиректом на головну сторінку (або категорію).

Коли НЕ СЛІД робити 301 редирект

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

Найголовніше, щоб не зробити помилок, не варто зв'язуватися з редиректами, якщо ви на 100% не впевнені в тому, що ви робите або в чомусь сумніваєтеся. Прийміть це як дружня порада :)

Перманентний редирект не варто використовувати для тимчасових рішень, це очевидно з його назви – для тимчасового переміщення використовуйте 302 Moved Temporarily. При цьому не станеться склеювання сторінок і сторінку з редиректом можна буде будь-коли відновити.

Якщо з вашим доменом трапилися проблеми, наприклад, фільтри, бан і т.п., і ви вирішили змінити адресу сайту (домен), то не варто робити 301 редирект зі старого домену на новий - в результаті ви приклеїте до нового домену і усі проблеми старого. Тобто, зрештою, нічого й не зміниться. Так, був якийсь час рішення виходу з-під гугло-фільтра Пінгвін за допомогою повного 301-редиректу зі старого домену на новий. Дійсно всі позиції відновлювалися до рівня як до санкцій, і це здавалося панацеєю від злого Пінгвіна, але при черговому апдейті алгоритму ця особливість була врахована і новий домен також потрапляв під фільтр, в результаті нічого не покращувалося після зміни домену. Якщо ви вирішили змінити домен, то можна спробувати перенести весь контент на новий домен, а на старому його видалити і повісити заглушку з повідомленням про переїзд, а ще краще почати все з нуля.

Існує дуже багато способів зробити 301-редирект: через htaccess, php, javascript, налаштування сервера і т. д. - так от не треба намагатися використовувати відразу всі методи одночасно, занадто велика ймовірність «розбіжностей» між різними способамиі можна, наприклад, отримати нескінченний циклічний перенапрямок.

Коли ви працюєте зі складною структурою сайту або переробляєте великий портал, часто трапляються численні редиректи або довгі ланцюжки. Це означає, що редирект відбувається не в один крок, а в два і більше – це погана ситуація і її треба по можливості уникати. При переході за таким посиланням пошуковий робот, отримавши кілька перенаправлень поспіль, може подумати, що його обманюють і припинити слідувати далі і взагалі перестати враховувати посилання. Ось вам приклад з моєї практики, якось мені на аудит потрапив сайт з таким несподіваним ланцюжком:

http://site.ru/tax/term/30 ->
http://www.site.ru/tax/term/30 ->
http://www.site.ru/tax/term/30/ ->
http://www.site.hosting.ru/404.php ->
http://www.site.ru/404.php

А ще в результаті сторінка http://www.site.ru/404.php, яка повинна віддавати 404 помилки, дає відповідь 200 OK. Це навіть мені вибухнуло мозок, а уявіть, що подумав би пошуковий робот, потрапивши в таку карусель! Мало того, що в ланцюжку взяли участь три різні домени, то ще й сторінка помилки каже, що вона не помилка і її треба індексувати.

По можливості прагнете відсутності редиректів усередині сайту – якщо зовнішні посилання на сайт виправити вже не можна і редирект неминучий, то внутрішні посилання треба намагатися виправляти. Можливо, це й не позначиться на якості індексації та ранжируванні, але й не можна бути впевненим напевно, а тому краще уникати таких спірних ситуацій. У відстеженні внутрішніх редиректів і взагалі помилок усередині сайту вам допоможе чудова.

Складаючи прищеплення редиректів в.htaccess виключайте реальні адреси директорій та файлів на сервері та стежте за вибіркою. Ситуація для сайту, що потрапив мені одного разу на аудит – у боротьбі з дублями сторінок категорій зі слішем на кінці та без, вебмайстер перестарався небагато і навпаки лише посилив проблему. Мало того, що під правила перезапису потрапили і реальні файли js-скриптів та css-стилів, через що вони перестали коректно працювати, так ще й деякі сторінки отримали непотрібний сліш на кінці і з'явилися дублі. Друзі, ретельно стежте, щоб складені правила поширювалися лише на ту групу адрес, з якою ви працюєте, та обмежуйте всі інші.

Для пошуку проблемних сторінок та їх адрес, яких необхідно позбутися, використовуйте можливості панелей вебмайстра від Яндекс і Google. Для Яндекса Вебмайстер: Вибираємо сайт -> Індексування сайту -> Виключені сторінки. Для Google Webmaster: Вибираємо сайт -> Оптимізація -> Оптимізація HTML; А також: Вибираємо сайт -> Конфігурація -> Параметри URL.

Особливості індексації та переіндексації редиректів у Яндекс та Google. Коли ви боротиметеся з дублями і проблемними адресами, зрозуміло, ви будете чекати на видалення помилок з панелей вебмайстра, тут є деякі особливості. З Google все просто - налаштували редиректи, зміни проіндексуються протягом 2 тижнів, за цей час почнуть зникати помилки і з панелі вебмайстра, зазвичай через місяць всі помилки пропадають. З Яндексом є тонкість, і полягає в наступному - після проставлення редиректів можна чекати пропадання помилок з панелі вічно, я чекав одного разу півроку, поки не написав на підтримку, де мені повідомили, що крім редиректу необхідно додатково закрити проблемні сторінки в robots.txt і тільки тоді вони пропадуть із панелі вебмайстра.

Permanent Redirect 301 через.htaccess

Такий спосіб встановлення редиректів є найпопулярнішим і найпростішим. Хоча, зізнатися, далеко не все так просто, як здається, так що я планую написати окремий пост про htaccess. З плюсів даного способуможна відзначити, що редирект спрацьовує лише на рівні сервера до запуску обробки будь-яких скриптів сайту і несе додаткового навантаження.

У вас на сервері (докорінно, там де головний index.php) вже напевно є файл.htaccess. Якщо файл не видно:

Перевірте налаштування ftp-менеджера, він може приховувати системи не файли, яким і є файл htaccess
Зайдіть у файловий менеджерчерез панель керування хостера та перевірте права для файлу. Я маю на увазі не CHMOD, а групу та користувача, наприклад, там може стояти користувач root, а ви підключаєтеся через ftp, використовуючи доступ користувача власника домену.
Банально файлу може бути:) Тоді його слід створити, але під windows іноді виникає проблема, т.к. по суті файл.htaccess бачиться системою як файл без імені та лише з розширенням. Пропоную простий спосіб - створюємо звичайний txt-файл, додаємо в нього рядок "RewriteEngine On" (без лапок), завантажуємо txt-файл на сервер, на сервері перейменовуємо файл в.htaccess

Більшість правок, пов'язаних з редиректом, слід писати на самому початку файлу після рядка «RewriteEngine On» , щоб ці правила оброблялися в першу чергу. Важливо дотримуватись послідовність дій, т.к. команди обробляється сервером рядково від початку до першого входження. Інакше кажучи, треба завжди починати із приватною та закінчувати більш загальною вибіркою.

Давайте розглянемо кілька найпоширеніших і найкорисніших прикладів:

301 редирект для домену з www.site.ru на site.ru

RewriteCond %(HTTP_HOST) !^www\.(.*) RewriteRule ^(.*)$ http://www.%1/$1

Вищеописані варіанти редиректу добре працюють і вимагають жодних правок з вашого боку — лише вставити в.htaccess файл. Однак для 100% надійності я порадив би вам інший варіант:

RewriteCond %(HTTP_HOST) !^www.site.ru$ RewriteRule ^(.*)$ http://www.site.ru/$1

RewriteCond %(HTTP_HOST) !^site.ru$ RewriteRule ^(.*)$ http://site.ru/$1

Перший для тих, хто має основний домен з www, другий – хто без www. Відповідно в обох прикладах треба замість "site" вписати назву вашого домену.
Отже, чим же ці варіанти кращі? Дуже просто, вони перевіряють не тільки відсутність/наявність www в імені домену, але перевіряють ім'я домену на повну його відповідність.
Живий приклад: Напевно, ви стикалися з тим, що несподівано сайт може проіндексуватися за службовою адресою на хостингу (така адреса видається, щоб до сайту можна було звернутися до прив'язки вашого реального домену), якомусь дзеркалу або взагалі ip-адресі! Так ось універсальні правила лише верифікувати відсутність/наявність www, при цьому все одно, до якого домену звертається користувач або пошуковий робот.
Так ось скориставшись просунутим варіантом, ви на 146% будете впевнені, що ваш сайт буде доступний тільки і виключно за вказівним особисто вами доменного імені та з урахуванням www. Я користуюсь лише таким варіантом і вам рекомендую!

301 редирект з http на https

У світлі масового переходу сайтів на захищений протокол необхідно знати, як зробити редирект з http на https. До речі, якщо ви ще не обрали SSL-сертифікат, вам варто прочитати мій пост про .

Нижче я пропоную вам кілька варіантів 301 редиректу з протоколу http на https, які можуть працювати або не працювати в залежності від конфігурації саме вашого сервера, але якесь правило вам точно підійде:

RewriteCond %(HTTPS) !=on RewriteRule ^(.*)$ https://%(HTTP_HOST)/$1

RewriteCond %(SERVER_PORT) !^443 $ RewriteRule ^(.*)$ https://%(SERVER_NAME)%(REQUEST_URI)

RewriteCond %(SERVER_PORT) !^443$ RewriteRule ^(.*)$ https://%(SERVER_NAME)%(REQUEST_URI)

RewriteCond %(ENV:HTTPS) !on RewriteRule ^(.*)$ https://%(HTTP_HOST)%(REQUEST_URI)

RewriteCond %(HTTP:X-HTTPS) !1 RewriteRule ^(.*)$ https://%(HTTP_HOST)/$1

RewriteCond %(HTTPS) off RewriteCond %(HTTP:X-Forwarded-Proto) !https RewriteRule ^(.*)$ https://%(HTTP_HOST)%(REQUEST_URI)

Редирект з протоколу https на http (чесно, не знаю, навіщо вам це знадобиться):

RewriteCond %(HTTPS) =on RewriteRule ^(.*)$ http://%(HTTP_HOST)/$1

Нещодавно я написав дуже докладну інструкцію. Якщо ви плануєте переїзд із https на https, ви зобов'язані її прочитати!

Внесу деяку ясність у незрозумілу абракадабру:

RewriteCond означає умову, при збігу з якою буде виконано правило RewriteRule. За допомогою регулярних виразівзадаються шаблони рядків.
Змінні сервери:
- %(REQUEST_URI) — частина урла без доменного імені та GET-параметрів, наприклад, для сторінки, яку ви читаєте: blog/post/4393 ,
- %(HTTP_HOST) - хост або доменне ім'янаприклад: сайт
- %(QUERY_STRING) — рядок із набором GET параметрів, тобто частина урла після знака питання (і до ґрат якоря, якщо він є).
- %(REQUEST_FILENAME) - повний шляхв файловій системісервера до файлу або скрипту, що відповідає цьому запиту..php, а ось у файловій системі сервера це страшний рядок /var/www/сайт/data/www/сайт/index.php.
  Буває, роблячи редирект, ви отримуєте несподіваний результат, наприклад, хотіли за адресою http://site.ru/page-name?post=17434801_4060 прибрати параметри отримали рядок http://site.ru/usr/local/www/site.ru/www/page-name - параметрів позбулися, але отримали дивну адресу. Це все тому, що ви не вказали на початку файлу після RewriteEngine On директиву RewriteBase /, яка встановлює конкретну, базову URL для перетворень у контексті каталогу.
Метасимволи використовуються для завдання груп символів або позначок у шаблоні:
- ^ - Мітка початку рядка,
- $ - Мітка кінця рядка,
- ! - Заперечення,
- \ - екрануючий сліш, дозволяє вважати наступний за ним метасимвол звичайним символом,
- . – точка, що означає будь-який символ, але тільки один,
- () – угруповання.
Модифікатори ставляться після звичайних символів, метасимволів або їх груп та розширюють можливості використання шаблонів:
- ? символ повторюється 0 або 1 раз,
- * - Повторюється від 0 до 65536 разів,
- + - Повторюється від 1 до 65536 разів.
Прапори визначають додаткові опції для цього правила та перераховуються в квадратних дужкахчерез кому:
- NC – (nocase) вимикає перевірку регістру символів.
- R - (redirect) зупиняє процес перетворення і повертає результат браузеру клієнта як редирект на цю сторінку(302, MOVED TEMPORARY). З цим прапором можна вказати інший код результату, наприклад, R=301 поверне редирект з кодом 301 (MOVED PERMANENTLY). Як ви розумієте, це те саме, що нам треба.
- L - (last) зупиняє процес перетворення, і поточне посилання вважається остаточним.

Найпопулярніший випадок – 301-редирект з index.php (html) на головну сторінку. На 90% сайтів зустрічається проблема дублювання головної сторінки за адресами http://site.ru та http://site.ru/index.php (або index.html, index.htm або будь-який інший варіант, не принципово, а то й все відразу). Десь це явно коли, наприклад, посилання з логотипу веде на site.ru, а посилання в меню веде на site.ru/index.php, десь не явно, коли дубль знаходиться при введенні адреси з index.php вручну . Важливо просто вирішити проблему. І я пропоную універсальний варіант, ось він:

RewriteCond %(THE_REQUEST) ^(3 ,9 )\ /index\.(php|html|htm)\ HTTP/ RewriteRule ^(.*)index\.(php|html|htm)$ $1

RewriteCond %(THE_REQUEST) ^(3,9)\ /index\.(php|html|htm)\ HTTP/ RewriteRule ^(.*)index\.(php|html|htm)$ $1

Просто вставте цей код без змін після рядка після рядка RewriteEngine On і немає проблем!

Багато хто, хто починає боротися з дублями на сайті, задаються питанням, а звідки беруться такі посилання, які дублюють основну сторінку http://site.ru/page-name.html&post=-1234567_8901 ? Звідки взялася приставка &post=-1234567_8901 – це «добро» береться з вконтакте, коли хтось ділиться посиланням на ваш сайт у себе на стіні, групі чи паблиці, то автоматично додається подібний рядок, мабуть, для відстеження якоїсь статистики.

Щоб позбутися цієї нісенітниці раз і назавжди необхідно додати в htaccess:

RewriteCond %(REQUEST_URI) ^(.*)\&sa= RewriteRule ^(.*)\&sa=(.*)$ $1

Як бачите, ніякої різниці між цим і попереднім випадком немає, нехай у вас в url'е буде &post= або &sa= або будь-що - рішення однакове, просто треба замінити очевидні частини коду. Зрозуміло ж, правда?

Позбавляємося параметрів або міток на адресу

Питання ставилося і в коментарях і багато разів на форумі, тому не можна його оминути. Що робити ось з такими дублями: http://site.ru/?abrakadabra або реальніший випадок http://site.ru?utm_source=twitterfeed&utm_medium=twitter

Даний випадок трохи відрізняється від наступного пункту, де ми позбавлятимемося параметрів для php-скрипта, тому що тут звичайна адреса і параметри в скрипт ми не передаємо. Ось рішення:

RewriteCond %(QUERY_STRING) ^lang=ua$ RewriteRule ^(.*)\.php\?(.*)$ $1\.php

%(QUERY_STRING) — це рядок із набором змінних для PHP, частина урла після знака питання (і до ґрат якоря, якщо він є).

Викликаємо url - http://site.ru/index.php?lang=ru

RewriteCond %(QUERY_STRING) ^lang=ua $
Запитуваний url підпадає під це правило, інших правил немає, тому буде виконаний RewriteRule рядком нижче.
RewriteRule ^(.*) \.php\?(.*) $ $1 \.php

Вихідний url: http://site.ru/index.php?lang=ru
Шаблон розбирання URL: ^(.*) \.php\?(.*) $
URL буде розібраний за змінними: $1 = http://site.ru/index $2 = lang=ru і зібраний назад вже у вигляді http://site.ru/index .php ($1 \.php)
А далі буде 301 редирект на новий URL.

Приклад правил зміни структури сайту

RewriteRule ^post/category/(.*)$ blog/category/$1 RewriteRule ^post/(.*)$ blog/post/$1

Ось такі рядки мені довелося додати файл htaccess, коли я змінив структуру свого блогу.

Раніше у мене були адреси такі: https://сайт/post/4358 і https://сайт/post/category/seo, що якось ламало логіку в структурі – адже блог це лише частина сайту, але чомусь пости належать сайту, а не блогу, а категорії належать постам, що теж зовсім нелогічно.

З цього прикладу видно, що важливо дотримуватися послідовність правил. Якби я поміняв рядки місцями, тобто попереду б йшов рядок RewriteRule ^post/(..info/blog/post/category/seo а не як слід на https://сайт/blog/category/seo).

І останній приклад – розбір частої помилки з адресою від кореня сервера

Наприклад, ви вирішили виправити таку проблему, коли сторінка категорії доступна за двома адресами http://site.ru/razdel/podrazdel/index.php та http://site.ru/razdel/podrazdel/. Другий url є правильним і основним, а url з index.php на кінці є повним дублем, якого необхідно позбутися.

Для того щоб зробити редирект з index.php на категорію ви прописуєте правило:

RewriteEngine On RewriteBase /

301-редирект зі сторінки на сторінку, на нову адресу

Найпростіший випадок, коли треба зробити редирект однієї сторінки на іншу адресу. Якщо вам потрібно зробити редирект для кількох сторінок, доведеться писати кілька правил, але у разі краще скористатися шаблонами, описаними вище. Є кілька абсолютно ідентичних варіантів синтаксису:

Redirect 301 /page-name1.html http://site.ru/page-name2.html Redirect permanent /page-name1.html http://site.ru/page-name2.html RedirectPermanent /page-name1.html http ://site.ru/page-name2.html

Вибирайте один із трьох, а особисто я віддаю перевагу першому варіанту — він коротший, простий і зрозуміліший. До речі, тут site.ru може бути не обов'язково тим самим доменом, але будь-яким іншим.

На цьому закінчимо с.htaccess і перейдемо до PHP.

Permanent Redirect 301 за допомогою PHP

Зазвичай PHP редирект я використовую, коли виникають труднощі с.htaccess або виявляється так, що функція на php виявляється більш логічною та зрозумілою.

Сам синтаксис 301 редиректу на php виглядає так:

header(); header ("Location: http://site.ru"); die("Redirect");

header("HTTP/1.1 301 Moved Permanently"); header("Location: http://site.ru"); die("Redirect");

Ці рядки повідомляють браузер клієнта, що з якоїсь запитаної сторінки необхідно зробити перманентний редирект на адресу http://site.ru. При цьому http://site.ru може бути не тільки адресою головної сторінки поточного сайту, але може бути будь-яким іншим сайтом. Якщо щось пішло не так і сталася помилка, то у вікні браузера ми побачимо напис «Redirect».

Щоб було зрозуміло, наведу кілька прикладів функцій, які я написав для свого блогу сайт, намагаючись вирішити певні завдання.

Функція, що дозволяє прибрати певний шматок із url

if (strpos($_SERVER["REQUEST_URI" ], "http://сайт" ) !== false) ( $real_page_url = "http://сайт" .str_replace ("/http://сайт" , "" , $_SERVER["REQUEST_URI" ]); header ("HTTP/1.1 301 Moved Permanently" );

if (strpos($_SERVER["REQUEST_URI"], "http://сайт") !== false) ( $real_page_url = "http://сайт"..1 301 Moved Permanently"); header("Location: $real_page_url"); die("Redirect"); )

Якось у мене виникла проблема, що в панелі вебмайстра вилізла купа 404 помилок, адреси цих сторінок були виду https://alaev. звідкись на адресі з'явилася дублююча адреса сайту. І тоді я написав функцію, яка перевіряє, чи є в URI (зауважте, не URL, а URI) входження «http://сайт», і якщо є присутнім, то вирізаємо з адреси цей шматок і записуємо результат у змінну $real_page_url, а Потім робимо 301-редирект на правильну адресу зі змінної.

Функція, що прибирає кінцевий сліш з url

if (($_SERVER["REQUEST_URI" ], - 1 , 1 ) == "/" ) ( $requested_url = rtrim($requested_url, "/" ); header ("HTTP/1.0 301 Moved Permanently" ); header ( "Location: $requested_url" ); die("Redirect" ); )

if (($_SERVER["REQUEST_URI"], - 1, 1) == "/") ( $requested_url = rtrim($requested_url, "/"); header("HTTP/1.0 301 Moved Permanently"); header( "Location: $requested_url"); die("Redirect"); )

Ось така ось найпростіша функція, яка дивиться, чи є в запитаному адерсі сторінки слєш на кінці, і якщо він є, то слєш обрізається і відбувається 301-редирет на адресу без слєша.

Існує ще маса варіантів, що дозволяють віддавати команду перенаправлення різними мовами програмування, типу ASP, Ruby on Rail і т.д., але я з цими мовами не знайомий, тому не розумітиму і пудрити вам мізки. Ще можливі редиректи за допомогою метатегу meta refresh, а також редиректи на javascript – але це доля нечистих на руку дорвейщиков, а пошуковики ці редиректи не розуміють, вони одержують відповідь від сервера 200 OK. Тож ці варіанти ми не розглядаємо.

Permanent Redirect 301 для сервера nginx

Пам'ятаєте я писав про дзеркало мого сайту, доступного по IP? У результаті проблему вирішили редиректом, прописаним у файлі конфігурації сервера, зазвичай він розташований тут /etc/nginx/nginx.conf. Там прописали такі рядки:

server ( listen 1.2.34.123:80 default; server_name _; rewrite ^/(.*)$ http://site.ru/$1 permanent; )

Тут йдеться про те, що якщо йде звернення до IP-адреси через 80-й порт, то необхідно робити permanent redirect на site.ru.

Однак техпідтримка не рекомендувала мені так чинити зі словами: «Більше коректно буде налаштувати HTTP-сервер таким чином, щоб він просто закривав з'єднання, якщо до нього звертаються за адресою, яка не вказана явно в конфігурації HTTP-сервера, це найбільш надійний, простий , безпечний і найвибагливіший до ресурсів сервера варіант. Через деякий час сторінки, які будуть недоступні, швидше за все, будуть викинуті з індексу пошукових систем.

Наступна порада була така: «Коли потрібно просто закривати з'єднання замість перенаправлення, то вкажіть замість рядка "rewrite ^/(.*)$ http://site.ru/$1 permanent;" такий рядок "return 444;". Потім виконайте "invoke-rc.d nginx reload"».

Раптом це комусь допоможе.

Приклади редиректів у найпоширеніших випадках

Редирект для домену www.site.ru на site.ru

server ( listen 80; server_name site.ru; rewrite ^ http://www.site.ru$request_uri? permanent; )

Редирект з адреси http://site.ru/index.php на http://site.ru/

location = /index.php ( if ($request_uri = /index.php) ( rewrite ^ http://$host? permanent;#301 redirect ) fastcgi_pass unix:/tmp/fastcgi.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params;

От якось так. Я в налаштуваннях конфігів для nginx не сильний, завжди обходжуся налаштуваннями апача, так що якщо у вас з'явилися якісь питання щодо nginx, то я навряд чи зможу вам допомогти.

Як перевірити HTTP заголовки та статуси відповіді сервера

Я хотів у цьому розділі описати різні сервіси та плагіни для перевірки відповіді сервера, але розумію, що цей пост вже настільки великий за обсягом, що доведеться обмежитися просто посиланнями на розширення браузерів Chromeта Firefox.

Додаток HttpFox для Firefox

HttpFox (ось посилання на аддон) – це мій улюблений інструмент відстеження http-заголовків. HttpFox рядковим чином показує хід завантаження сторінки, що дозволяє відстежувати, наприклад, ланцюжки редиректів і взагалі порядок і швидкість завантаження сторінки. Якщо ви користуєтеся Мозиллою, то рекомендую.

Розширення HTTP Headers для Chrome

Сам я не користуюсь розширенням HTTP Headers (ось посилання на нього), але інтернети мені порадили звернути увагу саме на нього. Якщо у вас є кращі варіанти, будь ласка, відпишіться в коментарях.

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

Конфігураційний файл .htaccess є конфігом для веб-серверів на Apache. Більшість хостингів працюють через цей сервер, тому на кожному сайті є цей файл. Вебмайстри можуть частково керувати його роботою, вносячи до нього свої зміни. У цій статті ми розглянемо директиви та правила, які можна міняти у роботі сервера.

Найголовніший файл .htaccess розташовується в корені сайту:

Його дії поширюються на поточний каталог і всі вкладені каталоги. Тобто. власники сайтів мають можливість впливати тільки на роботу свого проекту, не заважаючи роботі всього сервера. Якщо цей файл відсутній, його можна створити за допомогою будь-якого блокнота. Головне, щоб назва файлу була ".htaccess" - без форматів .txt, .doc і т.д.

Через файл .htaccess найчастіше налаштовують 301 редирект на рівні сервера, що сильно прискорює процес переходу на нову сторінку, т.к. не треба завантажувати проміжну сторінку. Також тут прописується який файл обробляє 404 помилки.

Трохи нижче ми розглянемо всі поширені варіанти редиректів через .htaccess, а для початку ознайомимося з опціями та правилами.

Щоб мати можливість працювати з редиректами потрібно включити модуль ReWriteEngine. Для цього необхідно прописати два рядки коду (бажано в самому верху файлу .htaccess):

Options +FollowSymLinks RewriteEngine On

Розмістіть ці рядки у верхній частині файлу .htaccess , щоб мати можливість працювати з директивами модуля mod_write.

Також на хостингу мають бути включені модулі mod_alias (для підтримки Redirect, RedirectPermanent та RedirectMatch).

1. Правила Redirect, RewriteRule та RewriteCond 1.1. Директива Redirect

Синтаксис Redirect:

Redirect /звідки http://куди_повна_адреса

Redirect встановлює прямий редирект з однієї сторінки на іншу.

У status пишуть код редиректу. Необов'язковий параметр. Найчастіше пишуть 301, що сигналізує про постійну зміну адреси сторінки.

Важливо, щоб сторінка "звідки" була прописана у форматі без вказівки на повну адресу сайту, але із зазначенням повної відносної адреси URL починаючи зі слеша "/" (тобто з кореня сайту). Сторінку куди йде редирект необхідно писати повністю, тобто. абсолютна адреса сторінки URL (тобто з назвою домену та протоколу http або https).

Наприклад

Redirect 301 /oldpage.php http://site/newpage.php

Можна також писати інакше

RedirectPermanent 301 /oldpage.php http://site/newpage.php або Redirect permanent 301 /oldpage.php http://site/newpage.php 1.2. Директива RewriteRule

Директива RewriteRule визначає правила переходу. Синтаксис наступний:

RewriteRule Шаблон Підстановка [коди]

При зовнішньому редиректі змінюється урл адреси в рядку браузера - " "
При внутрішньому - не змінює урл адреси в рядку браузера - " " або "[L] "

1.3. Директива RewriteCond

Директива RewriteCond визначає умови, за яких виконуються правила в RewriteRule.

RewriteCond Порівняна_Рядок Умова

Наприклад, цими умовами можуть бути браузер користувача, IP-адреса, заголовок і т.д.

1.4. Директива RedirectMatch

Директива RedirectMatch аналогічна Redirect з тією різницею, що дозволяє записувати регулярні вирази.

RedirectMatch Звідки Куди 2. Приклади 301 редиректів в.htaccess

Ми вже розглядали безліч прикладів з редиректом з .htaccess у статтях:

Зміна адреси сайту - редирект зі старого домену на новий

Тут ми доповнимо варіанти редиректів, яких ще не було.

2.1. Редирект з однієї сторінки на іншу

Редирект із site.ru/cat/oldpage на site.ru/newpage.html

RewriteRule ^cat/oldpage.* /newpage.html

Або другий варіант:

Redirect 301 /cat/oldpage http://www.site.com/newpage.php 2.2. Редирект з усіх файлів.htm на.html RewriteCond %(REQUEST_FILENAME) !-f RewriteRule ^(.*)\.htm$ $1.html

Або другий варіант:

RewriteRule ^(.*)\.htm$ $1.html 2.3. Редирект всього каталогу на іншу сторінку

З будь-якої сторінки в каталозі та підкаталогах /old/ буде відбувається редирект на /new.php

RewriteRule ^old(.*)$ /new.php 2.4. Видалення зайвих слешів в URL

Наприклад, сторінка /catalog///stranica.html доступна та відкривається. Щоб уникнути такої ситуації і не плодити нескінченну кількість дублів слід записати наступний редирект

RewriteCond %(REQUEST_URI) ^(.*)//(.*)$ RewriteRule . %1/%2 2.5. Реврайт без редиректу

Можна завантажити іншу сторінку без зміни адреси сторінки URL-адреси. Наприклад, завантажимо сторінку /news.html , а в адресному рядку буде відображатися адреса /news/happy

RewriteRule ^news/happy.* /news.html [L] 2.6. Проставляння замикаючого слюша в кінці адреси головна сторінка

Наприклад, багато серверів працюють так, що останній слеш не пишеться в URL. Наприклад, http://site.ru. Нижче наведений код вирішують цю проблему: сайт відкриватиме http://site.ru/

RewriteCond %(REQUEST_URI) /+[^\.]+$ RewriteRule ^(.+[^/])$ %(REQUEST_URI)/ 2.7. Видаляємо директорію каталогу з URL

Наприклад, для редиректу зі сторінки site.com/directoriya/stranica.html на site.com/stranica.html потрібно прописати наступне:

RewriteRule ^directoriya/(.+)$ http://site.com/$1

Або другий варіант:

RewriteCond %(DOCUMENT_ROOT)/directoriya/$1 -f RewriteRule ^(.*)$ directoriya/$1 2.8. Редирект GET параметрів

Наприклад, зробити редирект зі сторінки /?act=page&id=2 на /page-2/

RewriteCond %(QUERY_STRING) act=page RewriteCond %(QUERY_STRING) id=(\d+) RewriteRule .* /page/%1/? ] 2.9. Редирект на мобільну версіюсайту m.site.ru

У цьому прикладі спочатку перевіряється факт того, що користувач відкрив сайт з мобільного пристрою(HTTP_USER_AGENT) , далі відбувається заміна адреси сайту на m.URL

Наприклад, виконаємо редирект з будь-якої сторінки піддомену poddomen.site.ru на основний домен site.ru

RewriteCond %(HTTP_HOST) ^poddomen.site.ru$ RewriteRule ^(.*)$ http://site.ru%(REQUEST_URI) 3.Інші приклади з htaccess 3.1. Заборонити IP-адресу та браузер

Заборонимо відкривати сайт для користувача з браузера IE з IP-адресою 172.111.222.55

RewriteCond %(HTTP_USER_AGENT) MSIE RewriteCond %(REMOTE_ADDR) ^172\.111\.222\.55$ RewriteRule ^.*$ - [F] 3.2. Заборонити конкретний файл

Заборонимо для всіх файл disable_file.html :

deny from all 3.3. Дозволити доступ з одного IP

Доступ буде дозволено лише з однієї IP-адреси 172.111.222.55

order deny,allow deny from all allow from 172.111.222.55 3.4. Заборонити доступ з різних IP

Заборонити доступ до сайту з кількох ip-адрес 172.112.222.55, 172.113.222.55, 172.114.*.*

orden deny,allow deny from all deny from 172.112.222.55 deny from 172.113.222.55 deny 172.114.*.* 3.5. Редирект в URL із великих символів на маленькі

Усі великі літери в URL-адресі будуть переведені на маленькі.

RewriteRule - RewriteRule! - RewriteRule ^([^A]*)A(.*)$ $1a$2 RewriteRule ^([^B]*)B(.*)$ $1b$2 RewriteRule ^([^C]*)C(.* )$ $1c$2 RewriteRule ^([^D]*)D(.*)$ $1d$2 RewriteRule ^([^E]*)E(.*)$ $1e$2 RewriteRule ^([^F]*) F(.*)$ $1f$2 RewriteRule ^([^G]*)G(.*)$ $1g$2 RewriteRule ^([^H]*)H(.*)$ $1h$2 RewriteRule ^([^ I]*)I(.*)$ $1i$2 RewriteRule ^([^J]*)J(.*)$ $1j$2 RewriteRule ^([^K]*)K(.*)$ $1k$2 RewriteRule ^([^L]*)L(.*)$ $1l$2 RewriteRule ^([^M]*)M(.*)$ $1m$2 RewriteRule ^([^N]*)N(.*)$ $1n$2 RewriteRule ^([^O]*)O(.*)$ $1o$2 RewriteRule ^([^P]*)P(.*)$ $1p$2 RewriteRule ^([^Q]*)Q( .*)$ $1q$2 RewriteRule ^([^R]*)R(.*)$ $1r$2 RewriteRule ^([^S]*)S(.*)$ $1s$2 RewriteRule ^([^T] *)T(.*)$ $1t$2 RewriteRule ^([^U]*)U(.*)$ $1u$2 RewriteRule ^([^V]*)V(.*)$ $1v$2 RewriteRule ^( [^W]*)W(.*)$ $1w$2 RewriteRule ^([^X]*)X(.*)$ $1x$2 RewriteRule ^([^Y]*)Y(.*)$ $1y $2 RewriteRule ^([^Z]*)Z(.*)$ $1z$2 RewriteRule - [N] RewriteCond %(ENV:HASCAPS) TRUE RewriteRule ^/?(.*) /$1

Досить важливий моментпід час налаштування сайту. Неправильно налаштований редирект може пошкодити пошукової видачі сайту. Найпоширеніші ситуації, в яких припадає використання Permanent Redirect 301:

Зміна адреси сайту – ви купили свій домен і вирішили переїхати з site.example.com на site.ru
Склейка дзеркал - якщо ваш сайт доступний за адресою www.site.ru та site.ru, пошукові системиможуть порахувати це як два різні сайти, тому спочатку необхідно визначитися з головним дзеркалом (з www або без www) і налаштувати редиректи на основне дзеркало.
Коли сторінка (одна або кілька) змінила свою адресу - в якийсь момент стало зрозуміло, що адреси http://example.com/index.php?option=com_content&task=view&id=23&Itemid=1 не є добре, і потрібно їх переробити в http://example.com/sport/news12 , але шкода втрачати позиції в індексі пошукових систем (оскільки для них це буде нова стаття).
Ще один спосіб для боротьби з дублями сторінок

Важливо: якщо сторінку переміщено тимчасово використовуйте 302 Moved Temporarily. Склейки сторінок у цьому випадку не станеться і сторінку з редиректом можна завжди відновити.

Permanent Redirect 301 для apache (.htaccess)

Вставляти правила потрібно відразу після рядків:

RewriteEngine On RewriteBase / # щоб обрізати повний шлях, від кореня сервера до кореня сайту

самі правила задаються за допомогою регулярних виразів, нагадаємо синтаксис:

Метасимволи, для завдання груп символів або позначок у шаблоні:
- ^ - мітка початку рядка,
- $ - мітка кінця рядка,
- ! - заперечення,
- \ - екрануючий сліш, дозволяє вважати наступний за ним метасимвол звичайним символом,
- . - точка, що позначає будь-який символ, але тільки один,
- () - Угруповання.
Модифікатори ставляться після звичайних символів, метасимволів або їх груп:
- ? - символ повторюється 0 або 1 раз,
- * - повторюється від 0 до 65536 разів,
- + - повторюється від 1 до 65 536 разів.
Прапори визначають додаткові опції для даного правила:
- NC – (nocase) відключає перевірку регістру символів.
- R - (redirect) зупиняє процес перетворення та повертає результат браузеру клієнта як редирект на цю сторінку (302, MOVED TEMPORARY).
  З цим прапором можна вказати інший код результату, наприклад, R=301 поверне редирект з кодом 301 (MOVED PERMANENTLY). Як ви розумієте, це те саме, що нам треба.
- L - (last) зупиняє процес перетворення, і поточне посилання вважається остаточним.

Розглянь ситуації, що найчастіше зустрічаються:

RewriteCond %(HTTP_HOST) ^www\.(.*) RewriteRule ^(.*)$ http://%1/$1 RewriteCond позначаємо умову, при збігу з якою буде виконано правило RewriteRule. Редирект з index.php (html) на головну сторінку RewriteCond %(THE_REQUEST) ^(3,9)\ /index\.(php|html|htm)\ HTTP/ RewriteRule ^(.*)index\.(php|html |htm)$ $1 Редирект при зміні структури сайту RewriteRule ^post/category/(.*)$ blog/category/$1 RewriteRule ^post/(.*)$ blog/post/$1 Permanent Redirect 301 на PHP

Щоб повідомити браузеру про те, що із запитаної ним сторінки потрібно зробити редирект на адресу http://site.ru виконайте команди:

Header("HTTP/1.1 301 Moved Permanently"); header("Location: http://site.ru"); exit();

Permanent Redirect 301 для nginx

Правила редиректу описуються у секції server.

Редирект з www.site.ru на site.ru server ( listen 80; server_name www.site.ru; rewrite ^ http://site.ru$request_uri? permanent; )

або загальне правилодля всіх сайтів:

Server ( server_name ~^(?! www\.); rewrite ^ http://www.$host$request_uri permanent; )

Редирект для з site.ru на www.site.ru server ( listen 80; server_name site.ru; rewrite ^ http://www.site.ru$request_uri? permanent; ) Редирект з index.php на головну сторінку location = / index.php ( if ($request_uri = /index.php) ( rewrite ^ http://$host? permanent;#301 redirect ) fastcgi_pass unix:/tmp/fastcgi.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root fastcgi_script_name;include fastcgi_params;

Код стану HTTP (англ. HTTP status code) зі статусом 301 Moved Permanently (Переміщено остаточно) свідчить про те, що запитаний документ остаточно перенесено на новий URI, зазначений у полі Location заголовка.

Для чого це потрібно?

Насамперед, при зміні доменного імені сайту, необхідно сповістити пошукові системи про зміну адреси сайту. По-друге, для склеювання імені сайту з www і без нього. По-третє, для швидкої передачі Page Rank на новий сайт.

PHP

Спосіб перший

Спосіб другий

Perl

Спосіб перший

$ cgi = новий CGI; print $cgi->redirect("http://www.example.com/");

Спосіб другий

#!/usr/bin/perl -w use strict; print "Status: 301 Moved Permanently\n"; print "Location: http://www.example.com/\n\n"; exit;

ASP.NET

Спосіб перший

private void Page_Load(object sender, System.EventArgs e) ( Response.Status = "301 Moved Permanently"; Response.AddHeader("Location","http://www.example.com"); )

Спосіб другий (з версії 4.0)

RedirectPermanent("http://www.example.com");

ASP Ruby on Rails def do_something headers["Status"] = "301 Moved Permanently" redirect_to "http://www.example.com/" end ColdFusion Java (JSP) Веб-сервер Apache (.htaccess)

Спосіб перший (mod_alias, Redirect)

Redirect 301 / http://www.example.com

Спосіб другий (mod_alias, RedirectPermanent)

RedirectPermanent / http://www.example.com

Спосіб третій (mod_alias, Redirect permanent)

Redirect permanent / http://www.example.com

Спосіб четвертий (mod_alias, RedirectMatch)

RedirectMatch 301 ^(.*)$ http://www.example.com/

Спосіб п'ятий (mod_rewrite)

Options +FollowSymLinks RewriteEngine On RewriteBase / RewriteRule ^(.*)$ http://www.example.com/$1

Популярне в рубриці: