дома › СО › Како да поставите пренасочување на друг URL во PHP пред да се вчита страницата? Евролига мажи ucp php пренасочување

Како да поставите пренасочување на друг URL во PHP пред да се вчита страницата? Евролига мажи ucp php пренасочување

6,1 K

Да речеме дека сакате да ја прикажете страницата https://example.com/final.php на корисниците кои одат на страницата https://example.com/initial.php. Ова може да се направи со неколку PHP методи, JavaScript и HTML. Во оваа статија, ќе го покриеме секој од методите што можете да ги користите за пренасочување на PHP на друга страница.

Еве неколку променливи што ќе ги користиме:

Користење на функцијата PHP header() за пренасочување на URL

Ако сакате да додадете пренасочување од initial.php во final.php, можете да го поставите следниов код на веб-страницата initial.php. Испраќа ново заглавие на локација до прелистувачот:

Овде го користиме заглавието на функцијата PHP () за да го креираме пренасочувањето. Треба да го поставите овој код пред кој било HTML или текст. Во спротивно, ќе добиете грешка дека заглавието е веќе испратено. Можете исто така да користите баферирање на излезот за да ја спречите оваа грешка при испраќање заглавија. Следниот пример ја покажува оваа техника за пренасочување на PHP во акција:

За да се изврши пренасочување користејќи ја функцијата header(), функцијата ob_start() мора да биде првата функција во скриптата PHP. Ова ќе спречи да се појават грешки во заглавието.

Како дополнителна мерка, можете да додадете die() или exit() веднаш по пренасочувањето на заглавието, така што остатокот од кодот на веб-страницата не се извршува. Во некои случаи, роботите за пребарување или прелистувачите може да не обрнат внимание на ознаката во заглавието Локација. Кои се потенцијалните закани за безбедноста на локацијата:

За да биде јасно: die() или exit() немаат никаква врска со пренасочувањата. Тие се користат за да се спречи извршувањето на остатокот од кодот на веб-страницата.

Кога се пренасочувате на страница во PHP, се препорачува да користите апсолутни URL-адреси кога ја одредувате вредноста на заглавието на Локација. Но, релативните URL-адреси исто така ќе работат. Можете исто така да ја користите оваа одлика за пренасочување на корисниците на надворешни страници или веб-страници.

Изнесување код за пренасочување на JavaScript користејќи ја функцијата PHP echo().

Ова не е чисто PHP решение. Сепак, тоа е исто така ефикасно. Можете да ја користите функцијата PHP echo() за да излезете JavaScript код кој ќе се справи со пренасочувањето.

Ако го користите ова решение, нема да морате да користите баферирање на излезот. Ова исто така спречува да се појават грешки поврзани со испраќање заглавија.

Подолу се дадени неколку примери кои користат различни методи JavaScript за пренасочување од тековната страница на друга:

Единствениот недостаток на овој метод за пренасочување на друга PHP-страница е тоа што JavaScript работи на страната на клиентот. И вашите посетители можеби имаат оневозможено JavaScript.

Користење на HTML мета-тагови за пренасочување

Можете исто така да користите основен HTML за да го извршите пренасочувањето. Можеби изгледа непрофесионално, но функционира. И не треба да се грижите дали JavaScript е оневозможен во вашиот прелистувач или претходно сте испратиле грешка во заглавијата:

Можете исто така да ја користите последната линија од претходниот пример за автоматско освежување на страницата на секои „n“ секунди. На пример, следниот код автоматски ќе ја освежува страницата на секои 8 секунди.

Здраво пријатели. Денеска би сакал да разговарам за една многу хакерска, но секогаш релевантна тема - ова е 301 Redirect (Постојано пренасочување 301) - во заедницата за оптимизација, и без формалности, токму тоа се подразбира под зборот „пренасочување“. Технички, ова е одговор на серверот на барање до него; овој одговор има код од 301, што покажува дека адресата на барањето е трајно преместена. Како резултат на сите овие лукави махинации, треба да добиеме некоја нова конечна адреса.

Верувам дека не ви се потребни овие технички аспекти и затоа сакам да зборувам за применети работи - кога и во кои ситуации е подобро да се користи пренасочување, како и со кои команди можете да ги конфигурирате правилата за пренасочување итн. Ќе разгледаме и алатки и услуги со кои можете да ја проверите исправноста на пренасочувањата.

Бидејќи објавата се покажа многу долга, решив да направам табела со содржина за ваша погодност:

Кога ТРЕБА да направите пренасочување 301?

Прво, пренасочувањето се користи кога страницата (група страници или цел дел) ја сменила адресата - најчесто тоа се случува кога се менува структурата на страницата, се преименува главниот дел од URL-то или се менува принципот на формирање адреси (со други зборови, CNC). За жал, не сите размислуваат за ова кога менуваат нешто на страницата, а како резултат на тоа има многу дупликати, што доведува до губење на позиции или дури и наметнување санкции од пребарувачите. Во мојата работа многу често се среќавам со такви ситуации и чини многу нерви да се поправи се и да се неутрализираат последиците. Во мое лично име, можам да препорачам пред каква било работа за промена на типот на CNC или промена на структурата, да направите план за моменталната структура на страницата, сите негови делови и примери на крајни страници. Сето ова ќе треба да се провери откако ќе заврши работата, за кога ќе одиме на старата адреса да дојдеме до новата, а серверот да даде пренасочување со код 301 (а не 302).

Следната вообичаена употреба на пренасочувањата 301 е менување на адресата на страницата или лепење на огледалата заедно. Доколку одлучите да ја промените адресата на веб-страницата во врска со ребрендирањето на компанијата или регистрирате нов, поубав и пократок домен за да го означите на печатените промотивни производи, многу е важно кога пристапувате до адресата на стариот домен, корисникот завршува на истата страница (а не на почетна страница), но на нов домен. Што се однесува до промотивните страници, тие обично се состојат од една или две страници, линкови од кои водат до главниот сајт, или кога одите на промотивниот сајт, веднаш сте пренасочени на посебна страница на главната страница. Понекогаш, при креирање на веб-страница, неколку домени се регистрираат одеднаш, на пример, поради двосмислениот правопис на името на компанијата на латински. За да се осигура дека при интуитивно пишување адреса, корисникот ќе стигне на вистинското место и ќе се регистрираат неколку домени, многу е важно 301 пренасочувања да се појават од сите „помошни“ домени до една главна адреса. Под никакви околности истата веб-локација не смее да биде достапна до сите адреси.

И, исто така, за огледалата - може да се случи вашата страница да биде достапна на адресите http://www.site.ru, http://site.ru и https://site.ru (второто е ретко, но се случува) - ова е сите класични грешки што не треба да се прават, а во нивното решавање се вклучени 301 пренасочувања. Исто како и во случајот со различни адреси на веб-локации, треба да одлучите за главното огледало (со www или без www) и да поставите пренасочувања кон главното огледало. Се разбира, пребарувачите не се глупави и во такви ситуации често се снаоѓаат сами, а можете да им помогнете и со тоа што точни поставкиво панели за веб-администратори и во robots.txt (за Yandex, Директива за домаќин). Но, оптимизацијата е деликатна работа, и јас не би се потпирал на среќа, туку користам докажан метод!

Понекогаш се случува многу непријатна ситуација кога копија од страницата станува достапна не само кога ќе го внесете името на доменот во лентата за адреси, туку и IP адресата на серверот. Оваа ситуација е малку веројатно да се случи на заеднички хостинг, но ако имате посветен сервер, тоа лесно може да се случи. Ова може да биде причина за неправилна конфигурација на серверот - оневозможувањето на пристапот при пристап до IP адреса ќе помогне да се реши проблемот, но најдоброто решение овде е пренасочување 301 на ниво на веб-сервер (Apache или Nginx). Пред неколку месеци имав токму таква ситуација - имав посветен сервер на кој висеа некои од сајтовите, но за еден од сајтовите решив да земам друг посебен сервер. Ја префрлив страницата, сè работеше како часовник, а потоа еден ден наидов на клон на мојата страница во резултатите на Google - шок, паника - се покажа дека ова е IP адресата на мојот нов сервер и, се разбира, мојата страница живее на него, и кога ќе се контактира, серверот дава одговор 200 ОК, а Google целосно го индексирал. Немаше таков проблем на претходниот сервер; првично беше конфигурирано пренасочување 301 од IP до доменот наведен како главен за оваа IP адреса. Сега научив од горко искуство и секогаш проверувајте ги таквите работи - бидете свесни и вие, не повторувајте ги грешките. Проблемот беше решен со додавање пренасочување на главниот домен на конфигурациите на веб-серверот nginx; ќе покажам пример за кодот во практичниот дел од објавата подолу.

Ситуацијата е слична на претходната - кога копија од страницата е лоцирана и достапна преку домен за тестирање на услуги, на пример, како site.hosting.ru. Вакви случаи се случуваат и во мојата пракса, и, за разлика од претходниот случај, ова е типично за виртуелен хостинг. Зошто постои ова? На пример, сè уште не сте купиле домен или префрлате локација од еден хостинг на друг, но NS-серверите за доменот не се променети или сè уште не се ажурирани DNS записикај давателот. Во такви ситуации тоа го прават тест адреси, каде што можете да конфигурирате и инсталирате сè пред да ја пренасочите адресата на страницата во новиот хостинг. А некои хостери грешат со тоа што не го блокираат пристапот до такви технички адреси, па дури и не го забрануваат нивното индексирање. Ако ја имате оваа непријатна ситуација, тогаш треба да се обидете да регистрирате пренасочување 301 од техничката адреса до главната во датотеката .htaccess.

И, се разбира, 301 пренасочувања навистина сакаат да ги користат вистинските оптимизација за борба против разни дупликат страници. Зошто само вистинските оптимизација? Да, затоа што погрешни луѓе влегоа на веб-страницата на клиентот и, што е сосема веројатно, почнаа да купуваат врски дури и без да ја посетат страницата - за жал, ова не е невообичаено. Периодично ми се обраќаат клиенти кои сакаат да го проверат интегритетот на нивните изведувачи/вработени кои се одговорни за оптимизирање и промовирање на страницата, колку добро оди работата - - и досега никогаш не се случило да не најдов грешки или недостатоци на сајтовите. Затоа, имајте на ум - јас сум секогаш среќен да ви помогнам. Да се вратиме на дупликатите - верувам дека наместо да се блокираат дупликатите од индексирање, потребно е да се пренасочи на главната адреса, а тоа не е толку интересно. Се разбира, има многу случаи кога преземањата се принудени, а потоа не можете без канонизација, но ако имате можност да направите пренасочување, задолжително направете го тоа. Чести случаи на дупликати кои секогаш мора да се проверуваат: адреси со и без коса црта на крајот, адреси со параметри и етикети - ќе ви кажам како да го решите ова подолу.

Кога можете да направите пренасочување 301?

Не можете да пишувате многу во овој дел, но ќе се обидам. Навистина се надевам дека по читањето ќе ми додадете неколку идеи во коментарите.

Пренасочување 301 може да се користи како одговор на серверот наместо грешка 404 Не е најдено– со други зборови, корисникот кој следи погрешна врска или непостоечка страница нема да види порака која вели: „Извинете, оваа страница повеќе не постои“, туку ќе биде префрлен на друга постоечка страница. Ова е многу контроверзна точка меѓу експертите и затоа не го наметнувам моето мислење никому. Но, јас претпочитам да користам пренасочување наместо грешка 404, и има неколку опции за развој на настани... Видете, има 2 категории на грешки од 404: првата е класична, кога страницата е всушност избришана, второто е кога грешката се појавува поради искривени надворешни врски. Во првиот случај, веројатно не треба да направите пренасочување, туку оставете ја грешката 404 како што е. Но, во вториот случај, треба да се грижите за пренасочување на точната URL адреса, ако може да се врати од скршена врска или пренасочување на главната страница (или категорија).

Кога НЕ треба да се направи пренасочување 301

Неколку зборови за тоа кога пренасочувањето може да ви наштети и затоа не треба да се користи во следните ситуации.

Најважно е да не правите грешки, не треба да се мешате со пренасочувања доколку не сте 100% сигурни во тоа што го правите или се сомневате во нешто. Сфатете го ова како пријателски совет :)

Трајно пренасочување не треба да се користи за привремени решенија, тоа е очигледно од неговото име - за привремено преместување, користете 302 Moved Temporarily. Во овој случај, страниците нема да се залепат заедно и страницата со пренасочување може да се врати во секое време.

Ако има проблеми со вашиот домен, на пример, филтри, забрани итн., и одлучите да ја смените адресата на страницата (доменот), тогаш не треба да правите пренасочување 301 од стариот домен на новиот - како резултат , ќе ги „лепиш“ и сите проблеми на старите. Односно, на крајот ништо нема да се промени. Да, некое време имаше решение да се излезе од филтерот Google Penguin користејќи целосно пренасочување 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 ОК одговор. Ова дури ми го разнесе умот, но замислете што би помислил робот-пребарувач доколку влезе во таква рингишпил! Не само што три различни домени учествуваа во синџирот, туку и на страницата за грешка пишува дека тоа не е грешка и треба да се индексира.

Ако е можно, стремете се кон отсуство на пренасочувања во рамките на страницата - ако надворешните врски до страницата не можат да се поправат и пренасочувањето е неизбежно, тогаш внатрешните врски треба да се коригираат. Ова можеби нема да влијае на квалитетот на индексирањето и рангирањето, но не можете да бидете сигурни, и затоа е подобро да избегнете такви контроверзни ситуации. Прекрасен ќе ви помогне да ги следите внатрешните пренасочувања и генерално грешките во рамките на страницата.

Кога креирате правила за пренасочување во .htaccess, исклучете ги вистинските адреси на директориуми и датотеки на серверот и следете го изборот. Ситуацијата за еден сајт на кој еднаш бев ревидиран беше дека во борбата против дупликатните страници со категории со и без коса црта на крајот, вебмастерот малку претера и, напротив, само го влоши проблемот. Не само што правилата за препишување влијаеја на вистинските js скрипти и датотеките во стилот на css, поради што тие престануваат да работат правилно, туку и некои страници добија непотребна коса црта на крајот и се појавија дупликати. Пријатели, внимателно погрижете се правилата што ги креирате да важат само за групата адреси со кои работите, а ограничете ги сите други.

За да пребарувате проблематични страници и нивните адреси од кои треба да се ослободите, користете ги можностите на панелите за веб-администратори од Yandex и Google. За Yandex Webmaster: Изберете локација -> Индексирање на страницата -> Исклучени страници. За Google Webmaster: Изберете локација –> Оптимизација –> HTML оптимизација; И исто така: Изберете ја локацијата -> Конфигурација -> Параметри на URL-то.

Карактеристики на индексирање и реиндексирање на пренасочувања во Yandex и Google. Кога се борите со дупликати и проблематични адреси, се разбира, ќе чекате да се отстранат грешките од панелите на веб-администраторот; има некои функции овде. Со Google, сè е едноставно - поставувате пренасочувања, промените ќе се индексираат во рок од 2 недели, во исто време грешките ќе почнат да исчезнуваат од панелот на веб-администраторот, обично по еден месец исчезнуваат сите грешки. Со Yandex има суптилност, а ова е следново: по поставувањето на пренасочувањата, може да чекате засекогаш грешките да исчезнат од панелот. Еднаш чекав шест месеци додека не пишам за поддршка, каде што ме известија дека дополнително на пренасочувањето, потребно е дополнително да се затворат проблематичните страници во robots.txt и само тогаш тие ќе исчезнат од панелот на веб-администраторот.

Трајно пренасочување 301 преку .htaccess

Овој метод на инсталирање пренасочувања е најпопуларен и наједноставен. Иако, морам да признаам, сè не е толку едноставно како што изгледа, па затоа планирам да напишам посебен пост за htaccess. На позитивната страна овој методМоже да се забележи дека пренасочувањето се активира на ниво на сервер и пред да започне обработката на која било скрипта на страницата и не носи дополнително оптоварување.

Веројатно веќе имате датотека .htaccess на вашиот сервер (во коренот, каде што е главниот index.php). Ако оваа датотека не е видлива:

Проверете ги поставките на 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. Според тоа, во двата примери треба да го внесете името на вашиот домен наместо „сајт“.
Па, зошто овие опции се подобри? Многу едноставно, тие го проверуваат не само отсуството/присуството на www во името на доменот, туку го проверуваат и името на доменот за целосна усогласеност.
Жив пример: Сигурно сте наишле на фактот дека неочекувано страницата може да се индексира со адреса на услуга на хостингот (таква адреса се издава за да може да се пристапи на страницата пред да се поврзе вашиот вистински домен), некое огледало или дури и IP адреса! Значи, универзалните правила само ќе го потврдат отсуството/присуството на www, и не е важно до кој домен пристапува корисникот или роботот за пребарување.
Така, со користење на напредната опција, ќе бидете 146% сигурни дека вашиот сајт ќе биде достапен само и исклучиво користејќи го името на доменот што вие лично го наведовте и земајќи го предвид www. Ја користам само оваа опција и ви ја препорачувам!

301 пренасочува од http на https

Во светлината на масовната транзиција на страниците кон безбеден протокол, треба да знаете како да пренасочите од http на https. Патем, ако сè уште не сте одбрале SSL сертификат, треба да го прочитате мојот пост за .

Подолу ви нудим неколку опции за пренасочување 301 од протоколот http на https, кој може или не може да работи во зависност од конфигурацијата на вашиот сервер, но едно од правилата дефинитивно ќе ви одговара:

RewriteCond %(HTTPS) !=на 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) !на RewriteRule ^(.*)$ https://%(HTTP_HOST)%(REQUEST_URI)

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

RewriteCond %(HTTPS) исклучен RewriteCond %(HTTP:X-Forwarded-Proto) !https RewriteRule ^(.*)$ https://%(HTTP_HOST)%(REQUEST_URI)

Пренасочи од https во http протоколот (искрено, не знам зошто можеби ви треба ова):

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

Неодамна напишав многу детални инструкции. Ако планирате да се преселите од https на https, си должите да го прочитате!

Ќе донесам малку јасност на неразбирливиот лапач:

RewriteCond означува состојба која, доколку се совпадне, ќе го изврши RewriteRule. Со користење на регуларни изразисе наведени обрасци на жици.
Променливи на серверот:
- %(REQUEST_URI) - дел од URL-адресата без име на домен и GET параметри, на пример, за страницата што моментално ја читате: blog/post/4393,
- %(HTTP_HOST) - домаќин или Име на домен, на пример: веб-страница
- %(QUERY_STRING) - низа со множество GET параметри, односно делот од URL-то по прашалникот (и пред сидровата мрежа, ако има).
- %(REQUEST_FILENAME) — целосна патекаВ датотечен системсервер на датотека или скрипта што одговара на ова барање..php, но во датотечниот систем на серверот ова е страшната линија /var/www/site/data/www/site/index.php.
  Се случува кога правите пренасочување, да добиете неочекуван резултат, на пример, сакавте да ги отстраните параметрите post=17434801_4060 во адресата http://site.ru/page-name?post=17434801_4060 , наведените соодветни правила ( за нив ќе бидат напишани подолу), но на крајот ја добивме линијата http://site.ru/usr/local/www/site.ru/www/page-name - се ослободивме од параметрите, но добивме чудна адреса. Сето ова е затоа што не наведовте RewriteBase / директива на почетокот на датотеката по RewriteEngine On, која поставува специфична, основна URL адреса за трансформации во контекст на директориумот.
Металиките се користат за да се дефинираат групи на знаци или „ознаки“ во шема:
- ^ - знак за почеток на линијата,
- $ е ознака на крајот на линијата,
- ! - негирање,
- \ - коса црта за бегство, ви овозможува да го земете предвид металикот што го следи како редовен знак,
- . – точка, означува кој било знак, но само еден,
- () – групирање.
Модификаторите се поставуваат по редовните знаци, металиковите или нивните групи и ги прошируваат можностите за користење шаблони:
- ? — симболот се повторува 0 или 1 пат,
- * — Повторено од 0 до 65536 пати,
- + — Се повторува од 1 до 65536 пати.
Знамињата дефинираат дополнителни опции за ова правило и се наведени во квадратни заградиразделени со запирки:
- NC - (nocase) го оневозможува проверката на случајот.
- R - (пренасочување) го запира процесот на конверзија и го враќа резултатот во прелистувачот на клиентот како пренасочување кон оваа страница(302, ПРЕМЕСТЕН ПРИВРЕМЕНО). Со ова знаменце можете да наведете различен код за резултат, на пример R=301 ќе врати пренасочување со шифра 301 (ПРЕМЕСТЕН ТРАЈНО). Како што разбирате, тоа е токму она што ни треба.
- L - (последен) го запира процесот на конверзија и тековната врска се смета за конечна.

Најпопуларниот случај е пренасочување 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 - ова „добро“ е преземено од VKontakte, кога некој споделува врска до вашата страница на нивниот ѕид, во група или јавност, слична линија автоматски се додава, очигледно за следење на некои статистики .

За да се ослободите од оваа глупост еднаш засекогаш, треба да додадете во htaccess:

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

Како што можете да видите, нема разлика помеѓу овој и претходниот случај, дури и ако имате &post= или &sa= или што и да е во URL-то, решението е исто, само треба да ги замените очигледните делови од кодот. јасно, нели?

Ослободување од параметрите или ознаките во адресата

Прашањето беше поставено во коментарите и многупати на форумот, така што не може да се игнорира. Што да се прави со такви дупликати: http://site.ru/?abrakadabra или пореален случај http://site.ru?utm_source=twitterfeed&utm_medium=twitter

Овој случај е малку поинаков од следната точка, каде што ќе се ослободиме од параметрите за скриптата PHP, бидејќи овде не ја пренесуваме вообичаената адреса и параметри на скриптата. Еве го решението:

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

%(QUERY_STRING) е низа со множество променливи за PHP, делот од URL-то по прашалникот (и пред хашот за сидро, ако го има).

УРЛ на повици - http://site.ru/index.php?lang=ru

RewriteCond %(QUERY_STRING) ^lang=ru $
Бараната URL-адреса спаѓа под ова правило, нема други правила, така што RewriteRule ќе се изврши во линијата подолу.
RewriteRule ^(.*) \.php\?(.*) $1 $ \.php

УРЛ на изворот: 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://site/post/4358 и https://site/post/category/seo, што некако ја прекина логиката во структурата - на крајот на краиштата, блогот е само дел од страницата , но поради некоја причина објавите припаѓаат на страницата, а не на блогот, а категориите припаѓаат на објавите, што е исто така целосно нелогично..info/blog/category/seo - сега блогот е посебен дел од страницата, и постовите му припаѓаат, а категориите му припаѓаат на блогот, а не на објавите.

Од истиот пример е јасно дека е важно да се следи редоследот на правилата. Кога би ги заменил линиите, односно линијата RewriteRule ^post/(..info/blog/post/category/seo би дошла напред а не како што треба на https://site/blog/category/seo.

И последниот пример е анализа на вообичаена грешка со адресата од коренот на серверот

На пример, решивте да решите проблем кога страницата со категоријата е достапна на две адреси http://site.ru/razdel/podrazdel/index.php и http://site.ru/razdel/podrazdel/. Вториот URL е точен и главниот, а URL-то со index.php на крајот е целосен дупликат што треба да се отстрани.

За да се пренасочите од index.php во категорија, треба да го напишете следново правило:

RewriteEngine на RewriteBase /

301 пренасочува од страница на страница на нова адреса

Наједноставниот случај е кога треба да пренасочите една страница на друга адреса. Ако треба да направите пренасочување за неколку страници, ќе треба да напишете неколку правила, но во овој случај подобро е да ги користите шаблоните опишани погоре. Постојат неколку целосно идентични опции за синтакса:

Пренасочи 301 /page-name1.html http://site.ru/page-name2.html Пренасочи трајно /page-name1.html http://site.ru/page-name2.html ПренасочиПостојано /page-name1.html http http://site.ru/page-name2.html

Изберете една од трите, но лично ја претпочитам првата опција - таа е пократка, поедноставна и поразбирлива. Патем, овде site.ru не мора да биде истиот домен, туку кој било друг.

Да завршиме со .htaccess и да преминеме на PHP.

Трајно пренасочување 301 користејќи PHP

Јас обично користам PHP пренасочување кога има потешкотии со .htaccess или излегува дека функцијата PHP се покажува пологична и поразбирлива.

Синтаксата на пренасочување 301 во php изгледа вака:

заглавие (); заглавие ("Локација: http://site.ru"); die ("Пренасочување");

заглавие ("HTTP/1.1 301 трајно преместен"); заглавие ("Локација: http://site.ru"); die ("Пренасочување");

Овие линии му кажуваат на прелистувачот на клиентот дека е неопходно трајно да се пренасочи од некоја барана страница на адресата http://site.ru. Во овој случај, http://site.ru може да биде не само адреса на главната страница на тековната страница, туку може да биде и која било друга страница. Ако нешто тргна наопаку и се појави грешка, тогаш во прозорецот на прелистувачот ќе го видиме натписот „Пренасочи“.

За да биде појасно, еве неколку примери на функции што ги напишав за мојот блог сајт, обидувајќи се да решам одредени проблеми.

Функција која ви овозможува да отстраните одреден дел од URL-то

if (strpos($_SERVER["REQUEST_URI" ], "http://site") !== неточно) ($real_page_url = "http://site" .str_replace ("/http://site" , "" , $_SERVER["REQUEST_URI" ]); заглавие ("HTTP/1.1 301 преместено трајно"); заглавие ("Локација: $real_page_url"); die("Пренасочување"); )

if (strpos($_SERVER["REQUEST_URI"], "http://site") !== неточно) ($real_page_url = "http://site"..1 301 Преместен трајно"); header("Локација: $real_page_url"); die ("Пренасочување"); )

Еднаш имав проблем што се појавија куп 404 грешки во панелот за веб-администратори, адресите на овие страници беа како https://alaev..е. Од некаде во адресата се појави дупликат адреса на страницата. И тогаш напишав функција која проверува дали URI (забелешка, не URL-то, туку URI) го содржи записот „http://site“, и ако го содржи, го отсекуваме овој дел од адресата и го пишуваме резултатот до променливата $real_page_url, а потоа правиме пренасочување 301 до точната адреса од променливата.

Функција која ја отстранува заостанувачката коса црта од URL-то

if (($_SERVER["REQUEST_URI" ], - 1 , 1 ) == "/" ) ( $requested_url = rtrim($requested_url, "/"); заглавие ("HTTP/1.0 301 е преместен трајно"); заглавие ( "Локација: $requested_url"); die("Пренасочување"); )

if (($_SERVER["REQUEST_URI"], - 1, 1) == "/") ( $requested_url = rtrim($requested_url, "/"); header ("HTTP/1.0 301 Travly Transmeded"); header( "Локација: $requested_url"); die ("Пренасочување"); )

Овде е наједноставната функција која бара да види дали бараната адреса на страницата има коса црта на крајот, а ако ја има, коса црта се отсекува и се случува пренасочување 301 на адресата без коса црта.

Има многу повеќе опции кои ви дозволуваат да издадете команда за пренасочување на различни програмски јазици, како ASP, Ruby on Rail итн., но јас не сум запознаен со овие јазици, затоа нема да бидам паметен и да ве измамам овде . Пренасочувањата се исто така можни со користење на мета-ознаката за мета освежување, како и пренасочувања на Javascript - но ова е судбината на нечесните развивачи на вратата, а пребарувачите не ги разбираат овие пренасочувања; тие добиваат одговор од 200 ОК од серверот. Значи, ние не ги разгледуваме овие опции.

Трајно пренасочување 301 за nginx сервер

Се сеќавате дека напишав за огледало на мојата страница, достапно преку IP? Како резултат на тоа, проблемот беше решен со пренасочување напишано во датотеката за конфигурација на серверот, обично лоцирана овде /etc/nginx/nginx.conf. Таму беа напишани следните редови:

сервер (слушајте 1.2.34.123:80 стандардно; име_сервер _; препишете ^/(.*)$ http://site.ru/$1 постојан; )

Овде пишува дека ако се пристапи до IP адреса преку портата 80, тогаш е неопходно да се направи трајно пренасочување на site.ru.

Сепак, техничката поддршка не ми препорача да го направам ова со зборовите: „Поправилно би било да го конфигурирате HTTP серверот на таков начин што тој едноставно ја затвора врската ако се пристапи на адреса што не е експлицитно наведена во Конфигурација на серверот HTTP, ова е најсигурната, едноставна, безбедна и најмалку барана опција за ресурсите на серверот. По некое време, страниците до кои повеќе не се достапни, најверојатно ќе бидат исфрлени од индексот на пребарувачот“.

Следниот совет беше овој: „Кога треба едноставно да ја затворите врската наместо да пренасочувате, тогаш наместо линијата, наведете „преработи ^/(.*)$ http://site.ru/$1 трајно;“ таква линија "враќање 444;". Потоа стартувајте: "invoke-rc.d nginx reload"".

Можеби ова ќе помогне некому.

Примери на пренасочувања во најчестите случаи

Пренасочи за доменот www.site.ru на site.ru

сервер (слушајте 80; server_name site.ru; препишете ^ http://www.site.ru$request_uri? трајно; )

Пренасочи од адресата http://site.ru/index.php на http://site.ru/

локација = /index.php ( ако ($request_uri = /index.php) ( преработи ^ http://$host? permanent;#301 redirect ) fastcgi_pass unix:/tmp/fastcgi.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; вклучи fastcgi_params;)

Така нешто. Не сум добар во поставувањето конфигурации за nginx; секогаш се задоволувам со поставките на Apache, па ако имате какви било прашања за nginx, веројатно нема да можам да ви помогнам...

Како да ги проверите заглавијата на HTTP и статусите на одговор на серверот

Во овој дел сакав да опишам различни услуги и приклучоци за проверка на одговорот на серверот, но разбирам дека оваа објава е веќе толку голема во обем што ќе морам да се ограничам на само врски до екстензии за Прелистувачи на Chromeи Firefox.

HttpFox додаток за Firefox

HttpFox (еве линк до додатокот) е мојата омилена алатка за следење http заглавието. HttpFox го прикажува напредокот на вчитувањето на страницата линија по линија, што ви овозможува да ги следите, на пример, синџирите на пренасочувања и, воопшто, редоследот и брзината на вчитување на страницата. Ако користите Mozilla, дефинитивно го препорачувам.

Екстензија на HTTP заглавија за Chrome

Јас самиот не ја користам екстензијата HTTP Headers (еве врска до неа), но Интернетот ме советуваше да обрнам внимание на тоа. Ако имате подобри опции, ве молиме објавете ги во коментарите.

Ова го завршува мојот страшно долг и досаден пост, пријатели.
Ви благодариме што прочитавте до крај, се надевам дека ви беше навистина корисно.

Конфигурациската датотека .htaccess е конфигурација за веб-серверите на Apache. Повеќето хостинг сајтови работат преку овој сервер, така што секоја локација ја има оваа датотека. Веб-администраторите можат делумно да го контролираат неговото работење со правење свои промени. Во оваа статија ќе ги разгледаме директивите и правилата што можат да се променат во работата на серверот.

Најважната датотека .htaccess се наоѓа во коренот на страницата:

Неговите дејства се однесуваат на тековниот директориум и сите поддиректориуми. Оние. Сопствениците на страниците имаат можност да влијаат само на работата на нивниот проект без да се мешаат во работата на целиот сервер. Ако оваа датотека недостасува, може да се креира со која било бележница. Главната работа е дека името на датотеката треба да биде ".htaccess" - без формати .txt, .doc итн.

301 пренасочувања најчесто се конфигурираат на ниво на сервер преку датотеката .htaccess, што во голема мера го забрзува процесот на префрлување на нова страница, бидејќи нема потреба да се вчитува средна страница. Исто така, одредува која датотека ја обработува грешката 404.

Подолу ќе ги разгледаме сите вообичаени опции за пренасочување преку .htaccess и прво ќе се запознаеме со опциите и правилата.

За да можете да работите со пренасочувања, треба да го овозможите модулот ReWriteEngine. За да го направите ова, треба да напишете две линии код (по можност на самиот врв на датотеката .htaccess):

Опции +FollowSymLinks RewriteEngine On

Ставете ги овие редови на самиот врв на вашата датотека .htaccess за да можете да работите со модулските директиви на mod_write.

Исто така, модулите mod_alias мора да бидат овозможени на хостингот (за поддршка на Redirect, RedirectPermanent и RedirectMatch).

1. Правила за пренасочување, RewriteRule и RewriteCond 1.1. Директива за пренасочување

Синтакса за пренасочување:

Пренасочи /од http://to_full_address

Пренасочување поставува директно пренасочување од една страница на друга.

Кодот за пренасочување е запишан во статус. Е изборен параметар. Најчесто пишуваат 301, што сигнализира трајна промена на адресата на страницата.

Важно е страницата „од“ да биде напишана во формат без означување на целосната адреса на страницата, но со означување на целосната релативна URL-адреса која започнува со коса црта „/“ (т.е. од коренот на страницата). Страницата каде оди пренасочувањето треба да биде целосно напишана, т.е. апсолутна адреса на страницата URL (т.е. со име на домен и http или https протокол).

На пример

Пренасочи 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 [шифри]

Кога ќе се појави надворешно пренасочување, URL-то во линијата на прелистувачот се менува - " "
Со внатрешно - не ја менува URL-адресата во линијата на прелистувачот - " " или "[L] "

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

Директивата RewriteCond ги дефинира условите под кои се извршуваат правилата во RewriteRule.

RewriteCond Comparison_String Condition

На пример, овие термини може да бидат прелистувачот на корисникот, IP адресата, насловот итн.

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

Директивата RedirectMatch е слична на Redirect, единствената разлика е во тоа што ви овозможува да пишувате регуларни изрази.

RedirectMatch From Where To 2. Примери на 301 пренасочувања во .htaccess

Веќе разгледавме многу примери со пренасочување .htaccess во написите:

Промена на адресата на веб-страницата - пренасочување од стариот домен на новиот

Овде ќе додадеме опции за пренасочувања кои сè уште не постоеле.

2.1. Пренасочи од една страница на друга

Пренасочи од site.ru/cat/oldpage на site.ru/newpage.html

RewriteRule ^cat/oldpage.* /newpage.html

Или втората опција:

Пренасочи 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=страница RewriteCond %(QUERY_STRING) id=(\d+) RewriteRule .* /страница/%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 за сите:

негираат од сите 3.3. Дозволете пристап од една IP адреса

Пристапот ќе биде дозволен само од една IP адреса 172.111.222.55

нарачај одбие,дозволи одбие од сите дозволи од 172.111.222.55 3.4. Одбијте пристап од различни IP адреси

Одбијте пристап до страницата од неколку IP адреси 172.112.222.55, 172.113.222.55, 172.114.*.*

нарачај отфрли,дозволи одбие од сите негира од 172.112.222.55 одбие од 172.113.222.55 одбие 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 ^( [^Ш]*)Ш(.*)$1в$2Препишувањеправило ^([^X]*)X(.*)$1x$2Препишувањеправило ^([^Y]*)Y(.*)$1год $2 RewriteRule ^([^Z]*)Z(.*)$1z$2 RewriteRule - [N] RewriteCond %(ENV:HASCAPS) TRUE RewriteRule ^/?(.*) /$1

Доволно важна точкапри поставување на страницата. Неправилно конфигурирано пренасочување може многу да ги оштети резултатите од пребарувањето на страницата. Најчестите ситуации во кои треба да користите Трајно пренасочување 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. Во овој случај, страниците нема да се спојат и страницата со пренасочување секогаш може да се врати.

Трајно пренасочување 301 за apache (.htaccess)

Треба да ги вметнете правилата веднаш по редовите:

RewriteEngine On RewriteBase / # за скратување на целата патека, од коренот на серверот до коренот на страницата

самите правила се специфицирани со користење на регуларни изрази; потсети се на синтаксата:

Металикови, за одредување групи на знаци или „етикети“ во шема:
- ^ - знак за почеток на линијата,
- $ - ознака за крај на линијата,
- ! - негирање,
- \ - коса црта за бегство, ви овозможува да го земете предвид металикот што го следи како редовен знак,
- . - точка, означува кој било знак, но само еден,
- () - групирање.
Модификаторите се ставаат по редовните знаци, металиковите или нивните групи:
- ? - симболот се повторува 0 или 1 пат,
- * - се повторува од 0 до 65536 пати,
- + - се повторува од 1 до 65536 пати.
Знамињата дефинираат дополнителни опции за ова правило:
- NC - (nocase) го оневозможува проверката на случајот.
- R - (пренасочување) го запира процесот на конверзија и го враќа резултатот во прелистувачот на клиентот како пренасочување на оваа страница (302, ПРЕМЕСТЕН ПРИВРЕМЕНО).
  Со ова знаменце можете да наведете различен код за резултат, на пример R=301 ќе врати пренасочување со шифра 301 (ПРЕМЕСТЕН ТРАЈНО). Како што разбирате, тоа е токму она што ни треба.
- L - (последен) го запира процесот на конверзија и тековната врска се смета за конечна.

Размислете за најчестите ситуации:

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 Трајно пренасочување 301 во PHP

За да го информирате прелистувачот дека страницата што ја побарала треба да се пренасочи на адресата http://site.ru, извршете ги следните команди:

Заглавие („HTTP/1.1 301 трајно преместен“); заглавие ("Локација: http://site.ru"); exit();

Трајно пренасочување 301 за nginx

Правилата за пренасочување се опишани во делот за сервер.

Пренасочи од www.site.ru на серверот site.ru (слушајте 80; име на серверот www.site.ru; препишете ^ http://site.ru$request_uri? трајно; )

или општо правилоза сите сајтови:

Сервер (име на серверот ~^(?! www\.); препишете ^ http://www.$host$request_uri постојан; )

Пренасочи за од site.ru на серверот www.site.ru ( слушај 80; server_name site.ru; препиши ^ http://www.site.ru$request_uri? постојан; ) Пренасочи од index.php на локацијата на главната страница = / 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; вклучи fastcgi_params;)

Код за статус на HTTP со статус 301 Преместен трајно покажува дека бараниот документ е трајно преместен во новиот URI наведен во полето Локација на заглавието.

За што е?

Најпрво, при промена на името на доменот на страницата, неопходно е да се известат пребарувачите за промената на адресата на страницата. Второ, да се спои името на страницата со и без www. Трето, брзо да го пренесете рангирањето на страницата на нова локација.

PHP

Метод еден

Метод два

Перл

Метод еден

$cgi = нов CGI; печати $cgi->пренасочување ("http://www.example.com/");

Метод два

#!/usr/bin/perl -w користете строго; отпечати „Статус: 301 трајно преместен\n“; отпечати „Локација: http://www.example.com/\n\n“; излез;

ASP.NET

Метод еден

приватна празнина Page_Load(испраќач на објект, System.EventArgs e) ( Response.Status = "301 е преместена трајно"; Response.AddHeader("Локација","http://www.example.com"); )

Втор метод (од верзија 4.0)

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

ASP Ruby on Rails def do_something headers["Статус"] = "301 преместени трајно" redirect_to "http://www.example.com/" крај ColdFusion Java (JSP) Apache Web Server (.htaccess)

Првиот метод (mod_alias, пренасочување)

Пренасочи 301 / http://www.example.com

Втор метод (mod_alias, RedirectPermanent)

ПренасочувањеПостојано / http://www.example.com

Трет метод (mod_alias, трајно пренасочување)

Пренасочи постојан / http://www.example.com

Метод четири (mod_alias, RedirectMatch)

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

Метод пет (mod_rewrite)

Опции +FollowSymLinks RewriteEngine On RewriteBase / RewriteRule ^(.*)$ http://www.example.com/$1

Популарни во категоријата: