Маленький файл с большой душой — htaccess и SEO

htaccess

Настройка файла htaccess может показаться утомительной задачей, особенно если вы с ним не знакомы. И, честно говоря, если вы не знакомы с ним, вы должны действовать осторожно, так как вы можете довольно легко вывести из строя весь сайт, введя неправильное правило или даже просто неправильный символ. Не пытаясь напугать, просто констатирую факт. В этой статье мы сосредоточимся на том, как SEO может извлечь из этого пользу в некоторой степени безопасным образом. В конце концов, это довольно удобный маленький файл для многих вещей, и я сообщу вам о нескольких типичных случаях его использования.

Что такое файл htaccess?

Упрощенное описание файла гипертекстового доступа состоит в том, что он является подмножеством правил конфигурации веб-сервера Apache на уровне каталога. Один веб-сайт может иметь несколько таких в каждом каталоге, но в этой статье мы сосредоточимся на экземпляре webroot. Зная это, вы можете делать более сложные вещи, но для большинства из них использования файла webroot обычно более чем достаточно.

Другими словами, вы можете переопределить или добавить глобальную конфигурацию Apache с помощью htaccess. Распространенными случаями использования являются, например, перенаправление URL-адресов, сокращение URL-адресов, управление доступом (для разных веб-страниц и файлов) или настраиваемые ответы об ошибках. Вы можете сделать намного больше с другими правилами конфигурации. Если вы ищете более сложные случаи, я планирую написать более подробное руководство в своем блоге. Наличие файла в webroot означает, что мы можем контролировать правила в пределах одного домена, не изменяя правила в других доменах на том же сервере. Начинаете видеть преимущества уже?

Даже если многим это может показаться языком программирования, файл состоит из директив Apache, которые являются вариантом PCRE (регулярные выражения, совместимые с Perl). Не волнуйтесь, вам не нужно изучать новые языки, и в этом контексте это всего лишь формат, который htaccess использует в своем наборе правил. Просто сообщаю вам, если вы хотите найти больше информации об этом, и сокращения всегда весело. Сеть полна подробных и объясненных примеров, так что только небольшие изменения должны помочь вам.

Этот файл также не имеет ничего общего с приложением, в котором размещен ваш сайт, он рассматривается как отдельный файл, такой как WordPress, Magento, Prestashop и т. Д. Он связан с самим веб-сервером и не имеет ничего общего с CMS или Платформа eCom, которую вы используете. Те же правила применяются независимо от системы, на которой работает ваш сайт. Единственное, что может измениться, — это структура каталогов при перенаправлении или блокировании доступа в рамках правил. Поэтому не имеет значения, построен ли ваш сайт на PHP, Ruby или Javascript. Функциональность файла с гипертекстовым доступом остается прежней.

Как вы уже поняли, .htaccess в основном используется веб-серверами Apache. Если вы используете nginx (еще одно очень популярное программное обеспечение веб-сервера), настройки немного отличаются, поэтому правила не совсем совпадают. Поэтому, возможно, первое, что нужно проверить, это выяснить, какой веб-сервер работает на вашем сайте, прежде чем идти вперед.

Как работает htaccess?

Таким образом, имя файла — .htaccess, и по умолчанию оно должно быть именно таким, чтобы оно работало. На самом деле это имя htaccess, а точка или полная остановка перед именем файла означает, что это скрытый файл. Это распространенный способ скрывать файлы в среде UNIX / LINUX. Поэтому вам нужно знать, как увидеть скрытые файлы в вашей системе, чтобы показать .htaccess.

Сам файл представляет собой простой текстовый файл. Используйте подходящий редактор при редактировании или создании его на локальном компьютере, например Notepad ++, Atom или Sublime Text. Я предпочитаю использовать его в кодировке символов UTF-8, потому что я в старой школе, и много лет назад кодовые наборы были своего рода хлопотами, поэтому после UTF-8 я придерживаюсь этого. Если вы редактируете его в режиме онлайн через cPanel, он обычно имеет правильные настройки по умолчанию. Если вам нужно передать его по FTP или SFTP, убедитесь, что передача выполняется в режиме ASCII. Я не буду вдаваться в подробности с настройками программного обеспечения FTP и так далее, я полагаю, вы уже знакомы с ними.

Вроде бы много мелочей, но через некоторое время вы обретаете рутину вокруг этого, и, как правило, настройки нужно устанавливать один раз для каждого программного обеспечения. Просто важно знать это, потому что неправильные настройки могут испортить ваш новый блестящий файл, и он не будет работать должным образом при установке на сервере. С .htaccess дьявол действительно в деталях.

Итак, теперь у нас есть чистый файл. Давайте начнем этим пользоваться. Если у вас уже есть содержимое файла (что, вероятно, связано с вашим текущим программным обеспечением для веб-сайтов, таким как WordPress и т. Д.), Не беспокойтесь, мы рассмотрим основы в дальнейшем.

Структура содержимого файла

Я возьму базовый WordPress htaccess в качестве примера для ознакомления с синтаксисом. Вы, наверное, видели это много раз и задавались вопросом, что здесь происходит. Итак, давайте разделим это!

# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress

Во-первых, вы можете увидеть символ # для комментирования в каждой строке. Комментарий заканчивается на разрыве строки или обычно нажатием Enter. Htaccess не поддерживает блоки комментариев, поэтому, если вам нужно прокомментировать несколько строк, каждая строка комментария начинается с #

RewriteEngine On

Здесь мы убедимся, что движок Apache для этого сайта включен. Это отдельный модуль, который отсутствует в ядре Apache, и его можно установить на уровне сервера в глобальном файле конфигурации httpd.conf или как мы делаем здесь для каждого каталога через htaccess. Если это установлено на уровне сервера, нам не обязательно повторять это здесь.

RewriteBase /

Здесь мы устанавливаем базу для последующих правил перезаписи, чтобы обрабатывать ее как базу. Вам необходимо использовать относительные пути. Это может стать немного сложнее для понимания, если у вас есть несколько htaccess в нескольких каталогах в игре, но давайте предположим, что у вас есть только один в webroot. Символ / в данном случае означает корень документа, в котором находятся файлы сайта. Обычно это означает то же самое, что https://www.example.com/ при переводе в URL домена.

RewriteRule ^index\.php$ - [L]

Правила переписывания — это то, где происходит настоящая магия переписывания. Вы можете иметь практически бесконечное их количество, но помните, что это делается на лету. Это означает, что правила проверяются несколько раз при каждом просмотре страницы на сайте. Их может быть довольно много, прежде чем это окажет какое-либо влияние на реальный мир, особенно если ваш веб-сервер использует SSD-диски (и я не знаю, почему это не так). Но, как правило, рекомендуется сохранить файл как можно более тонким.

Синтаксис правил переписывания следующий:

RewriteRule Pattern Target / Substitution [Флаг1, Флаг2, Флаг3]

Флаги — это необязательные модификаторы правила, которые могут изменить поведение правила. Например, мы можем установить cookie, когда правило соответствует флагу CO, и дать cookie некоторые ключи и значения, мы можем настроить некоторые страницы на возврат 403 запрещенного кода ошибки с флагом F и установить типы MIME для определенных файлов с помощью Т флаг.

Это может стать очень техническим, очень быстрым, но это только для того, чтобы показать, насколько универсальным является правило. Давайте вернемся к правилу под рукой.

RewriteRule ^index\.php$ - [L]

Поэтому здесь мы ищем файл index.php и ничего больше с ^index\.php $. Это формат регулярных выражений, который очень силен для нахождения очень универсальных групп строк в основном и полезен также в GA с ограничениями. Google немного убрал регулярные выражения, но все еще очень полезен и там. Так что было бы неплохо хотя бы немного ознакомиться с ним.

Хорошо, давайте пройдемся по строке шаблона, ^ обозначает начало строки. Если вы хотите найти строку, содержащую точку, вам нужно экранировать символ \ символом. И $ отмечает конец строки. Я надеюсь, что это имеет какой-то смысл. Но у ^index\.php $ есть только одно совпадение — index.php и все. Это точный поиск совпадений, так сказать.

Тогда, как мы видим, наша цель или замена — это не что иное, как -. Это означает, что нет замены. И затем, в конце концов, появляется флаг [L], который указывает прекратить обработку правил.

Итак, мы искали файл index.php и установили правило, которое ничего не делает, какой смысл? Задача состояла в том, чтобы не допустить переписывания более поздних правил в index.php. Мы этого не хотим, так что это своего рода гарантия для index.php. Фактически мы хотим, чтобы index.php обрабатывал наши постоянные ссылки в WordPress. Другими словами, если браузер заходит на index.php, мы не хотим, чтобы какие-то более поздние правила действовали дальше и позволяли CMS или чему-либо другому делать свое дело.

Как вы можете видеть в htaccess, порядок имеет значение. Вам нужно иметь правила в определенном порядке, чтобы достичь поставленных целей. Просто чтобы помнить об этом по мере продвижения вперед.

RewriteCond %{REQUEST_FILENAME} !-f

Условия перезаписи — это способ ограничить типы запросов, на которые будет влиять правило перезаписи ПОСЛЕ их выполнения. Например, вы можете установить определенные перенаправления только для определенного набора IP-адресов.

Синтаксис условий перезаписи следующий:

Условие тестовой строки RewriteCond [Flag1, Flag2, Flag3]

Если задано более одного условия, все они должны соответствовать или быть истинными, прежде чем будет применено следующее правило. Тестовая строка обычно в этом контексте является серверными переменными, такими как %{REQUEST_FILENAME}. Имя файла запроса содержит полный URL-адрес запрошенного файла с веб-сервера и задается на уровне сервера.

Условие в этом случае является !-F. -f означает непосредственно «обычный файл», поэтому он проверяет, является ли тестовая строка допустимым файлом. Но ! в начале отрицает это, так что фактически проверяет, является ли тестовая строка НЕ ​​допустимым файлом. Имеет смысл?

Хорошо, я знаю, что это может быть много. Давайте подведем итоги. Итак, правило

RewriteCond %{REQUEST_FILENAME} !-f

Проверяет, не является ли полный URL-адрес, к которому обращается посетитель, недействительным файлом. Если это не так, мы идем вперед. Это способ отловить пути перезаписи, поскольку постоянные ссылки не являются реальными файлами или каталогами. Нам нужно их обработать, иначе сервер просто выдаст 404 ошибки. Вот как мы их ловим и направляем в CMS и т. Д. Для дальнейшей обработки.

Еще не спит? Хорошо, давайте перейдем к следующему.

RewriteCond %{REQUEST_FILENAME} !-d

Хорошо, здесь мы установили то же условие, что и раньше для файлов, теперь мы делаем это для каталогов. Потому что, конечно, они не одно и то же.

Итак, теперь у нас есть два установленных условия, которые проверяют, является ли запрошенный URL-адрес недопустимым файлом AND не допустимым каталогом. Если оба совпадают и только тогда, мы обрабатываем следующее правило.

RewriteRule . /index.php [L]

Так что это правило, которое мы обрабатываем, когда выполняются условия. Другими словами, если кто-то пытается получить доступ к чему-то на нашем веб-сайте, который не существует, то есть постоянная ссылка в жаргоне WordPress. Здесь шаблон представляет собой простую точку, которая означает любой символ, кроме разрыва строки. Но так как разрывы строк встречаются редко в контексте URL, это в основном означает все. И теперь целью является просто /index.php, который является файлом index.php в webroot, который мы защищали прежде от дальнейшей перезаписи. И снова [L] останавливает обработку еще каких-либо правил. Именно поэтому ваши правила могут не сработать, если вы поставите их ниже этого или между условиями. Порядок здесь имеет значение, ребята.

Итак, что мы на самом деле настроили сервер здесь? Наша конечная цель — позволить WordPress обрабатывать постоянные ссылки на своем конце. Для этого мы переписываем каждый запрос, который не указывает на фактический файл или каталог, в /index.php и проверяем, когда запрос приходит к index.php, он на этом останавливается. Вот и все. Тогда WordPress берет на себя ответственность и делает свое волшебство.

Для чего вы можете использовать файлы .htaccess?

Я перечислю несколько вариантов использования, чтобы у вас было более четкое представление о том, на что способен маленький файл, помимо перенаправления URL-адреса, сокращения URL-адреса, контроля доступа или настраиваемых ответов об ошибках. Давайте сохраним актуальность в SEO.

  • Простая авторизация и аутентификация. Удобно, например, когда промежуточный сайт не попадет в индекс Google раньше времени. Конечно, вы не должны индексировать свои промежуточные сайты, но индексирование промежуточного сайта может быть настолько плохим, что может быть хорошей идеей убедиться, что это не произойдет с простой авторизацией.
  • Перезапись URL: Да, так называемые «красивые URL» также используют .htaccess во многих случаях. Или, по крайней мере, позволяет CMS обрабатывать все это.
  • Список каталогов: мы можем контролировать реакцию сервера, если не указана конкретная веб-страница. Допустим, у нас есть несколько PDF-файлов, которые мы не хотим перечислять. Мы можем контролировать, отображается ли список или нет через htaccess.
  • HTTPS & HSTS: реализация HTTPS и HSTS на серверах Apache в значительной степени зависит от правильной перезаписи URL и информации заголовка, указанной в файле .htaccess. Любой неправильный синтаксис в файле при развертывании HTTPS или HSTS приводит к сбою в реализации.
  • Сообщения об ошибках: ошибки случаются независимо от того, что мы делаем, но приятно предоставлять посетителям тематические сообщения о том, что происходит. Через htaccess мы можем дать именно это.
  • Перенаправления: мы, SEO, любим наши 301, не так ли? Мы также можем установить их здесь.
  • Блокировка: если у нас есть, например, неприятный бот, роуминг на наших сайтах, мы можем заблокировать его здесь по IP-адресу. Мы также можем заблокировать трафик с определенных сайтов с помощью реферера. Веселье, веселье, веселье.

И даже больше … как вы видите, этот небольшой файл имеет некоторый символ, badum-tsss.

Я бы с удовольствием рассмотрел все варианты использования с примерами, но эта статья станет чертовски скучной, так что давайте двигаться дальше. Вы всегда можете найти примеры Google или попросить больше. Идея состоит в том, чтобы дать идеи о том, как извлечь выгоду из этого небольшого файла в качестве SEO.

Не всегда все разумно обрабатывать через .htaccess, потому что у него есть несколько недостатков, таких как:

  • Потеря производительности: меньшая проблема после того, как SSD-накопители стали популярными, но это полезно знать. Для каждого HTTP-запроса к серверу существует доступ к файловой системе, который является узким местом в большинстве ситуаций, и веб-сервер также проверяет правила при каждом доступе в каждом каталоге. Другими словами, диск используется каждый раз, когда вызывается ресурс, по крайней мере, один раз, что может довольно быстро привести к излишнему использованию диска. Есть способы оптимизировать это все же. И если файл не станет физически большим или их много, потеря производительности в большинстве случаев будет незначительной.
  • Безопасность: вам необходимо правильно настроить систему, иначе безопасность может быть нарушена. Всегда убедитесь, что ваш хостинг на высшем уровне по этим вопросам.
  • Синтаксис: Как я уже говорил, с .htaccess дьявол кроется в деталях. В этом контексте это означает, что даже один неправильный персонаж может сломать ваш сайт или его части. Неправильные орфографические ошибки могут легко привести к ошибкам 501 сервера, и это никогда не бывает весело. Вы всегда можете перевести весь файл в автономный режим, изменив имя, например, на _htaccess или htaccess.old. Это сбросит все, что сделано в файле .htaccess, и во многих случаях возвращает сайт в режим онлайн.

Как вы можете себе представить, этот маленький файл обладает большей огневой мощью, чем мы можем справиться. Но универсальность и многочисленные варианты его использования могут быть преимуществом, которое вам может понадобиться в один прекрасный день для облегчения ваших собственных задач. Будьте смелыми, проверьте это и помните, что если вы закрываете сайт, вы можете сбросить все, переименовав файл. Если у вас уже есть рабочий файл в вашем webroot, ОЧЕНЬ хорошая идея скопировать рабочую версию, прежде чем вы зайдете и сделаете свою магию. Таким образом, вы можете легко отменить все изменения, которые вы только что сделали. Как я уже упоминал ранее, я также планирую рассказать об этой теме более подробно в своем блоге позже, поэтому, если вы прочитали это далеко, возможно, вам будет интересно проверить это

0 0 vote
Article Rating
Подписаться
Уведомление о
guest
0 Комментарий
Inline Feedbacks
View all comments