- Визначення 301 Redirect Функція веб-сервера, який перенаправляє відвідувача з поточної сторінки або...
- 301 Приклади коду перенаправлення
- Перенаправлення метаобновлення (не найкращий вибір)
- Приклад метаобновлення (не найкращий вибір)
- Переадресація JavaScript (взагалі не рекомендується)
- Приклад переспрямування Javascript (не рекомендується)
- Перенаправлення на стороні сервера
- Приклад перенаправлення PHP 301
- Приклад перенаправлення ASP 301 (VBScript)
- Приклад переадресації ASP 301 (JScript)
- Приклад перенаправлення ASP .NET 301 (C #)
- Приклад переадресації Cold Fusion 301 (CFM)
- Приклад переадресації JSP / JAVA 301
- CGI / Perl 301 Прикладний код переадресації
- Обробка статичних сторінок, як якщо б вони були динамічними
- Обробка .html сторінок, як якщо б вони були .php в Apache
- Обробка .htm сторінок, як якщо б вони були .asp в IIS
- Висновок
- Головна стаття
Визначення 301 Redirect
Функція веб-сервера, який перенаправляє відвідувача з поточної сторінки або сайту на іншу сторінку або сайт, повертаючи код відповіді, який говорить про те, що оригінальну сторінку чи сайт було перенесено на нове місце. Пошукові системи, як ця інформація, легко передадуть популярність посилання (і PageRank) на новий сайт швидко та з невеликою кількістю питань. Вони також не схильні викликати проблеми з фільтрами дублювання. SEO, як 301 перенаправлення, і вони, як правило, кращий спосіб мати справу з кількома доменами, вказуючи на один сайт. 302 Перенаправлення Функція веб-сервера, який перенаправляє відвідувача з поточної сторінки або сайту на іншу сторінку або сайт, повертаючи код відповіді, який говорить, що оригінальна сторінка або сайт тимчасово переміщено на нове місце. Пошукові системи часто інтерпретують їх як парк, і приймуть свій час, з'ясовуючи, як обробляти цю установку. Намагайтеся уникати перенаправлення 302 на ваш сайт, якщо це можливо (якщо це дійсно лише тимчасове перенаправлення), і ніколи не використовуйте їх як певну форму відстеження кліків для ваших вихідних посилань, оскільки вони можуть призвести до "викрадення веб-сайту" під деякими обставин.
MetaTags
HTML-теги, які записані в головний розділ HTML-сторінки і передають різні види інформації, але насправді не відображаються на сторінці як текст. Наприклад, назва, опис та ключові слова для сторінки. The metatag що має значення для цього документа мета-оновлення . McAnerin Networks пропонує a безкоштовний генератор метатагів тут .
Сценарій на стороні клієнта (стрибок вниз)
Сценарій на стороні клієнта - це програма, яка обробляється на клієнті (зазвичай це веб-браузер) після того, як інформація надіслана користувачеві. На відміну від багатьох сучасних веб-браузерів, павуки пошукових систем не запускають скрипти на стороні клієнта - тому вони не можуть бути використані для впливу на пошукові системи, крім пропусків (тобто скриптів, які навмисно "залишають павука", розраховуючи на те, що браузери зазвичай виконують скриптів). Приклад сценарію на стороні клієнта: Сценарій Java Сценарій на стороні сервера (перейти вниз) Скрипт на стороні сервера - це програма, яка обробляється на сервері , перш ніж інформація досягне комп'ютера переглядача. Порівняно з клієнтським скриптом, який обробляється на комп'ютері клієнта. Приклади мов, які зазвичай використовуються як сценарії на стороні сервера: PHP , JSP , ASP , ASP.NET , PERL і Cold Fusion .
PHP
Попередній процесор PHP (Hypertext Preprocessor, PHP) - це відкритий вихідний мова програмування на стороні сервера, широко використовуваний для веб-скриптів і для обробки даних, переданих через CGI. PHP може бути написаний у вигляді скриптів, які знаходяться на сервері, і може створювати вихід HTML, який завантажується у веб-браузер. Крім того, PHP може бути вбудований у HTML-сторінки, які потім зберігаються з розширенням .php. Потім PHP-розділи сторінки розбираються за допомогою движка PHP на сервері, а PHP-код видаляється до завантаження сторінки в веб-браузер. Більше інформації про PHP .
Perl
Практична мова видобування та звітності (PERL) - це відкритий вихідний мова програмування на стороні сервера, широко використовуваний для веб-скриптів і для обробки даних, переданих через CGI. Сценарії Perl не вбудовуються в HTML-сторінки і не завантажуються в веб-браузер, а знаходяться на сервері. Вони виконуються, починаючи з команд HTML-сторінок або інших скриптів, і можуть створювати HTML-вивід, який завантажується в веб-браузер. Більше інформації про Perl
JSP
Сторінка Java Server Page (JSP) - це технологія керування вмістом або зовнішнім виглядом веб-сторінок за допомогою сервлету java, невеликих програм, вказаних на веб-сторінці, і запущених на веб-сервері для зміни веб-сторінки, перш ніж вона буде надіслана. користувачеві, який його запросив. Sun Microsystems, розробник Java, також посилається на технологію JSP як інтерфейс прикладних програм Servlet (API). JSP можна порівняти з технологією Microsoft Active Server Page (ASP). Більше інформації про JSP ASP Active Server Pages. Специфікація, яка дозволяє веб-сторінкам динамічно створюватися за допомогою HTML, скриптів і компонентів багаторазового використання ActiveX. VBScript і JScript є найпоширенішими мовами сценаріїв, які використовуються для ASP . ASP.NET Набір технологій веб-розробки, що продаються Microsoft. Програмісти можуть використовувати його для створення динамічних веб-сайтів, веб-додатків і веб-служб XML. Вона є частиною платформи Microsoft .NET і є наступником активних серверних сторінок Microsoft ( ASP ) технології. Хоча ви можете використовувати VBScript і JScript з ASP.NET, стандарт є C # ColdFusion ColdFusion - це мова програмування на основі тегів, яка використовується переважно для написання веб-додатків. Мова був створений JJ Allaire і його брат Джеремі Аллер, але продукт в даний час належить Macromedia (буде незабаром придбаний Adobe). Додаткова інформація про ColdFusion. JavaScript JavaScript - це скриптова мова - система програмних кодів, створена Netscape, яка може бути вбудована в HTML веб-сторінки для додавання функціональних можливостей. JavaScript не слід плутати з мовою програмування Java. Додаткова інформація про Javascript. C # (“C Sharp”) Об'єктно-орієнтована мова програмування, розроблена компанією Microsoft як частина їхньої ініціативи .NET. Microsoft на основі C # на C ++ і Java. C # був розроблений як мова, яка забезпечить баланс C ++ з швидким розвитком, Visual Basic, Delphi і Java. Додаткова інформація про C #
Детальна інформація
Огляд
Проблема з використанням скриптів для перенаправлення полягає в тому, що пошукові системи не виконують їх. Це означає, що для того, щоб вони працювали, їх потрібно виконувати на сервері, коли викликається сторінка, але до того, як пошукова система отримає її. Існує лише одне виключення з цього приводу, і я одразу в нього ввійду.
Загалом, оскільки виконання сценарію та перенаправлення відбуваються до того, як сторінка перейде до павука, ви можете використовувати будь-яку бажану мову сценаріїв, якщо сервер виконує його, а сама мова здатна перенаправляти та реагувати на статус код 301 або 302.
Загалом, переадресація, яка не вказує 301, трактується як 302, тому для того, щоб зробити правильний 301, потрібно мати можливість вказувати код стану мовою за вашим вибором. Є винятки з цього, але це загальна поведінка.
301 Приклади коду перенаправлення
Переадресація на стороні клієнта
Існує два поширених типи переадресацій на стороні клієнта - мета-оновлення і JavaScript, і тільки мета-оновлення фактично працює для перенаправлення пошукової системи. Однак, як ви побачите, це не дуже добре. Загалом, переадресація на стороні клієнта є поганою ідеєю і її слід уникати, якщо це можливо.
Перенаправлення метаобновлення (не найкращий вибір)
Почнемо з поганого прикладу. Це також дуже, дуже поширений приклад, тому потрібно знати про це. Існує тег HTML, який називається мета-оновленням, який може виконувати перенаправлення, які пошукові системи можуть виявляти та реагувати. Це єдине виключення з ідеї, що скрипти та теги на стороні клієнта не впливають на пошукові системи. Вони зазвичай дивляться на цю.
Питання в тому, як вони з нею дивляться, як вони це роблять? Це дуже важлива проблема. По-перше, веб-майстри використовують це протягом багатьох років у добросовісному розумінні, і якщо пошукова система не зрозуміє, то результатом буде багато дуже хороших сайтів, які не обробляються належним чином.
Таким чином, пошуковій системі необхідно займатися цим питанням. Більшість пошукових систем припускають, що оновлення, яке відбувається швидше, ніж потрібно, щоб завантаження сторінки в середньому було повним, має на меті діяти як перенаправлення сервера, тоді як, якщо оновлення встановлено досить високо, щоб користувач міг його побачити і оновити свої закладки, намір полягав у тому, щоб користувач виправляв свої закладки, а не щоб сервер виправляв їх. У цей момент оновлення є більш ввічливою, ніж інструкція. Тому пошукові системи зазвичай турбуються про швидке оновлення.
Тепер вони, здається, розглядають швидке мета-оновлення як 302, і життя набагато краще для всіх учасників. Я не знаю жодних офіційних заяв про те, як вони обробляють мета-оновлення, тому ця інформація походить від уст в уста і тестування. Оскільки вона обробляється як 302, вона не є кращим типом переадресації для цілей SEO.
Yahoo, до їхнього величезного кредиту, фактично окреслив, як вони вирішують це. Якщо мета-перенаправлення встановлено на 0 секунд, то він буде розглядатися як перенаправлення 301. Якщо вона більше 1 секунди, вона розглядається як перенаправлення 302. Чесно кажучи, я вважаю, що це прекрасний спосіб впоратися з цим.
Програма MSN Search говорить: "Додавання тега мета-перенаправлення до заголовка сторінки не видаляє вихідну сторінку з індексу MSN Search; однак, це перенаправлятиме відвідувачів на ваш новий сайт. Я читав це, маючи на увазі, що вони розглядають його як перенаправлення 302. Оскільки 302 вважається тимчасовим, оригінальна сторінка зберігається в індексі.
ASK очевидно розглядає мета-оновлення 0 як 302, де він отримує цільову сторінку замість вихідної сторінки, але зберігає посилання на початкову сторінку, поки не з'ясує, що відбувається.
Таким чином, в основному, всі 4 основні пошукові системи обробляють мета-оновлення інакше - я настійно рекомендую НЕ використовувати його, якщо у вас є вибір. Якщо вам треба, вам краще припустити, що мета-оновлення 0 буде працювати найбільш послідовно, і, ймовірно, буде розглядатися як 302 всіма, крім Yahoo, які будуть розглядати як 301.
Це суперечить «звичайній мудрості», що мета-оновлення призведе до заборони або покарання. Неправда. Це призведе до 302 - який може виглядати як пенальті за деяких обставин. 302 можуть бути поганими новинами, оскільки цільовий вміст розглядається як приналежний до вихідної сторінки, що може призвести до викрадення, виникнення дублювання та багатьох інших проблем.
Я не рекомендую його, але він може працювати як метод останньої інстанції. Застереження за емпер .
Приклад метаобновлення (не найкращий вибір)
<META HTTP-EQUIV = Оновити ЗМІСТ = ”0; URL = http: //www.newdomain.com ”>
Переадресація JavaScript (взагалі не рекомендується)
JavaScript є другим типом перенаправлення загальної сторони клієнта. На відміну від тега мета-оновлення, пошукова система ігноруватиме перенаправлення JavaScript і залишатиметься на сторінці.
Деякі люди вирішили, що вони можуть використовувати цю поведінку для спаму в пошукових системах, шляхом заповнення ключових слів на сторінці, а потім за допомогою швидкого перенаправлення JavaScript, щоб перемістити людей на наступну сторінку, дозволяючи павуку залишатися та індексувати спам-сторінку.
Google зрозумів, як виявити цю тактику влітку 2004 року, і в результаті багато веб-сайтів втратили рейтинг, що призвело до принаймні однієї сумно відомої фірми SEO, яка почала проти них позов, а також змусив їх виглядати погано.
Коротше кажучи, перенаправлення JavaScript не працюють у пошукових системах, і їх використання може бути заборонено у пошуковій системі, залежно від обставин.
Ніколи не використовуйте переадресацію JavaScript на сторінці чи домену, який ви бажаєте класифікувати за допомогою пошукових систем.
Єдина причина, чому я включив їх на цю сторінку, - це попередження. Іноді ви можете використовувати їх на сторінках, які не є доступними для пошукових систем, наприклад, певні системи кошика для покупок і так далі, але в цілому краще уникати їх.
Приклад переспрямування Javascript (не рекомендується)
<script type = ”text / javascript”>
<! -
window.location = “http://www.newdomain.com/”
// ->
</script>
або
<body onLoad = "setTimeout (location.href = 'http: // xxx', '0')">
Я не можу стверджувати, що цей метод НЕ рекомендується.
Вона має чистий ефект показування людям і пошуковим системам 2 різних речей - не хороший початок довгострокових результатів. В основному, це ризиковано.
Перенаправлення на стороні сервера
Сервери не автоматично переходять на кожну веб-сторінку, яку вони обслуговують, і шукають сценарії для запуску. Вони дивляться тільки всередині файлів, які, на їхню думку, можуть мати в них сценарії на стороні сервера. Це заощаджує накладні витрати на сервер і є більш ефективним. Традиційно файли, що закінчуються на .htm і .html, вважаються статичними, і тому більшість серверів не намагатиметься їх виконати. Ви можете змусити їх бути визнаними як динамічні, але взагалі це не робиться.
Коли динамічна сторінка викликається з сервера, сервер спочатку переглядає сторінку, перш ніж відправити його користувачеві. Потім він виконає всі сценарії, які він розпізнає як скрипти, які він повинен виконати, а потім відправляє результати користувачеві. Це означає, що динамічна сторінка може виглядати на сервері дуже різним, ніж коли вона нарешті досягає користувача. У деяких системах CMS існує лише одна сторінка, і вміст цієї сторінки контролюється за допомогою змінних, надісланих до неї. Це одна з причин, чому пошукові системи будуть не довіряти сторінкам з великою кількістю змінних.
Щоб виконати скрипт на стороні сервера, сервер повинен бути налаштований на обробку типу сторінки, на якій він знаходиться, і сценарій повинен бути присутнім на сторінці (зазвичай в заголовку або на самому верху сторінки)
Приклад перенаправлення PHP 301
header (“HTTP / 1.1 301 Переміщено постійно”);
заголовок ("Місцезнаходження: http://www.newdomain.com/newdir/newpage.htm");
Вхід();
Приклад перенаправлення ASP 301 (VBScript)
<% @ Language = VBScript%>
<%
Response.Status = ”301 постійно переміщено”
Response.AddHeader “Location”, “http://www.newdomain.com/newdir/newpage.asp”
response.end
%>
Приклад переадресації ASP 301 (JScript)
function PermanentRedirect (strDestinationUri) {
Response.Clear ();
Response.Status = 301;
Response.AddHeader ("Розташування", strDestinationUri);
Response.Flush ();
Response.End ();
}
Примітка:
"StrDestinationUri" має бути абсолютним URI для максимальної сумісності з клієнтом. Функція припускає, що "Response.Buffer = true;" була встановлена в певний момент до виклику функції і буде помилкою, якщо немає (це типова конфігурація для IIS5 і вище).
Приклад перенаправлення ASP .NET 301 (C #)
<script runat = ”server”>
private void Page_Load (відправник об'єкта, System.EventArgs e)
{
Response.Status = “301 Постійно переміщено”;
Response.AddHeader ("Розташування", "http://www.new-url.com/");
}
</script>
Приклад переадресації Cold Fusion 301 (CFM)
Просто додайте цей код на сторінку ColdFusion:
<.cfheader statuscode = ”301 ″ statustext =” Перенесено назавжди ”>
<.cfheader name = "Location" value = "http://www.new-url.com/">
Приклад переадресації JSP / JAVA 301
Просто додайте цей код до сторінки чи сценарію:
<%
response.setStatus (301);
response.setHeader (“Розташування”, “http://www.new-url.com/”);
response.setHeader (“Підключення”, “закрити”);
%>
CGI / Perl 301 Прикладний код переадресації
Perl відрізняється від наведених вище прикладів, оскільки він взагалі не переходить на сторінку. Насправді це скрипт, який називається (як правило, з cgi-bin). "Сторінки" зазвичай виглядають як "pages.cgi" і називаються, як якщо б вони були скриптами, а не веб-сторінками.
#! / usr / bin / perl
використовувати cgi;
my $ q = cgi-> new ();
print $ q-> redirect (
-location => 'http://www.newsite.com/newpage.cgi',
-статус => 301,
);
Обробка статичних сторінок, як якщо б вони були динамічними
Іноді ви захочете зробити перенаправлення на сторінках, які є стандартними статичними веб-сторінками (тобто htm або html). Це особливо часто трапляється, коли ви намагаєтеся переключитися зі старих статичних систем на новіші динамічні. Проблема полягає в тому, що, оскільки пошукові системи не виконують сценарії, сценарії перенаправлення не працюватимуть у пошуковій системі на статичній сторінці. Що робити?
Ну, є виправлення. Більше як kludge. Але це працює. Що ви робите, скажіть веб-серверу, що сторінки з розширенням .htm (та / або .html) фактично є динамічними і повинні розглядатися як динамічні сторінки. Це трохи збільшить навантаження на ваш сервер (оскільки всі сторінки .htm будуть оброблені до рендеринга), але це дуже незначно, і ви, напевно, не помітите цього.
Це не відрізняється від навантаження, ніж якщо б ви просто перемкнули всі ваші сторінки на динамічний.
Обробка .html сторінок, як якщо б вони були .php в Apache
Ви можете змусити всіх сторінок * .htm проаналізувати інтерпретатором php з директивою .htaccess:
Додаток AddType / x-httpd-php .html
Внесіть відповідні коригування, якщо це * .htm документи, які потрібно обробити:
Додаток AddType / x-httpd-php .htm
Обробка .htm сторінок, як якщо б вони були .asp в IIS
У Менеджері Інтернет-послуг перейдіть на вкладку "Домашній каталог" властивостей веб-сайту та натисніть кнопку "Конфігурація". На вкладці "Відображення прикладних програм" цього спливаючого вікна можна керувати способами обробки файлів. Ви хочете налаштувати нове відображення для розширення HTM, яке виглядає так само, як відображення ASP. Ви також можете зробити це для файлів HTML, якщо ви їх використовуєте.
Деякі системи налаштовані інакше, ніж у моїх - просто подивіться на те, що налаштування для ваших сторінок ASP і дублювати їх для сторінок HTM.
Висновок
Перенаправлення скриптів може багато чого досягти, і якщо це серверна сторона, то ви, звичайно, досить безпечні щодо пошукових систем, що слідують за ним. Загалом, це займе менше накладних витрат і простіше використовувати перенаправлення веб-сервера за допомогою будь-якого з них Apache або IIS . Однак перенаправлення з використанням сценаріїв є законною технікою для людей без повного контролю над своїм сервером, або у яких є дуже специфічні сценарії, які вимагають перенаправлення, які не підтримуються безпосередньо веб-сервером.
Далі: Геолокація та перенаправлення
Головна стаття
Детальна технічна інформація
Конкретні сценарії та способи їх вирішення
Якщо не вказано інше, всі статті, написані Іаном Маканеріном, BASc, LLB. Copyright © 2002-2004 Всі права захищені. Дозвіл повинен бути наданий письмово для використання або перевидання будь-де, але на цьому сайті, але ми дозволяємо це і не стягуємо плату за неї, окрім зворотного. Зв'яжіться з нами для отримання додаткової інформації.
Пов'язані
Питання в тому, як вони з нею дивляться, як вони це роблять?Що робити?