[ad_1]
Во-первых, напомню: как доведение URL-адресов, так и перенаправление 301 можно выполнить в.htaccess файлы или в обработчике 404. Если вы не совсем понимаете, как перезапись URL-адресов и 301-е работают в целом, этот пост определенно поможет. И если вы не читали пост на прошлой неделе о раздвоении личности RewriteRule, вероятно, это полезный справочный материал для понимания сегодняшнего поста.
 |
«Усовершенствование URL-адресов» — это процесс отображения читаемых URL-адресов с большим количеством ключевых слов для конечного пользователя (и робота Googlebot) при фактическом использовании уродливых, часто параметризованных URL-адресов за кулисами для генерации контента для страницы. Вот ты делаешь НЕТ выполните перенаправление 301. (Неясно, что такое перенаправление, 301 или 302 и т. Д.? Здесь, в Центре знаний SEOmoz, вас ждет помощь.) |
|
301-е выполняются, когда вы действительно переместили страницу, и вы действительно хотите, чтобы Googlebot знал, где находится новая страница. Вы признаете роботу Googlebot, что его больше нет в старом месте. Вы также просите Googlebot предоставить новой странице все ресурсы ссылок, заработанные старой страницей в прошлом. Например, вы могли перенести свой веб-сайт на новую систему управления контентом, и все страницы имеют несколько другие URL-адреса, чем те, которые были до перехода. |
 |
Если вам нравится спусковой крючок, вы можете прийти к выводу, что RewriteRule является предпочтительным оружием как для выравнивания URL-адресов, так и для переадресации 301. Конечно, вы МОЖЕТЕ использовать RewriteRule для этих задач, и, конечно же, синтаксис регулярных выражений является мощным способом выполнения некоторых довольно сложных преобразований URL-адресов. И действительно, если вы собираетесь использовать RewriteRule, вероятно, вам следует использовать его в своем httpd.conf файл вместо этого.
В документации Apache есть отличное описание того, когда не использовать .htaccess.
Не бойся обработчика 404
 |
Во-первых, все, кто трепещет при мысли о создании своего собственного обработчика 404, примите валиум. Это не так уж сложно. Если у вас работает RewriteRule и вы дожили до конца, у вас не возникнет проблем с созданием собственного обработчика ошибок 404. Это просто веб-страница, на которой отображается какое-то сообщение «не найдено», но она дает вам возможность взглянуть на запрошенную страницу, и, если вы можете «сохранить ее», вы перенаправляете пользователя на страницу, которую они ищите всего парочку строк кода. |
В противном случае возвращается статус HTTP 404 вместе с тем, как вы хотите, чтобы страница выглядела, когда вы говорите им, что не можете найти то, что они искали.
Кстати, наличие собственного обработчика 404 дает вам возможность развлечь пользователя, а не просто заставить его пожалеть себя. Посмотрите этот пост в Smashing Magazine на креативных страницах 404.
Хорошее чувство юмора может вызвать любовь и преданность покупателя, который в противном случае мог бы просто разозлиться на 404.
Вот пример обработчика 404 в ASP. Важная заметка: не использовать Response.Redirect — это 302, а не 301!
Для PHP вам нужно добавить строку в ваш.htaccess указывая туда, куда вы положили обработчик 404:
- ErrorDocument 404 /my-fabulous-404-handler.php
Затем в этом файле PHP вы можете получить URL-адрес, который не был найден, через:
- $ request = $ _SERVER[‘REDIRECT_URL’];
Затем используйте любую логику PHP, которую вы хотите проанализировать URL-адрес и выяснить, куда отправить пользователя.
Если вы можете успешно перенаправить его, установите:
- заголовок («HTTP / 1.1 301 перемещен навсегда»);
- заголовок («Местоположение: http://www.acmewidgets.com/purple-gadgets.php»);
И вот здесь в PHP это становится немного опасным. Нет реального способа передать управление другой веб-странице за кулисами — не сообщив браузеру или роботу Googlebot через 301, что вы передаете его другой странице. Но вы можете использовать звонок требовать() на лету, чтобы получить код с целевой страницы. Просто не забудьте сначала установить код HTTP на 200:
- заголовок (‘HTTP / 1.1 200 OK’);
И вы должны быть осторожны на своем сайте, чтобы использовать include_once () вместо включают() чтобы убедиться, что вы не втягиваете общий файл дважды. Другой вариант — использовать завиток чтобы захватить содержимое целевой страницы, как если бы оно было на удаленном сервере, а затем вернуть HTML-код обратно в поток, повторив то, что вы получили обратно. Но это немного опасно, если вы пытаетесь отказаться от печенья …
И, если вам действительно нужно отправить 404:
- заголовок («HTTP / 1.0 404 не найден»);
Очень важно: будьте осторожны, чтобы убедиться, что вы возвращаете правильный HTTP-код из обработчика 404. Если вы нашли страницу с хорошим контентом, которую хотели бы показать, верните 200. Если вы нашли хорошее совпадение и хотите, чтобы робот Googlebot знал об этом имени страницы вместо того, что было запрошено, сделайте 301. Если вы действительно не знаете, У меня хорошее совпадение, убедитесь, что вы отправили 404. И не забудьте проверить фактические полученные коды ответов — я большой поклонник подключаемого модуля HttpFox Firefox.
Легкость отладки
|
Вот где обработчик 404 действительно завоевывает мою любовь. Поскольку это просто еще одна веб-страница, вы можете вывести частичные результаты манипуляции со строкой, чтобы увидеть, что происходит. На самом деле не кодируйте перенаправление, пока не убедитесь, что все остальное работает. Вместо этого просто укажите введенный URL-адрес, URL-адрес, который вы пытаетесь сфабриковать и перенаправить, и любые промежуточные строки, которые помогут вам во всем разобраться. С участием RewriteRule, отладка в значительной степени состоит из кодирования вашего выражения регулярного выражения, установки флагов и последующего просмотра, работает ли оно. Указывается ли URL в смешанном регистре? Косые черты … вперед? Обеспечить регресс? Мне нужно было сбежать от этого персонажа … или это не та особенность? |
 |
Вы летите вслепую. Это работает или не работает.
Если вы боретесь с RewriteRule регулярные выражения, Rubular имеет хороший редактор / тестер регулярных выражений.
Гибкость программирования
 |
С участием RewriteRule, вам нужно выполнить всю работу в одной строке регулярного выражения. И хотя регулярное выражение элегантно, мощно и должно всем поклоняться, иногда вам может потребоваться более сложная логика перезаписи URL, чем просто умная подстановка. В обработчике 404 вы можете вызывать функции для таких вещей, как преобразование числовых параметров исходного URL-адреса в слова и наоборот. |
Доступ к вашей базе данных
|
Если вы работаете с большим сайтом, управляемым базой данных, вам может потребоваться поиск элементов в базе данных для преобразования параметров в слова. А поскольку обработчик 404 — это просто еще одна веб-страница, вы можете делать с базой данных все, что и на любой другой веб-странице. |
 |
Например, у меня был туристический веб-сайт, на котором пункты назначения, острова и отели определялись в базе данных по числовым идентификаторам. Необработанная страница, на которой отображается контент для отеля, также должна отображать страну и остров, на котором находится отель.
Необработанный URL-адрес для конкретной страницы отеля мог быть примерно таким:
/hotel.asp?dest=41&island=3&hotel=572
В то время как «красивый URL» для этого отеля мог быть примерно таким:
/ отели / Гавайи / Мауи / Гранд-Вайлеа /
Когда клиент запрашивал приведенный выше «красивый URL», мой обработчик 404 разбивал URL-адрес на разделы:
- поиск 2-го раздела в таблице назначений (Гавайи = 41)
- поиск 3-го раздела в таблице островов (Мауи = 3)
- поиск 4-го раздела в таблице гостиницы (Гранд Вайлеа = 572)
Затем я бы назвал функцию ASP Server.Transfer передать исполнение /hotel.asp?dest=41&island=3&hotel=572 для создания контента.
Теперь имейте в виду, что вы, вероятно, захотите сгенерировать ссылки к вашим красивым URL-адресам из идентификаторов базы данных, а не жестко их кодировать. Например, если у вас есть страница со списком всех отелей на Мауи, вы получите все идентификаторы отелей из базы данных для отелей, в которых destination = 41
и остров = 3, и хотите написать ссылки вроде / отели / Гавайи / Мауи / Гранд-Вайлеа /. Функции, которые вы пишете для этого, будут очень и очень похожи.
к тем, которые вам нужны для декодирования этих URL-адресов в обработчике 404.
И последнее, но не менее важное: вы можете отслеживать 404-е, которые вас удивляют (т. Е. Настоящие 404-е), отправив страницу либо по электронной почте, либо зарегистрировав URL-адреса 404 в таблице.
в вашей базе данных.
Представление
 |
Для большинства людей производительность труда снижается.htaccess не будет значительным. Но если вы выполняете оптимизацию URL-адресов для крупного сайта или переименовали огромный список страниц на своем сайте, есть несколько вещей, о которых вы, возможно, захотите знать — особенно с учетом того, что Google теперь использует скорость загрузки страницы в качестве одного из его факторы ранжирования. |
Все запросы оцениваются в.htaccess, нужны ли URL-адреса в манипуляции / перенаправлении или нет.
Сюда входят ваши файлы CSS, изображения и т. Д.
Перенося переписывание / перенаправление на обработчик 404, вы избегаете проверки кода сопоставления URL-адреса с каждым файлом, запрашиваемым с вашего веб-сервера — только URL-адреса, которые не могут быть найдены как есть, попадут в обработчик 404.
Сказав это, обратите внимание, что вы можете сопоставить шаблон в.htaccess для страниц, которыми НЕ нужно манипулировать, и используйте L флаг для преждевременной остановки обработки.htaccess для URL-адресов, которые не нуждаются в особой обработке.
Даже если вы ожидаете, что почти каждая запрашиваемая страница будет нуждаться в де-красивом URL (преобразовании в параметризованную страницу), не забывайте о файлах изображений, файлах Javascript, CSS и т. Д. Подход обработчика 404 позволит избежать наличия URL-адресов для этих компонентов страницы. проверяется на соответствие вашим шаблонам конверсии каждый раз, когда они выбираются.
Особый случай
Хорошо, может быть, этот случай не такой уж особенный — вообще-то он довольно распространен. Допустим, мы перешли к структуре новых красивых URL-адресов из старых параметризованных URL-адресов.
Мы не только должны иметь возможность перейти от красивого URL -> параметризованного URL-адреса для создания содержимого страницы для пользователя, мы также хотим перенаправить ссылочный вес из любых старых параметризованных URL-ссылок на новые красивые URL-адреса.
На актуальной параметризованной веб-странице (например, hotel.asp в приведенном выше примере) мы хотим сделать 301 редирект на красивый URL. Мы возьмем каждый из числовых параметров, найдем пункт назначения, остров и название отеля и создадим наш красивый URL-адрес и 301 для этого. Там ссылочный сок все сохранен …
Но мы должны быть осторожны, чтобы не попасть в бесконечный цикл, конвертируя туда-сюда, туда-сюда:
Когда это происходит, Firefox предлагает сообщение о том, что вы сделали что-то настолько глупое, что даже не пытается получить страницу. Однако они говорят это так вежливо: «Firefox обнаружил, что сервер перенаправляет запрос на [URL] таким образом, который никогда не будет завершен «.
Кстати, вполне возможно, что та же проблема возникнет через RewriteRule высказывания — знаю по личному опыту 🙁
На самом деле решить эту проблему не так уж и сложно. В ASP, когда обработчик 404 передает управление странице hotel.asp, строка запроса теперь начинается с «404; http«. Итак, в hotel.asp мы видим, начинается ли строка запроса с 404, и если да, мы просто продолжаем отображать страницу. Если она не начинается с 404; http, тогда мы 301 переходим к красивому URL.
Другие ссылки
Информация о настройке обработчика 404 в Apache:
- http://www.plinko.net/404/custom.asp
- http://www.webreference.com/new/011004.html
- http://www.phpriot.com/articles/search-engine-urls/4
Документация Apache по RewriteRule:
- http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html#RewriteRule
Пользовательские страницы ошибок ASP.net:
- http://aspnetresources.com/articles/CustomErrorPages.aspx
Отличная статья о создании страниц 404 для сайтов WordPress, которые удерживают клиентов на вашем сайте (спасибо
Archshrk!):
- http://yoast.com/404-error-pages-wordpress/
[ad_2]
