Добрый день, друзья, опять я давно не писал. Новогодний аврал, знаете ли, но я все равно на связи. Помните выражение «Все новое – это хорошо забытое старое»? Так вот сегодня я хочу поговорить об азах оптимизации, а именно про внутреннюю оптимизацию сайта. Как я заметил, очень многие настолько уверены в том, что они отлично это знают, что даже не задумываются и добровольно игнорируют важнейшие моменты, без учета которых о внешней оптимизации не может идти и речи. Признаться, я и сам грешу порой, и из-за этого последнюю неделю переверстывал свои проекты.
И вообще в последнее время я все больше и больше убеждаюсь в том, что внутренняя оптимизация гораздо важнее внешних факторов и позволяет сэкономить огромные бюджеты в итоге. Итак, хватит лирики, приступим к обсуждению тех самых важных моментов.
UPD А здесь руководство по оптимизации целевых страниц сайта.
Немного о протоколе http
Вспомним некоторые важные для нас коды состояния HTTP:
HTTP/1.1 200 OK
HTTP/1.1 404 Not Found
HTTP/1.1 301 Moved Permanently
HTTP/1.1 304 Not Modified
Для просмотра информации отдаваемой сервером я рекомендую использовать плагин для Mozilla FireFox под названием HttpFox, очень удобная штука для анализа. Так же можно использовать FireBug, у меня стоят оба плагина, чего и вам советую. Если же неохота связываться с плагинами, есть и онлайн сервисы, например, www.askapache.com, но времени на ввод капчи вы потратите намного больше, чем на установку плагинов. Если с выбором определились, то поехали дальше.
Итак, а зачем это нам вообще надо? Прежде чем приступать к какой либо оптимизации, надо убедиться, что наш сайт отдает правильные ответы. Открывая любую существующую страницу сайта, мы должны получить код состояния 200 OK, означающий, что все в порядке.
Открывая ошибочную или несуществующую страницу, мы обязательно должны получить код ошибки 404 Not Found. Это действительно важно, особенно для сайтов с url'ами без ЧПУ, где, допустим, что постраничная навигация строится в виде /index.php?page=2. А что если в конце вписать несуществующий номер страницы? Если вы получите код 200 OK, то нужно это срочно решать!
Если вы меняете структуру сайта или вообще полностью меняете CMS, то при невозможности сохранения старых адресов страниц следует сделать 301 редирект на новые. Это будет означать, что страница теперь находится по новому адресу, а все входящие ссылки и накопленный страницей «вес» (если кому угодно «траст») сохранятся.
А зачем же в список важных кодов ответа сервера я написал 304 Not Modified? Это состояние означает, что страница не изменилась, и роботу незачем ее заново загружать и можно идти дальше. Зачем это надо? А для того, что на больших порталах может содержаться огромное количество страниц, и, чтобы быстро проиндексировать новые (или переиндексировать старые, но изменившиеся), роботу может потребоваться больше месяца. А вы ведь хотите, чтобы поисковик поддерживал индекс вашего сайта в актуальном состоянии, правда! На опыте одного из своих сайтов, количество страниц которого переваливает за полмиллиона, знаю, что переиндексация занимает от месяца до двух!
Только вот почему-то разработчики различных CMS об этом забывают или не думают вообще, а надо было бы! Так что пока такую фишку с кодом ответа 304 можно назвать высшим пилотажем!
Если с базой все нормально, двигаемся дальше.
Внутренняя оптимизация и явные дубли страниц сайта
Самый важный вопрос, который надо решить еще до начала разработки сайта — выбрать «правильную» CMS. К сожалению, очень часто понимаешь, что выбрал «неправильную» CMS уже по прошествии определенного времени, когда переделка сайта и смена CMS невозможны по ряду причин. Поэтому приходится сражаться с уже существующими «болячками».
Возможные проблемы:
- Существование страниц по нескольким адресам, например, с ЧПУ и без него. Это техническая проблема CMS, и решать ее тоже надо на техническом уровне.
- Существование страниц по адресам со слешем на конце и без него (например, site.ru/category и site.ru/category/). Это так же связано с CMS.
- Существование дублей главной страницы вида site.ru и site.ru/index.php. Лучше всего если движок будет сам решать эту проблему, если нет, то советую использовать канонизацию url’ов (наличие на странице <link rel="canonical" href="http://site.ru" />). Этот мета-тег поддерживает как Яндекс, так и Google.
- Выдача главной страницы вместо 404 ошибки для несуществующих страниц. Это проблема CMS, но в последнее время не замечал, чтобы популярные движки допускали такие ошибки, однако раньше я с таким встречался.
- Существование сайта на двух доменах с www и без (www.site.ru и site.ru в глазах поисковых систем это абсолютно два разных сайта). К счастью эта проблема легко решается с помощью 301 редиректа и файла .htaccess
Для основного домена без www:Options +FollowSymLinks RewriteEngine On RewriteCond %{HTTP_HOST} ^www\.(.*) [NC] RewriteRule ^(.*)$ http://%1/$1 [R=301,L]
Для основного домена с www:
Options +FollowSymLinks RewriteEngine On RewriteCond %{HTTP_HOST} ^site\.ru$ [NC] RewriteRule ^(.*)$ http://www.site.ru/$1 [R=301,L]
- Генерация адресов страниц с сессиями для поисковых роботов. Эта проблема очень распространена для большинства форумных движков. Из-за этого в индексе может появляться огромное количество одинаковых страниц, но с разными идентификаторами сессии в url’е. Решений масса, потому описывать тут ничего не буду, достаточно погуглить.
Все это относится к четким или явным дублям и наносит наибольший урон сайту.
Внутренняя оптимизация и неявные дубли страниц или псевдодубли
Очень важным является понятие процента уникальности конкретной страницы относительно остальных проиндексированных страниц в рамках сайта.
Вот распространенный пример: имеется страница сайта, где есть возможность комментирования, при определенном количестве комментарии переносятся на вторую страницу, и эта страница дублирует содержимое первой, но с другими комментариями. А таких страниц может быть много, и с появлением каждой последующей ценность основной страницы снижается.
Подобным образом вредят страницы категорий, тегов, архивов и версий для печати. Все они частично или полностью дублируют важное содержимое основных страниц. Этого нельзя допускать.
Если не получается решить проблемы на техническом уровне (например, «допиливание» CMS или установка модулей и плагинов), придется просто закрывать «ненужные» страницы от индексации. Существует два основных метода: создание в файле robots.txt необходимой директивы и наличие на странице мета-тега <meta name="robots" content="noindex,follow" />.
За проблемы, описанные выше и связанные с дублями страниц или их частей, поисковые системы в строгом порядке накладывают на сайт фильтры и понижают его в выдаче. Бывают и случаи полного вылета сайта из индекса, т.к. «генераторы мусора» поисковикам совсем ни к чему!
Так же от индексации стоит закрывать страницы, не имеющие ценности (профили пользователей, логи, какие-нибудь «промежуточные» страницы и т.д.), технические страницы (страницы обратной связи, регистрации, добавления новости и подобные), то есть те страницы, на которые не планируется вести людей.
В качестве основного инструмента для поиска проблемных мест любого сайта я использую панели вебмастера Гугла и Яндекса, этого более чем достаточно!
Я очень надеюсь, вы осилите и воплотите в жизнь эти простые советы по внутренней оптимизации сайта. Этими правилами ни в коем случае не стоит пренебрегать, положительный эффект порой может быть просто ошеломляющим, я сам лично видел!
Повторюсь, не забывайте про мое руководство по внутренней оптимизации страниц сайта, все-таки структура сайта в целом и структура целевых страниц это совершенно разные вещи и совмещать две этих темы не правильно!
До скорых встреч, друзья, и удачи вам в борьбе с болезнями своих сайтов. Хороший сайт – здоровый сайт!
Спасибо, всегда полезно почитать.
По некоторым запросам выдача Я сайт в подписи выдаёт именно на метку записи, ибо ключ из 3-4 слов (без кавычек) боту удобнее собрать именно со страницы самой метки. Плюс сама страница не представляет же собой простыню, а лишь превью постов. По стате переходов на сайт на меточные страницы не так много, но они присутствуют. Исключительно частный случай.
Пока писал коммент родился душевыдирающий вопрос: можно ли поднять страницу про "мёд" в тематику "горчица", если на неё проставить горчичной тематики ссылок в пределах одного сайта. Глупость, но всё же интересно)
Вы оценили, что потеряете какие-то жалкие несколько переходов на страницы меток, при этом даже не рассматривая вариант, например, минимального роста по всем существующим позициям на 1. Чисто философски-мечтательно подойдите к размышлениям.
Теоретически можно любую страницу поднять куда угодно. Вопрос зачем и сколько это будет стоить? А вообще прошли те времена, когда "найден по ссылке:" было довольно частой картиной в Яндексе. Сейчас внутренние факторы решают очень много, а при сильных недочетах вообще сводя все усилия по работе с внешними факторами на нет.
А мне понравилась статья, спасибо АлаичЪ что напомнил о подобных факторах...
Азы, а вопросы все равно нашлись )
К примеру есть страницы:
site.com/category
и
site.com/category/
Насколько я понял, это проблема. В какую сторону это решить? Как лучше, со слешем или без него?
При этой же проблеме создается новый URL (site.com/new_url_category/). Редирект необходимо ставить с site.com/category или с site.com/category/, или с обоих сразу?
Этот момент понимаю не сильно. Буду рад подсказкам и объяснениям =)
А лучше так, как тебе нравится. Со слешем или без него поисковику абсолютно все равно, главное чтобы страница только одна была. Если тебе будет легче определиться — я использую без слеша.
Исходя из этого вторая проблема не имеет оснований. Просто делаешь редирект со старой основной страницы на новую основную.
Возник попутный вопрос.
А как быть с комментариями? К примеру в WP, где после того, как ты оставляешь коммент в URL добавляются параметры. Это проблема?
Ну вообще-то об этом планировалось рассказать в следующем посте, но для тебя спалю тут ;) Для предостережения от подобных случаев спасает опять же канонизация url'ов, о ней я в этом посте тоже писал.
Просто открой на моем блоге любую страницу с добавлением якоря комментария в конце и посмотри исходный код на наличие rel="canonical".
Спасибо =)
Кстати, посчитай для интереса, сколько уже на твоем блоге слов "спасибо" =) Можешь поставить счетчик :)
Я читал, но не знал, что такое канонизация, а вопрос с www.site.ru, site.ru, site.ru/index.php решал редиректом.
Зашел, почитал, понял, сейчас пойду поэкспериментирую :)
Еще есть каверзный вопрос к тебе (к этому посту последний, честное слово). Раньше страницы были вида site.ru/node/22 (CMS drupal). Сейчас делаем site.ru/category.
Программно site.ru/category переадресуется на site.ru/node/22, но для ПС надо сделать редирект с site.ru/node/22 на site.ru/category
Получится замкнутый круг?
site.ru/node/22 => site.ru/category => site.ru/node/22
Или я чего то не понимаю? Когда объяснял прогерам как надо сделать, они мне рассказали именно такую версию.
Можно сказать ради "спасибо" блог и ведется ;) Я же для новичков его позиционирую!
Я вообще не понял твоего вопроса. Точнее даже не понял идеи, у тебя есть адрес основной, зачем какими-то неясными махинациями делать несколько редиректов чтобы придти к нему же? о_О Выносишь мой мозг прямо с утра! В общем, это идиотизм, как с технической точки зрения, так и с точки зрения ПС. Редирект должен быть всегда только один!
так каким образом организовать данный редирект? то что в .htaccess это понятно. можно ли увидеть пример данного редиректа? (код)
Я думаю это можно организовать таким методом:
Это редирект на страницу со слешем. Как организовать обратный редирект, т.е. на страницу без слеша, в данный момент затрудняюсь ответить.
site.ru/node/22 — страница в индексе, первоначальный и стандартный url в Drupal.
site.ru/category — новый URL человеческий
делаю редирект site.ru/node/22 => site.ru/category
Но, в Drupal при создании синонима site.ru/category идет редирект с этого синонима (site.ru/category) на первоначальный url (site.ru/node/22)
Вот и получается каламбур. Либо я чего-то не понимаю. Либо мне неправильно объяснили принцип в Drupal.
Короче тут геморрой не относящийся непосредственно к общим рекомендациям и принципам, тут проблемы CMS, с которой ты, видимо, не разобрался нормально. Все там должно решаться просто и без плясок с бубном. Достаточно покурить мануал, а в крайнем случае официальный форум поддержки.
Пойду курить =)
Спасибо за напоминание! Хотя все предложенные советы должны быть соблюдены как "должное", многие забывают или просто напросто не следят за их соблюдением.
Добрый день! Подскажите, как включить этот тег rel="canonical". Пишут что он стандартно идет с 2.9 версии WordPressa, но как бы не появляется. Дайте совет что нужно сделать.
Так для этого есть замечательный плагин All in One SEO. Там же в настройках есть пункт "Canonical URLs", ставите галку напротив него и плагин сам решит где, как и что надо прописывать.
И необязательно иметь 2.9 версию, можно более раннюю или более позднюю использовать.
Неохота лишние плагины ставить. А проще варианта нету?
Пропиши в шаблоне head.php для темы и будет работать:
<link rel="canonical" href="http://www.site.ru/page-url/" />
Все разобрался, он проставляется автоматом.
Кому интересно:
Начиная с WordPress 2.9, WordPress будет сам вставлять canonical при помощи стандартных фильтров, которые находятся в wp-includes/default-filters.php вашего WordPress сайта
А вот так отключается
remove_action ( 'wp_head', 'rel_canonical' );
Лишние плагины? Вы шутите? All in One SEO (или любой другой, имеющий подобный функционал) это просто необходимый плагин для работы. Это так же как купить компьютер и не установить операционную систему. Работать будет, но неудобно и неэффективно! Или я чего-то не понял?
У меня подключается скрипт создающий в полуавтоматическом режиме мета-теги title, description, keywords. Вполне хватает.
Это ведь печально! Хотя для вашего блога вполне подходит.
Title надо всегда прописывать ручками. Description можно заполнять на основании анализа запросов приводящих на конкретную страницу. Лично я делаю именно так, как следствие CTR возрастает. Keywords это пожалуй единственное, что можно автоматически генерировать, но я так же прописываю вручную, на основании спроса.
Почему печально! Можно и руками добавить, дописав keywords и description ключи в произвольные поля статьи
Привет. Почитал твои посты, и закрались некоторые противоречия в твоих постах. В одном посте ты пишешь, что выводишь все сайты за счет ссылок + внутренних факторов, в другом посте ты говоришь, что выводишь только за счет внутренних факторов и потом "жалуешься", что на новой работе с тебя требуют вывод сайтов за счет внутренней оптимизации без внешних ссылок... ;)
Поясни пожалуйста, подробнее... посмотрел твои сетки сателлитов /google спалил ;) / и не уверен, что все вылазит за счет внутренних факторов ;)
НЧ 90% что да возможно но не сч, вч, вк, ск запросы...
Можешь этот пост не публиковать, а ответить на емайл если есть желание ;)
Привет. Комментарии публикуются автоматически без модерации, мне скрывать нечего ;)
Сомнения возможны при прочтении постов не в хронологическом порядке или еще как нибудь. Этого не исключаю. Попробую развеять ваши противоречия.
Вы наверняка знаете, что я сменил место работы. На старом месте я продвигал сайты по схеме "внутренняя оптимизация + покупка ссылок", притом покупке ссылок уделялось больше внимания. Как следствие — большой опыт работы с Sape и много полезных материалов на блоге. Ну и сайты в топе, разумеется ;)
На новом месте работы у меня нет клиентских сайтов, я занимаюсь сайтами компании. А здесь уже другие риски, другие приоритеты и другие методы. Так вот сейчас я уделяю все время на внутреннюю оптимизацию. Это дает хорошие результаты.
И на счет "жалуешься", во-первых, я не жаловался, во-вторых, это было когда я только пришел на новое место и не понимал как и что устроено, и это вызывало некоторое недоумение.
Примерно так все и было.
На счет сетки сателлитов =) Да нет у меня сетки, у меня есть экспериментальные сайты и несколько неудачных стартапов (по причине отсутствия времени на них).
Спасибо! Очень интересный пост!
Можно пару вопросов:
1. Правильно ли я понял, что, если мы имеем страницы с кратким описанием "продукта", а оттуда делаем ссылку на страницу с полным описанием, которое включает и текст краткого описания, и еще кучу новых параметров, то это плохо? Делали это с целью оградить пользователя от ненужной информации.
2. Если мы имеем страницы разделов, на которых публикуются анонсы основных страниц, входящих в этот раздел, и одна страница входит в несколько разделов и, соответственно, ее анонс публикуется на страницах всех разделов, в которые она входит, то это тоже ведет к наложению санкций со стороны поисковиков?
Заранее спасибо, Александр
1. Нет, это не плохо. Правильная структура.
2. Выходит не очень хорошо, особенно если анонс дублируется много раз, из-за этого ценность части основной статьи, которая входит в анонс снижается. Каких то строгих санкций можно не бояться, но отсутствие такого «размножения» анонсов может дать мелкие плюсы. Тут вот какой совет: проанализируйте точки входа на свой сайт, и если разделы не собирают трафик или собирают, но очень мало (в процентном соотношении к общему поисковому трафику), то есть смысл вообще закрыть от индексации страницы разделов. Тем самым «убьете» дубли и ускорите индексацию сайта.
Спасибо за ответ
Прошу прощения за назойливость, но я не разработчик сайта, а заказчик, поэтому не все, о чем Вы говорите, схватываю на лету. Но очень хочется разобраться, чтобы правильно ставить задачи разработчикам. Поэтому, если можно, еще пара уточнений.
по п.1. Но ведь в этом случае часть текста каждой страницы существует на двух урлах. Т.е. имеет место массовое неявное дублирование страниц. Стоит закрыть полное описание от индексации, т.к. точкой входа является краткое описание, или два дубля не воспринимаются поисковиком как спам и не стоит парится на эту тему?
по п.2. Анонсы не являются частью основной статьи и пишутся отдельно, специально для представления страницы в разделах (типа превьюшки страничек). Специально от копирайтеров требую не повторять текст основной страницы в анонсе (хотя они, конечно, халтурят в этом :)). Точкой входа сейчас являются конечные страницы, т.е. закрыть раздел от индексации можно без особых потерь для трафика. Но, была идея попытаться оптимизировать сайт так, чтобы точкой входа как раз стал раздел, т.к. он сразу коротко дает представление обо всех страницах со сходной тематикой и может формироваться под поисковый запрос.
Получается, что, если анонс не является текстом основной статьи, то из-за его размножения страница статьи не должна обесцениваться? Но обесценивается сам анонс. И получается, что все равно его не будут находить по запросу, т.е. такая работа по рубрикации с точки зрения поисковой оптимизации бессмысленна?
Еще раз спасибо
Если вы заказчик, советую сейчас и в дальнейшем создавать, так называемый, чек-лист для разработчиков с описанием тонкостей реализации.
Слишком много всего вы написали. Это может послужить темой для отдельного поста или даже нескольких. Вообще если речь идет об организации структуры магазина, а в вашем случае я именно это и вижу, то я планирую посвятить этому отдельный большой пост. Но вкратце: магазины хоть и одинаковые внешне, но очень много зависит от тематики, например, для магазина электроники точкой входа должны быть карточки товара, а для магазина строй материалов точкой входа будут именно категории. О таких тонкостях я и планирую написать руководство.
А вот этот вопрос интересный! Меня здесь кое-что интересует.
Итак. Обычно, структура сайта следующая.
Если мы закроем от индексации "II уровень" (к примеру, в блоге это рубрики с кратким описанием), тогда получится, что "I уровень" не связан ссылками с "III уровнем". Исключение — будет несколько статей, на которые будут идти ссылки с главной в блоках "Последние статьи", "Лучшие статьи" и т.д.).
По логике вещей, все страницы сайта, должны быть связаны ссылками между собой. Тут получается, что "I уровень" отдельно, "II уровень" отдельно и ссылок между ними поисковик не зафиксирует.
Выход здесь может быть следующий — разрешить индексацию и писать к посту оригинальное краткое описание. Есть ли плагин на WP, который на рубрики будет выводить не часть поста, а создавать доп. поле, куда можно написать краткое описание? В таком решении вопроса — есть плюс и минус. Плюс — можно создавать описания, которые будут заинтересовывать людей (у людей будет интерес и они будут кликать и читать Ваши посты). Минус — это ж нужно писать больше =)
Скажите ваши мнения, коллеги.
Жень, все зависит от структуры, которую выбрал вебмастер. Например, у меня нет привязки поста к рубрике, а сама рубрика существует лишь для выборки из списка постов по определенной тематике.
Вопрос связки главной и внутренних страниц решается картой сайта (на блоге она есть у всех), и еще ты упустил момент, что на блоге есть постраничная навигация, ее то мы не закрываем от поисковиков. Так что твои выводы неверны.
Разрешение индексации рубрик и написание уникального анонса это, кончено, выход, но работы больше. А создание отдельно анонса от основного текста не проблема, у меня даже один из разделов на блоге реализован по этому принципу. Вот смотри: alaev.info/fotofolio, здесь краткое описание отлично от описания внутри. Реализуется это при помощи тега <!--more--> два раза по схеме: <img /><!--more-->Анонс<!--more-->Полное описание. Правда для этого пришлось писать функцию отдельную и отдельный шаблон страницы создавать.
В этом решении есть большой плюс — можно в анонсе писать краткую выжимку, так сказать, основные тезисы, тогда пользователь сразу будет знать о чем речь внутри и останется доволен!
Повернул мои мысли в нужную сторону)
С картой сайта на блогах еще не подружился. Надо начать дружить уже с ней.
Про реализацию анонса спасибо) Попробую на днях.
Пока вносил поправочку в коммент, ты уже ответил на него. Поправка в том, что "пришлось писать функцию отдельную и отдельный шаблон страницы создавать"
Вы здесь ответили на вопросы, которые меня давно мучили. Я пришла тоже к выводу, что лучше краткие анонсы писать. Но пока не получается реализовать из-за отсутствия времени.
Практически с самого начала существования WordPress, разработчиками был продуман функционал, который позволял вывести на главной текст на вашу статью без дублирования контента.
Зайдите на страницу редактора в админ – панели WordPress. На странице, под самим редактором найдете вкладку «Цитата (Excerpt)». Вот она и предназначена для вывода анонса статьи на главной, в рубриках, архиве, поиске и т.д. При создании статьи используйте это поле для создания уникального анонса статьи, который будет мотивировать посетителя кликнуть по ссылке «Читать далее» и прочесть вашу статью.
Кроме исключения дублей у поля «Цитата», есть еще одна полезная особенность, этот текст вы можете оптимизировать под ключевые слова необходимые для Главной, Рубрики и т.д.
А ведь и правда! Почему я не знал про это ума не приложу, честное слово! Спасибо большое за такую подсказку, буду использовать именно этот метод!
Да, то что нужно! Thank you!
Единственное, что сейчас надо будет сперва во все записи блога добавить эти уникальные описания, а только потом в шаблоне менять the_content () на the_excerpt (), а то выходит не очень красиво. Ну, или как выход, в шаблоне прописать условие, при котором будет выводиться the_content () если поле "Цитата" не заполнено! Щас поколдую над этим!
У меня один вопрос. Если я слишком сильно перелинкую страницы, ничего плохого не будет? Разумеется, я текст не трогаю, просто вставляю ссылки в нужные слова с помощью SimpleTags (wordpress). Если с 1 страницы идёт 20 исходящих ссылок на другие страницы? Это плохо? И почему Терехов ставит ссылку на главную страницу, после каждой статьи?
Я думаю, не стоит этого делать. Я уже у кого-то в блоге выражал свое недовольство автоматизацией таких важных вещей. Насколько это плохо или хорошо сказать не могу, но злоупотреблять не стоит не в коем случае. Оптимальное количество ссылок 3-5. Но все зависит от самого сайта, если это блог, то полезно будет делать отсылки пользователя на материалы о которых вы упоминаете в посте, это то самое юзабилити. Если это коммерческий сайт с небольшим количеством страниц, то полезно будет небольшое количество ссылок.
Почему Терехов ставит ссылку на главную это у него надо спросить ;) Тут гораздо важнее другое, нельзя чтобы страница ссылалась сама на себя!
PS Даже внутренние ссылки должны быть разбавлены. То есть анкор лист конечной страницы не должен состоять из одного только слова/словосочетания. Смысл такой же как и при покупке внешних ссылок.
О том, что дубли страниц вредны я знал и раньше, но даже не догадывался, что и теги причастны в этом. И еще если кто не знает в CMS DLE есть поддержка мультикатегорий (возможность выбора нескольких категорий) обязательно отключайте ее, если не хотите чтоб контент дублировался.
Теги больше всего и причастны к размножению дублей. Отключение мультикатегорий не выход для некоторых проектов.
Думаю было бы полезным расписать тут как сформировать 304-й заголовок. Как узнать робот уже видел эту стр. в данном состоянии или нет? Хотя можно и нагуглить.
Вопрос вдогонку. Заголовок Last-Modified заменит 304-й?
Если вам действительно интересно как реализовывается данная технология, то советую прочитать:
http://written.ru/articles/technologies/site_building/if_modified_since
http://xpoint.ru/know-how/Articles/SlezhenieZaKontentom
Привет уважаемый Илаичь.
На блог попал случайно и после половины прочитанного поста, уверено внес твой блог в закладки.
Профессионально занимаюсь СЕО совсем недавно. Но есть пару продвигаемых проектов.
Вопрос вот в чем:
В посте активно обсуждается тема вреда анонса статьи(поста) первыми предложениями из самого поста. Ну и то что анонс должен быть уникален.
Как же ты оправдываешь тот факт что анонс данного поста, идентичен первому абзацу?
Я на самом деле прошу твоего объяснения, без сарказма.
Привет. Только я не "Илаичь", а АлаичЪ =)
>> Как же ты оправдываешь тот факт что анонс данного поста, идентичен первому абзацу?
Никак ;) В самом начале я честно признался: "я и сам грешу порой". Это меня не оправдывает, понимаю, я работаю над написанием информативных анонсов к постам. Мало того, вы могли бы заметить, что у меня не заполнены, например, description и keywords на большинстве страниц. И это тоже моя недоработка, но у меня особый подход к заполнению метаполей, их я заполняю только на основе анализа существующего спроса ;) Об этом и других секретах я поведаю в своих будущих постах.
Дико полезный для меня пост! спасибо большое! подписался на рассылку !
МЕГА полезная для меня статья. Огромное спасибо!!!
Вы писали: «Существование сайта на двух доменах с www и без (www.site.ru и site.ru). К счастью эта проблема легко решается с помощью 301 редиректа и файла .htaccess», но у меня что-то ничего не выходит...
Вот мой htaccess:
Подскажите, пожалуйста, что и как нужно заменить?
Добавлял до этого кода строчку «Redirect 301 site.ru www.site.ru» не помогло... ((
Вот так должно быть:
Для основного домена без www:
Для основного домена с www:
Не знаю, за что у вас отвечают последние 4 строчки, но первые 4 — это то, что вам надо, они сделают 301 редирект. Так же не знаю, какой вам вариант нужен, или с www на без www редирект, или наоборот, так что выбирайте нужный из предложенных.
Нужен без www.
Я просто слабо понимаю что нужно было изменить.
Всё получилось. Огромное вам спасибо!
ПС уже сами определают с www или без — в панели вебмастера.
Не будьте столь наивны, поисковики надо контролировать по максимуму.
Спасибо за статью. Редко встретишь сейчас такой блог, как у вас. У меня вопрос, правда косвенно касающийся анонсов, но всё же.
В DLE есть краткая новость. Каким образом наиболее оптимально с точки зрения SEO размещать ссылку из короткой новости на полную? В самом названии новости либо ниже ссылкой типа "Читать далее...". Просто прочитал в одном из блогов, что тег h1 (а именно он используется при составлении заголовков коротких новостей) не должен быть ссылкой.
Во-первых, вариант "Читать далее..." сразу отсекается, он не оптимален.
Во-вторых, надо соблюдать правило — "Только один заголовок H1 на странице". Так что все заголовки shortstory рекомендую заменить на H2, ну а их сделать ссылками.
Приветствую!
Спасибо за интересные статьи!
А вот скажите, плиз, как-то я у Вас пост читал, где вы указываете на тот факт, что картинки на сайте должны иметь title и alt, соответствующие, на сколько я понял, тематике сайта.
На моем сайте около 500 картинок (у меня магазин), название которых никак не связано с тематикой сайта. (например, 12345.jpg). Скажите, пожалуйста, будет ли разумным переименовывать картинки, дабы улучшить внутреннюю оптимизацию сайта и есть ли вероятность, что сайт сможет немного приподняться в глазах поисковиков, что скажется на его позициях по органической выдаче? Спасибо.
Скажем сперва о том, что alt, title и имя файла — это три разные вещи.
Наличие этих тегов (alt и title) и их содержание или вообще их отсутствие может сказаться только в ранжировании при поиске по картинкам. На органическую выдачу это не повлияет никак. А при поиске по картинкам стоит помнить, что Google не учитывает атрибут title и не ищет по нему, только alt, а Яндекс читает и alt и title и может искать по ним.
В общем и целом, нет никакого смысла менять имена файлов картинок или их атрибуты вручную, есть смысл только если это будет сделано автоматически.
Спасибо за быстрый ответ!
Вы имеете в виду, что не надо менять названия файлов. Надо прописать теги. Так?
Я имел ввиду то, что ничего не надо менять вручную, потому что затраченное время не окупится. Менять имеет смысл только в случае автоматизации процесса.
Но все же конкретно отвечу на ваш вопрос — да, менять названия файлов не надо; да, прописывать теги надо.
Спасибо, Саша!
Здравствуйте, АлаичЪ! Не нашёл у Вас отдельную статью про ЧПУ, и поэтому пишу сюда. В данный момент в разработке новый сайт для нашей компании, и передо мной встал вопрос. Оставить ли адреса внутренних страниц прежними (вида .html), или настроить 301-й редирект, а адреса сделать со слэшем на конце? В последнем случае уже купленные внешние ссылки потеряют смысл?
А какой вы видите в этом смысл? Что должно измениться при отсутствии .html на конце? Я никакого в этом смысла не виду совершенно. Так что бросьте эту глупую затею, оставьте как есть!
А что за директива Options +FollowSymLinks, упомянутая в статье? Она является обязательной? В оригинальном .htaccess она отсуствует. Также часто встречаю директиву Options +Indexes в .htaccess.
Может, кто-нибудь объяснит на пальцах, какая от них польза?
Options +Indexes в .htaccess разрешает просматривать листинг файлов внутри запрашиваемого каталога, если там нет индексного файла по умолчанию (например, index.html или index.php). Т.е., например, у вас есть на сервере папка /uploads/ и в ней лежат какие-то файлы, но в папке нет index.* файла. Если кто-то введет в браузере http://site.ru/uploads/ то он увидит все содержимое папки и сможет что-то оттуда скачать. Правило -Indexes наоборот запрещает просмотр листинга, и при попытке посмотреть папку будет выведено стандартное сообщение Forbidden, что значит доступ запрещен.
Про Options +FollowSymLinks в .htaccess я затрудняюсь доходчиво объяснить, так что загуглите, проявите самостоятельность :)
Здравствуйте Александр! Посоветуйте, пожалуйста, как мне быть в сложившейся ситуации... Я новичок и многое приходится изучать по опыту других, а своего пока недостаточно, поэтому возникают проблемы... Одна из них проявилась недавно. В результатах поиска Гугла появились дубли моих страниц, где вместо имени домена значится айпи моего сервера(( я так понимаю, что это мой косяк и заключается он в неправильных настройках сервера... можно было бы конечно решить эту проблему настройкой сервера, чтобы по айпи не переходить на сайт, но тогда, насколько я понимаю, потеряется все, что Гугл успел проиндексировать по айпишнику? так ведь? а настройка htaccess, чтобы по айпи редиректиться на домен, вроде как тоже не подходит, т.к. на этом же сервере хочу в дальнейшем разместить еще один сайт... в общем я в ступоре:( подскажите как мне лучше поступить? Заранее спасибо!
PS Забыл еще написать, что по айпи Гугл проиндексировал уже 43 тыс. страниц, против 12 тыс. по имени домена :(
Надо как раз такую проблему решать на уровне сервера. А именно на строить 301-редирект с ip на домен. Для этого обратитесь к хостеру, они помогут. У меня у самого подобная оплошность вышла, решал ее именно так.
Даже если будете на этот ip еще один сайт добавлять, все равно придется выбирать основной, т.к. по запросу к ip не могут показываться два сайта одновременно, то один.
Спасибо за ответ!!! Скажите, а посредством настройки .htaccess эту проблему решить не удастся?
Удастся, наверное, но правильным решением будет именно обращение к хостерам, как я писал выше.
Спасибо за статьи! Вопрос такой: Редирект в файле .htaccess ту что в корне сервера или в шаблоне редактировать?
И у меня в этом файле .htaccess в корне и в шаблоне много строчек почему то...
Мне нужно без www. Боюсь что либо удалить... да и со слэшем и без тоже открывает страницы, как мне быть в этом случае? Спасибо.
Надо редактировать тот .htaccess, который в корне сайта.
Ничего удалять не надо, а новые правила надо добавлять сразу после RewriteEngine On
Александр добрый день! Спасибо за статью — как по мне очень интересная и познавательная. Я новичек — потому многое еще нужно освоить. У меня вопрос к Вам. Выше вы вспоминали о канонизации url’ов (наличие на странице <link rel="canonical" href="http://site.ru" />). 1.Могли бы вы описать это для файла .htaccess. 2. Если все таки тегом выполнять это, то физически выполняется переход site.ru/index.php. в site.ru или же я этого не вижу, но это понятно поисковикам и они это учитывают
Я ничего не понял из вашего вопроса. Давайте на более простом языке.
Проще говоря, я хочу избавится от дублей главной страницы. Можно ли настроить переадресацию с помощью файла .htaccess. И как будет в таком случае выглядеть код?
Все возможно, и об этом очень подробно написано здесь — https://alaev.info/blog/post/4393
Спасибо!
Я почему то не как не могу настроить: код 200 вместо 404 ошибки, то есть при не правильном написания ссылки на сайт перенаправляет на пустую страницу. Кто может сказать в чем причина?
Александр, у меня вопрос есть по поводу https? В каких случаях нужно переезжать? Допустим, у меня на сайт секретной/приватной информации пользователей не хранится. Каких-то финансовых данных тем более. Читал, что Гугл прям строго к этому относится, что мол даже не обязательно, чтобы приватная информация хранилась на сайте. Правда ли это? И как к этому относится Яндекс?
Хотел еще спросить по поводу алгоритма mobile-friendly, он же только на мобильную выдачу влияет?
Хранится или нет информация, не важно. Если есть какие-то формы авторизации на сайте, это уже требует защиты, то есть https желателен. Если есть авторизация, значит и секретные данные (логин, пароль, почта) есть.
Понял, спасибо!
Хорошо пишете, жизненно. Все-таки, для того, чтобы делать действительно стоящий блог, нужно не только рассказывать о чем-то, но и предоставлять это в интересной форме:)