Комментарии 49
>Для SEO оптимизации, желательно, чтобы сайт был размещен только на одном домене. Если у вас несколько доменов ссылаются на один сайт, делаем редиректы на основной домен. Желательно, чтобы он начинался с www.
Как раз таки для SEO оптимизации основной домен должен быть без www, а все остальные редиректиться на него. Так как домен www.domen.ru, является по сути доменом третьего уровня. А в некоторых зарубежных поисковых системах (да и вообще чисто эстетически) домен второго уровня имеет большее значение, чем с www (третьего уровня). Конечно здесь стоит учитывать какой домен вы раскручиваете (если вы закупали ссылки для SEO на domen.com, то стоит сделать редиректы с www на http. Если вы закупили ссылки на www, то редиректы должны быть как указаны в статье).
Как раз таки для SEO оптимизации основной домен должен быть без www, а все остальные редиректиться на него. Так как домен www.domen.ru, является по сути доменом третьего уровня. А в некоторых зарубежных поисковых системах (да и вообще чисто эстетически) домен второго уровня имеет большее значение, чем с www (третьего уровня). Конечно здесь стоит учитывать какой домен вы раскручиваете (если вы закупали ссылки для SEO на domen.com, то стоит сделать редиректы с www на http. Если вы закупили ссылки на www, то редиректы должны быть как указаны в статье).
Спорный вопрос, существует и такая точка зрения, как у вас. Но такие сайты как google, youtube, microsoft, facebook все-таки делают редирект на www. Кроме того, такой подход имеет еще некоторые преимущества. Поэтому я и советую www.
Указанным вами сайтам как-то положить на SEO. WWW в начале — это дань традиции.
Я ориентируюсь на best-practices. Всем хорошим сайтам все равно на SEO. И статья не о SEO, хотите, делайте без www. Я не против :)
>SEO оптимизации
А тавтология вас не смущает не смущает?
А тавтология вас не смущает не смущает?
Ваши слова были бы правильными лет 5-8 назад. Чтобы о новом хорошем сайте кто-то узнал и он получил начальную аудиторию без seo сейчас не обойтись, так как выдача пестрит раскрученными гавносайтами, дорами и сателитами. И найти там хороший сайт, который только что открылся, невозможно. А одной публикации о нем на паре известных ресурсов недостаточно чтобы он стал супер популярным.
Кроме того, такой подход имеет еще некоторые преимущества.
звучит многообещающе, но как-то недосказанно.
звучит многообещающе, но как-то недосказанно.
Речь идет о возможности ставить куки на www.domain.com.
Которые не будут распространяться на static.domain.com.
Это уже для тонкой оптимизации.
См: Best Practices for Speeding Up Your Web Site, секция «Use Cookie-free Domains for Components»
Которые не будут распространяться на static.domain.com.
Это уже для тонкой оптимизации.
См: Best Practices for Speeding Up Your Web Site, секция «Use Cookie-free Domains for Components»
Согласен с DedalX по поводу www, начинаете сайт с 0 — лучше делать без www, если сайт уже работал через www и имеет всякие пузомерки, то лучше его и оставить на www.
По поводу вообще настроек в htaccess то в проекте Kickstrap (который не так давно упоминался на харбе habrahabr.ru/post/141115/) есть очень хорошие настройки с описанием что и почему. Скачайте посмотрите — не пожалеете.
По поводу вообще настроек в htaccess то в проекте Kickstrap (который не так давно упоминался на харбе habrahabr.ru/post/141115/) есть очень хорошие настройки с описанием что и почему. Скачайте посмотрите — не пожалеете.
чего только не выдумают сео-оптимизаторы, чтоб показать, что они не зря едят свой хлеб
Спасибо за то, что поделились!
Интересует вопрос немного не по теме: почему желательно, чтобы основной домен начинался с www? Каким образом это влияет на SEO?
Интересует вопрос немного не по теме: почему желательно, чтобы основной домен начинался с www? Каким образом это влияет на SEO?
См. комментарий выше
Ещё бы флажок QSA добавить в редирект
Мне кажется, это не существенно в этом месте.
Если в приложении вы используете скрипт с паттерном «Фронт контроллер», то эти флаги нужны именно там.
Если в приложении вы используете скрипт с паттерном «Фронт контроллер», то эти флаги нужны именно там.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php?url=$1 [QSA,L]
</IfModule>
При чём тут вообще фронт контроллер.
Если по каким-то причинам запрос пришёл на не тот домен, то без флажка QSA вы потеряете весь GET
Если по каким-то причинам запрос пришёл на не тот домен, то без флажка QSA вы потеряете весь GET
Никогда не замечал, чтобы терялось.
Проверил, все ок.
Проверил, все ок.
Эм, с помощью какой магии в правиле
> RewriteRule ^(.*)$ www.example.com/$1 [R=301,L]
будет добавляться GET?
Вы уверены, что вы поняли проблему?
> RewriteRule ^(.*)$ www.example.com/$1 [R=301,L]
будет добавляться GET?
Вы уверены, что вы поняли проблему?
Проблему понял :)
Видимо QSA нет потому, что GET запросы не сливаются.
По идее если бы было RewriteRule ^(.*)$ www.example.com/?$1 [R=301,L], тогда точно нужно было.
Проверьте, все работает.
Видимо QSA нет потому, что GET запросы не сливаются.
По идее если бы было RewriteRule ^(.*)$ www.example.com/?$1 [R=301,L], тогда точно нужно было.
Проверьте, все работает.
Гхм, и вправду. Неужели из-за R он query-string добавляет автоматом в этом случае :-S
А потом пхпешников обвиняют в низкой квалификации — чего гадать, если есть документация:
httpd.apache.org/docs/current/mod/mod_rewrite.html
Modifying the Query String
By default, the query string is passed through unchanged. You can, however, create URLs in the substitution string containing a query string part. Simply use a question mark inside the substitution string to indicate that the following text should be re-injected into the query string. When you want to erase an existing query string, end the substitution string with just a question mark. To combine new and old query strings, use the [QSA] flag.
Qsa надо использовать если вы рерайтите не только путь, но и строку запроса, чтобы апач корректно скомбинировал старые и новые параметры.
Если вы не рерайтите строку запроса, то он просто передаст параметры без изменений
httpd.apache.org/docs/current/mod/mod_rewrite.html
Modifying the Query String
By default, the query string is passed through unchanged. You can, however, create URLs in the substitution string containing a query string part. Simply use a question mark inside the substitution string to indicate that the following text should be re-injected into the query string. When you want to erase an existing query string, end the substitution string with just a question mark. To combine new and old query strings, use the [QSA] flag.
Qsa надо использовать если вы рерайтите не только путь, но и строку запроса, чтобы апач корректно скомбинировал старые и новые параметры.
Если вы не рерайтите строку запроса, то он просто передаст параметры без изменений
Никто и не гадал.
Спасибо за шпильку, без неё уж никак, конечно.
ps: а потом оказывается, что русские коммунити в основном состоят из комментариев с обкидыванием друг друга говном.
Спасибо за шпильку, без неё уж никак, конечно.
ps: а потом оказывается, что русские коммунити в основном состоят из комментариев с обкидыванием друг друга говном.
Ну это давно известно, что русским только дай что-нибудь обгадить :-)
Просто у вас довольно продолжительное получилось обсуждение параметра QSA, при этом ни та ни другая сторона обсуждения не пыталась даже обратиться к документации, хотя судя по сообщениям krugvs — он каким-то эмпирическим путем пришел к верному ответу, что qsa надо использовать когда происходит слияние запросов.
Просто у вас довольно продолжительное получилось обсуждение параметра QSA, при этом ни та ни другая сторона обсуждения не пыталась даже обратиться к документации, хотя судя по сообщениям krugvs — он каким-то эмпирическим путем пришел к верному ответу, что qsa надо использовать когда происходит слияние запросов.
Я бы не стал судить, какой из ответов «верный» :-)
Добавленный QSA хуже не сделает. Я его по инерции использую везде, где мне нужны параметры. И этот вариант явно не хуже, просто потому, что в случае модификации правила (добавления? с параметрами) ничего не сломается, а в сценарии с «указываем там, и только там, где нужно» — мы должны об этом помнить всегда.
Добавленный QSA хуже не сделает. Я его по инерции использую везде, где мне нужны параметры. И этот вариант явно не хуже, просто потому, что в случае модификации правила (добавления? с параметрами) ничего не сломается, а в сценарии с «указываем там, и только там, где нужно» — мы должны об этом помнить всегда.
Bolerplate рекомендует без www и без QSA
# www.example.com должен направлять пользователей на example.com.
# no-www.org/faq.php?q=class_b
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^(.*)$ http://%1/$1 [R=301,L]
</IfModule>
2. Редирект на один домен
Зачем перечислять все домены, когда можно сделать так:
Зачем перечислять все домены, когда можно сделать так:
RewriteEngine on
RewriteCond %{HTTP_HOST} !^example\.org
RewriteRule ^(.*)$ http://example.org/$1 [R=permanent,L]
Прокеширование у вас все неверно.
И с таким Expire он действительно наступит 21 декабря :)
И с таким Expire он действительно наступит 21 декабря :)
Пункт 4 можно записать и одной строчкой, просто перечислив типы
Для mod_expires можно еще так прописать настройки:
Для mod_expires можно еще так прописать настройки:
<ifModule mod_expires.c>
ExpiresActive On
ExpiresDefault "access plus 1 seconds"
ExpiresByType text/html "access plus 1 seconds"
ExpiresByType image/x-icon "access plus 2592000 seconds"
ExpiresByType image/gif "access plus 2592000 seconds"
ExpiresByType image/jpeg "access plus 2592000 seconds"
ExpiresByType image/png "access plus 2592000 seconds"
ExpiresByType text/css "access plus 604800 seconds"
ExpiresByType text/javascript "access plus 216000 seconds"
ExpiresByType application/x-javascript "access plus 216000 seconds"
</ifModule>
А разве не надо все правила переносить в конфигурацию и убирать .htaccess на продакшене? Или я что-то забыл про апач?
Все это и многое другое описано в HTML5 Boilerplate
А можно подобный пример для IIS?
> Всегда указываем кодировку. По умолчанию лучше выбирать utf-8.
Этого не нужно делать НИКОГДА. Эта кодировка отдается в http заголовках и более приоритетна для браузера, нежели указанная внутри страницы в meta-теге с http-equiv=«Content-type». Не раз встречался с такими необычными хостингами, где приходилось дополнительно оверрайдить заголовок.
Этого не нужно делать НИКОГДА. Эта кодировка отдается в http заголовках и более приоритетна для браузера, нежели указанная внутри страницы в meta-теге с http-equiv=«Content-type». Не раз встречался с такими необычными хостингами, где приходилось дополнительно оверрайдить заголовок.
Ставьте ту же кодировку, что и в http-equiv=«Content-type».
В некоторых случаях сервер (например, апач) перекодирует содержимое в кодировку, больше подходящую пользователю с точки зрения сервера. Если при этом указать кодировку в самой странице, она может не совпадать с той, в которой сервер отдаёт содержимое сайта. Поэтому тэг
<meta> с указанием кодировки — не нужен.
Вот мне всегда было интересно: сжатие текстовых файлов происходит действительно налету?
То есть компрессор работает «с нуля» при каждом запросе? Или какое-то кэширование есть?
То есть компрессор работает «с нуля» при каждом запросе? Или какое-то кэширование есть?
Разве не практичнее использовать NGINX?
еще можно добавить выставлене MIME-типов, а DEFLATE можно в одну строку записать
Не холивара ради, но в последнее время полностью перешёл на nginx и забыл об апаче. Может то же самое про nginx расскажете?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Простая настройка .htaccess для production