7 технических SEO побед для веб-разработчиков

1. 1) IP-обнаружение / перенаправление
2. 2) Скорость сайта
3. 3) 301 и 302 перенаправления
4. 4) HTTP-заголовки
5. 5) Доступ к гусеничным машинам
6. 6) Javascript
7. 7) Flash
8. Заключение

Как SEO-агентство, мы часто работаем с внешними веб-разработчиками. Они могут работать внутри компании для клиента или другого агентства, такого как мы, но сосредоточены на веб-дизайне и разработке. Уровень знаний SEO сильно варьируется от агентства к агентству, и иногда нас привлекают к обучению разработчиков по тем частям SEO, на которые они часто влияют, не зная об этом. Ниже я расскажу о семи элементах SEO, о которых все разработчики должны знать.

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

• Заголовок тег
• URL-адрес
• Заголовки
• Основной текст и т. Д.

Техническое SEO включает в себя элементы страницы, которые пользователь не может увидеть, не глядя на исходный код. Они будут включать такие элементы, как -

• Обнаружение / Перенаправление IP
• Скорость сайта
• 301 и 302 перенаправления
• Заголовки HTTP
• Crawler Access
• Javascript
• вспышка

Вот семь вещей, которые я расскажу ниже.

1) IP-обнаружение / перенаправление

Недавно я столкнулся с этой проблемой из первых рук в клиентском проекте, и она была очень, очень грязной. Для тех из вас, кто не знаком с этим, обнаружение и перенаправление IP-адресов включает определение IP-адреса пользователя на вашем сайте, а затем показ его содержимого (или перенаправление на новый URL-адрес) в зависимости от их местоположения. Например, если кто-то зашел на сайт www.domain.ru и его IP-адрес указал, что он находится во Франции, вы можете перенаправить его на сайт www.domain.fr, который содержит французский контент.

Для пользователя это на самом деле не страшная вещь. Он не является надежным, так как обнаружение IP-адресов не всегда точно на 100%, но обычно это означает, что вы можете показывать пользователям контент, который больше соответствует их местоположению и языку. Звучит хорошо и имеет смысл.

Однако для поисковых роботов это может быть очень хлопотно. Главным образом потому, что они обычно сканируют IP-адреса из США, это означает, что они могут никогда не увидеть часть вашего контента. Мой недавний клиент перенаправлял на основе IP и в конечном итоге перенаправлял поисковые системы на их домен .us. Это означало, что поисковые системы не видели других стран, на которые они ориентированы, включая Великобританию и Австралию.

Джон Му поддержал это на Тема для веб-мастеров :

Да, многие сканеры поисковых систем в настоящее время базируются в США ...... Я полагаю, вы можете на что-то намечь на автоматическое перенаправление пользователей в зависимости от их местоположения - об этом мы поговорим позже в серии постов блога но, вообще говоря, да, это может вызвать проблемы у поисковых роботов, и поэтому мы настоятельно рекомендуем либо не делать этого, либо ограничивать его определенным набором страниц (скажем, домашней страницей), в то же время позволяя сканерам получать доступ ко всем остальной части контента на сайтах.

Хотя разработчики (и некоторые оптимизаторы) часто думают, что нет ничего плохого в обнаружении и перенаправлении IP, вы можете увидеть проблемы, которые это может вызвать. Поэтому вам нужно поговорить с ними и сообщить им о влиянии, которое это может оказать на сканирование и индексацию сайта. Бывают случаи, когда обнаружение IP имеет смысл, но я бы посоветовал с большой осторожностью и убедиться, что вы случайно не мешаете поисковым системам видеть ваши страницы.

2) Скорость сайта

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

С точки зрения SEO, вам нужно заботиться о скорости сайта, потому что Google одержим скоростью , Я недавно читал В плексе который дает представление о первых днях существования Google и описывает случаи, когда Ларри Пейдж измерял скорость продуктов в своей голове и был точным в течение десятых долей секунды. Каждый продукт, о котором он отзывается, должен быть очень быстрым, чтобы у него была возможность двигаться вперед. Google понимает, насколько пользователи заботятся о скорости, поэтому вы тоже должны.

Если вы боретесь с разработчиками здесь, перейдите к webpagetest.org и сравните ваш клиентский сайт с некоторыми конкурентами. Затем отправьте разработчикам копию видео:

Зачастую это может подтолкнуть их к тому, чтобы воспринимать скорость сайта более серьезно. С точки зрения специфики, посмотрите на это эпическое руководство от Крейга о Скорость сайта и SEO получить советы и инструменты для повышения скорости сайта.

3) 301 и 302 перенаправления

Извините, но многие разработчики (и SEO) ошибаются. Прямо сейчас вам нужно реализовать только два типа перенаправления - 301 или 302. Вот и все. Нет 303, 307 или что-то еще. Есть два основных способа, которыми это может быть испорчено, первый способ, о котором я собираюсь поговорить, - это использование неправильного типа перенаправления.

Смешение 301 и 302

Чтобы дать некоторый фон и контекст. 301 редирект обычно используется в SEO по одной из следующих причин:

• Страница куда-то переместилась или была удалена, поэтому вы хотите перенаправить пользователей и поисковые системы на соответствующую новую страницу
• Каким-то образом вы создали дублированный контент и хотите удалить их из индекса Google, перенаправив их в основную каноническую версию

Перенаправление 301 обычно передает почти весь сок ссылок и эквити на URL, на который он указывает. Так что это может быть хорошим способом придать некоторую силу различным страницам и убедиться, что вы не потеряете ни одного ссылочного сока на страницах 404 и т. Д. Вот почему это так полезно для SEO.

Несмотря на то, что мы не дружественны к SEO (мы расскажем почему), есть некоторые подлинные причины для SEO, использующего редирект 302 -

• Страница может быть просто временно недоступна, например, товар, который устарел на веб-сайте электронной коммерции, который скоро появится на складе
• Вы можете протестировать переход на новый домен, чтобы получить отзывы клиентов, но не хотите портить историю и рейтинг старых доменов.

Переадресация 302 работает здесь, потому что вы уверены, что движение не является постоянным. Из-за этого Google не будет передавать сок ссылок через перенаправление и не удалит старый URL из своего индекса. Это те же самые причины, по которым смешивание с 301-м и 302-м может повредить вашей производительности SEO.

Общая причина, по которой некоторые оптимизаторы и разработчики ошибаются, заключается в том, что для пользователя они не замечают никакой разницы. Они все равно будут перенаправлены. Но поисковые системы заметят разницу. Я видел пример того, как клиент переместил весь свой сайт на новый домен, и все перенаправления были 302. Это плохо, потому что -

• Сок ссылок не будет передаваться на новые URL-адреса, что означает, что они вряд ли будут иметь хорошие позиции в краткосрочной и, возможно, долгосрочной перспективе.
• Google не избавится от старых URL-адресов из своего индекса, что означает, что вы можете одновременно проиндексировать несколько URL-адресов со старого и нового доменов

Таким образом, вы можете оказаться в ситуации, когда ваш новый сайт индексируется, но практически не имеет силы и поэтому не имеет рейтинга. Я видел случаи серьезного снижения трафика из-за неправильной реализации перенаправлений, подобных этой. Следующее изображение предоставлено Elliance хорошо показывает различия:

Перенаправление всех URL-адресов обратно на домашнюю страницу

Это еще одна проблема, с которой я сталкивался не раз. Google рекомендует, чтобы при реализации перенаправлений вы делали это один за другим. Например -

Вы должны перенаправить:

http://www.old-site.com/product-name-12345 to http://www.new-site.com/product-name-12345

http://www.old-site.com/product-name-10000 to http://www.new-site.com/product-name-10000

То, что некоторые люди делают неправильно, это перенаправление -

http://www.old-site.com/product-name-12345 to http://www.new-site.com

http://www.old-site.com/product-name-10000 to http://www.new-site.com

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

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

4) HTTP-заголовки

Скорее всего, многие разработчики будут знать, что означают эти коды заголовков HTTP, но применительно к SEO они могут не знать, какой эффект они имеют или как к ним относятся поисковые системы. Есть много-много кодов состояния там (вы знали, что код состояния 418 означает, что я чайник ?!), но как SEO, вы, безусловно, должны хорошо знать следующие HTTP-заголовки и знать, какое влияние они могут оказать. Для отличного визуального способа понять коды заголовков, ребята в SEOgadget сделал инфографику, нажмите на изображение ниже, чтобы открыть полную инфографику:

Чтобы найти код заголовка HTTP страницы, вы можете использовать инструмент, такой как Веб-сниффер , SEOmoz Toolbar или в масштабе с использованием Кричащая лягушка ,

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

301 Постоянно перемещено - это было описано более подробно выше, но в итоге означает, что страница постоянно перемещена в другое место. И пользователи, и поисковые системы перенаправляются, и большая часть ссылочного сока передается через перенаправление, старая страница удаляется из индекса.

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

Страница 404 не найдена - вы, вероятно, знакомы с этим. Для пользователей и поисковых систем это означает, что запрашиваемая страница не может быть загружена. Если проиндексированная страница внезапно становится страницей 404, со временем поисковые системы перестанут ее ранжировать (по моему опыту и тестам в любом случае).

Быстрый sidenote здесь из опыта . Несколько раз я сталкивался с ситуацией, когда пользователю отображается страница, которая выглядит как 404, однако, если вы посмотрите на заголовок HTTP, вместо этого будет показан код 200 Success. Это не хорошо, и Google классифицировал их как мягкие 404. Причина, по которой они не очень хороши, заключается в том, что вам трудно обнаружить эти ошибки с помощью журналов сервера или Инструментов Google для веб-мастеров. Хотя Google пытается их обнаружить Лучше не полагаться на Google, чтобы сделать это для вас.

Рекомендуется убедиться, что страница 404 действительно возвращает заголовок HTTP 404. Кстати, вы должны проверить Дистиллированная страница 404 который построил наш стажер Андрей.

Страница 410 постоянно не найдена - я не уверен, почему я бы использовал это, а не перенаправление 301, но могут быть некоторые хорошие применения, и их стоит знать как Google относится к этому ,

500 Internal Server Error - это общая страница ошибок, которая не очень полезна, поскольку обычно не дает подробных сведений о причинах возникновения ошибки. Вы должны обязательно постараться свести эти ошибки к абсолютному минимуму.

503 Сервис недоступен - хотя этот код не следует часто использовать, полезно знать, если ваш сайт временно не работает и скоро вернется. Например, если вы перезапускаете сайт или новый дизайн, вам, возможно, придется сделать это, переведя сайт в автономный режим. Лучше вернуть 503, чтобы поисковые системы знали, что вернутся позже. Джон Му также подтвердил Позиция Google по этому вопросу :

« Оптимально, все такие URL-адреса« сервер не работает »должен возвращать код результата 503. (Служба недоступна). Это также предотвращает сканирование поисковых систем и индексацию страниц ошибок :-). Иногда я удивляюсь, сколько крупных сайтов забывают» сделать это ... "

5) Доступ к гусеничным машинам

Для меня ограничение доступа сканеров и оптимизация разрешений на сканирование - это упущенная часть SEO. Вероятно, потому что это может быть немного трудно осуществить, и это не совсем точная наука. Чтобы понять это и оптимизировать его, вы должны сначала освоиться с концепцией разрешения сканирования. Рэнд написал отличный пост на SEOmoz об этом после некоторых комментарии от Мэтта Каттса по теме.

На базовом уровне Google будет сканировать примерно на основе PageRank как Мэтт Каттс объяснил ранее :

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

Обучение здесь состоит в том, чтобы убедиться, что вы не тратите свое пособие на сканирование на страницах, которые вас не интересуют. Постарайтесь убедиться, что когда Google сканирует ваш сайт, они проводят время на ваших важных страницах. Есть несколько способов сделать это, просто имея хорошая архитектура сайта это довольно мощный способ сам по себе:

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

Robots.txt - это первый файл, который будет запрашивать поисковая система при сканировании вашего сайта. В этом файле они попытаются определить, существуют ли какие-либо области вашего сайта или конкретные URL-адреса, которые они не должны сканировать. Есть некоторые споры относительно того, насколько строго поисковые системы подчиняются тому, что содержится в файле robots.txt, но я все еще думаю, что вы должны его использовать и в большинстве случаев чувствует его надежность. Файл robots.txt обычно выглядит примерно так: Amazon.co.uk :

Или если вы кого-то вроде Риши это может выглядеть как это :

Если вы не знакомы с тем, как написать файл robots.txt, лучше всего освоиться с ним, прежде чем говорить с разработчиками по этой теме. Читать это руководство от Google и тестируйте на своих сайтах.

Здесь нужно внимательно посмотреть на свой сайт и решить, какие разделы вы не хотите, чтобы поисковые системы сканировали. Здесь следует соблюдать осторожность, поскольку вы не хотите блокировать страницы случайно.

Rel = Canonical - я бы никогда не рекомендовал использовать тег rel = canonical на новом сайте. Некоторые могут не согласиться со мной, но я считаю rel = canonical последней инстанцией в решении проблем архитектуры сайта. Если вы можете избежать этих проблем в первую очередь, сделайте это. Не думайте, что rel = canonical - это инструмент, который поможет вам.

Основной причиной этого является то, что этот тег не является строгим правилом. Поисковые системы не должны обращать на это внимание и могут изменить свое отношение к нему в любое время. Актуальные доказательства предполагает, что поисковые системы замечают это и используют его довольно сильно. Но я бы все же посоветовал не полагаться на это в долгосрочной перспективе.

Стоит информировать ваших разработчиков об этом теге и убедиться, что они знают, как его использовать. Это может быть большой помощью в решении проблем с дублирующимся содержимым, но в то же время может легко пойти не так, если вы не используете его правильно. Большим преимуществом использования rel = canonical с точки зрения разработки является то, что (теоретически) это легче реализовать, чем перенаправление 301:

Взгляните на это руководство от Линдсей закончил на SEOmoz для более полного руководства по rel = canonical, а также моего собственного поста на выбирая между rel = canonical и 301 redirect ,

6) Javascript

Javascript может быть отличной вещью, он может добавить отличную функциональность на ваш сайт и улучшить пользовательский опыт. Тем не менее, поисковые системы борются с пониманием Javascript. Они все время становятся лучше и активно пытаются запустить Javascript, чтобы получить доступ к большему количеству контента. Из-за этого есть две ключевые вещи, которые вы должны помнить -

Не размещайте ценный контент в javascript - вы хотите убедиться, что поисковые системы могут читать весь контент, который вы произвели. Не тратьте все свои усилия впустую, помещая свой контент в javascript, к которому поисковые системы не могут добраться.

Обычный способ, которым я видел это в прошлом, - это переход между вкладками на странице продукта электронной коммерции. Когда пользователь нажимает на вкладку, такую ​​как «Дополнительная информация», контент загружается с использованием JavaScript. Это хорошо для пользователя, но поисковые системы могут не найти этот дополнительный контент. В то время как они могут быть в состоянии добраться до него, лучше всего быть в безопасности и загружать контент на страницу без необходимости выполнения какого-либо дополнительного javascript.

Что-то, что я определенно защищаю, это использование Jquery, где это возможно. Jquery может сделать элементы страницы такими же красивыми, как javascript, но в целом оптимизирован для SEO. Когда вы просматриваете источник в элементе, созданном с помощью Jquery, вы обычно можете видеть контент, который отлично подходит для поисковых систем.

Не размещайте контент или ссылки в JavaScript, чтобы преднамеренно скрывать его от Google - это была старая тактика, которую SEO-специалисты использовали по разным причинам. Это было в тот день, когда поисковые системы искренне изо всех сил пытались увидеть, что находится внутри JavaScript. Так что это может быть использовано для старых практик, таких как лепка PageRank или просто вопиющее сокрытие контента.

7) Flash

Большинство из вас должно знать это, но для полноты изложения давайте кратко поговорим о флэш-памяти. Как и в случае с javascript, поисковые системы пытаются понять флеш-элементы страницы. Несмотря на различные улучшения поисковые системы не так продвинуты, как в javascript. тем не мение Google может извлечь некоторый текст и URL которые находятся внутри flash-элементов, но не все поисковые системы могут это сделать.

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

Заключение

Я думаю, что есть несколько ключевых выводов:

• Люблю своего разработчика! Они могут сделать для вас отличную работу и не стоит недооценивать свою способность делать классные вещи, чтобы помочь SEO
• Не думайте, что они знают все - будьте готовы помочь им понять последствия их работы для SEO
• Отдайте должное разработчикам, если они внесут изменения в сайт, и это поможет результатам, скажите им

Похожие

Комментарии