1. Шкала разработчиков Андерсона-Алдерсона
2. Стратегические и исполнительные результаты
3. Заставить разработчиков делать все зависит от масштаба
4. Распространенные задачи внедрения SEO по шкале Андерсона-Алдерсона
5. Позвольте мне познакомить вас с бегунами задач
6. Общие SEO рекомендации, которые вы можете использовать для выполнения задач
7. Минификация кода
8. Другие способы заставить разработчиков реализовать рекомендации SEO
9. Делай, что можешь, чтобы сбалансировать весы

Самая сложная задача в SEO - не обновлять алгоритм. У него нет доступа к корпоративным инструментам. Дело даже не в том, есть ли у вас опыт, чтобы определить, куда направить свои усилия.

Нет, самая сложная проблема в SEO - заставить разработчиков действительно выполнять рекомендации.

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

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

Шкала разработчиков Андерсона-Алдерсона

Сначала давайте познакомимся с игроками.

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

Вот как его босс описывает его в фильме: «У вас проблема, мистер Андерсон. Вы думаете, что вы особенный. Вы верите, что каким-то образом правила к вам не относятся ».

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

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

На другом конце спектра у вас Эллиот Алдерсон.

Для тех из вас, кто не смотрит «Мистер Робот: «Олдерсон - это тот тип людей, который придет в офис в 2 часа ночи, чтобы починить вещи, когда они сломаются, и даже пойти на то, чтобы в тот же вечер запрыгнуть на реактивном самолете компании, чтобы разобраться в последнем кризисе сети.

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

Этот тип разработчика внимателен и будет вызывать вас на своих бс, если вы не знаете, о чем говорите. Так что не приходите с рекомендациями по асинхронному JavaScript, не понимая, как он работает.

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

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

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

К сожалению, я не помню имя этого парня - но он легенда.

Стратегические и исполнительные результаты

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

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

Кроме того, я часто нахожу, что нет никакого дополнительного документа к документу стратегии, который помог бы клиенту и его команде разработчиков фактически выполнить эти рекомендации. Это очень представлено как: «Вот проблема, вы должны это исправить. Удачи."

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

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

В качестве примера, для списка метаописаний, которые являются слишком длинными, мы включим эти URL, их метаописания и их длину.

Большая проблема заключается в конечных результатах, которые представляются в большей степени на рассмотрение и утверждение клиента, чем на реализацию разработчиками. У нас есть результат под названием «Рекомендации по содержанию», в котором мы берем содержимое клиента и помещаем его в модель в Word и отслеживаем изменения для обновления основной копии, метаданных и внутренней структуры ссылок.

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

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

Это означает, что для реализации рекомендаций, содержащихся в этом документе Word, требуется разработчик, который находится на стороне Алдерсона в масштабе Андерсона-Алдерсона.

С другой стороны, если мы рассмотрим клиентскую версию документа «Рекомендации по содержанию» вместе с клиентом, а затем поместим полученные изменения в электронную таблицу, разработчик может написать сценарий, который просматривает каждую страницу и вносит предлагаемые изменения. , Подробнее об этом позже.

Это поместило бы реализацию ближе к концу Андерсона шкалы Андерсона-Алдерсона.

Заставить разработчиков делать все зависит от масштаба

Вообще говоря, с рекомендациями SEO всегда нужно помнить о масштабе. Иногда, однако, нет способа масштабировать то, что вы пытаетесь достичь.

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

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

Распространенные задачи внедрения SEO по шкале Андерсона-Алдерсона

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

• Обновление метаданных. Этот процесс обычно довольно утомителен. Если копия не будет подготовлена ​​там, где ее легко извлечь и поместить на страницу, для этого потребуется постраничное обновление в CMS или извлечение документа, который мы подготовили, и размещение его в базе данных.
• Обновление основного текста или встроенных структурированных данных. Подобно обновлению метаданных, это также довольно утомительно и требует постраничного обновления. В тех случаях, когда мы говорим об обновлении кода schema.org, который интегрирован в контент, а не помещается в <head> с помощью JSON-LD, для разработчика это кошмар.
• Обновление внутренней структуры ссылок. Это потенциально может быть сделано программно, но только если отношения будут эффективно идентифицированы. В большинстве случаев оптимизаторы представляют рекомендации на постраничном уровне, и разработчик не может эффективно масштабировать эти усилия.
• Оптимизация кода для повышения производительности. Разработчики, как правило, настолько одержимы скоростью, что сокращают слово «производительность» до «перф», чтобы его можно было сказать быстрее. Однако у них есть отвращение к критическим рекомендациям по пути рендеринга, которые исходят из Google PageSpeed ​​Insights. Из рекомендаций SEO, которые я даю, я придерживаюсь самых простых, потому что это область, в которой разработчики часто защищаются. Совет для профессионалов: используйте временную шкалу DevTools и сведения о производительности сети, чтобы получить их на борту с оптимизацией скорости страниц. Они склонны лучше реагировать на это.
• Создание XML-карт сайта по таксономии сайта. Существует множество инструментов, которые поддерживают разработку XML-карт сайтов, но разработчики, как правило, просто позволяют этим разрываться. Это приводит к XML-картам сайтов, таким как «sitemap14.xml», а не к тем, которые отражают осмысленную сегментацию после таксономии сайта и поэтому полезны для SEO для управления индексацией.
  
• Генерация снимков HTML. Исторически некоторые одностраничные приложения JavaScript, такие как Angular 1.x, испытывали трудности при индексации. Но разработчики слышали, что Google сканирует безголовые браузеры и они знают, что Angular - это фреймворк, разработанный Google, поэтому они иногда не обязаны учитывать его недостатки.
  
• Реализация перенаправлений. Перенаправления могут быть довольно легко масштабированы, так как они часто выполняются на уровне конфигурации сервера и записываются с помощью ряда правил сопоставления с шаблоном. По моему опыту, крайне редко разработчик не выполняет их.
• Исправление неправильных перенаправлений. И наоборот, когда дело доходит до переключения перенаправлений с 302-х на 301-е, я наблюдаю откат от команд разработчиков. На самом деле мне однажды сказали, что коммутатор может взломать сайт.
  

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

Позвольте мне познакомить вас с бегунами задач

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

Задачи, такие как Глоток а также хрюкать позволяют разработчикам автоматизировать ряд задач каждый раз, когда они запускают новый код. Более свежее дополнение, Webpack , также имеет возможность запуска задач. Это в значительной степени не позволяет разработчикам выполнять обычные или утомительные процессы, которые может выполнять сама машина, и многие веб-проекты используют их для этой цели.

Не вдаваясь в специфику самих инструментов, сообщества выросли вокруг Grunt, Gulp и Webpack; В результате появилась серия плагинов. Конечно, пользовательские модули могут быть написаны для каждого, но чем меньше работы, которую вы создаете для разработчиков, тем лучше.

Возвращаясь к идее обновления метаданных в масштабе, есть плагин для Grunt, который называется Грунт-мета-первенствует , который позволяет вам предоставить XLSX-файл с изменениями заголовков страниц, метаописаний и метаданных открытого графика.

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

Разработчик может эффективно изменить этот плагин, чтобы редактировать базу данных, а не редактировать файлы, или ваш файл Excel может быть преобразован в файл SQL довольно быстро и запущен как ОБНОВЛЕНИЕ всей базы данных.

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

Общие SEO рекомендации, которые вы можете использовать для выполнения задач

Grunt, Gulp и Webpack имеют серию плагинов, предлагающих настраиваемую функциональность, которая позволяет разработчику быстро выполнять утомительные задачи SEO. Ниже приведен (не исчерпывающий) список задач SEO и некоторые плагины, которые можно использовать для них:

Минификация кода

Сжатие изображения

Автоматическое обновление XML-файлов Sitemap.

Проверка AMP

AMP создание

Обновление метатегов

Генерация снимков HTML

Информация о скорости страницы

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

За пределами Grunt, Gulp, Webpack, разработчик может использовать WebCheck автоматизировать ряд других проверок для нескольких других проблем SEO, как выделено в этот поток StackOverflow , Идея состоит в том, что разработчик может написать тесты сборки, которые не позволят им развернуть новый сайт, если не все проверено. Вы можете найти больше плагинов, выполнив поиск npmjs.com ,

Другие способы заставить разработчиков реализовать рекомендации SEO

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

• Поймите технический стек и сформулируйте свои рекомендации в нем. Рассмотрим сценарий, в котором вы предложили 301 переадресацию для вашего клиента. Оказывается, они используют Nginx вместо Apache. Вы это знаете Nginx не использует файл .htaccess ? Если вы этого не сделаете, вы можете предложить разместить перенаправления 301 там, и разработчик может игнорировать все остальное, что вы говорите. Такие инструменты, как BuiltWith.com, дадут вам общее определение используемых технологий. Лучшая идея - взглянуть на заголовки HTTP в Chrome DevTools. Независимо от того, что вы делаете, вы должны потратить время, чтобы получить подробное понимание стека технологий, когда ваше взаимодействие начинается.
• Детализируйте детали в своих рекомендациях. Если от разработчика требуется поиск решения в другом месте за пределами вашего документа, у вас гораздо меньше шансов заставить его выполнить рекомендацию. Вместо этого объясните контекст и реализацию в соответствии со своими результатами, а не связывайтесь с объяснениями других людей. Хотя разработчики, как правило, никогда не доверяют приложениям других людей, некоторые разработчики склонны уважать ваши выводы DevTools больше, чем многие инструменты SEO. Я предполагаю, что это связано с сочетанием мельчайших деталей и того инструмента, который они используют каждый день.
• Дайте одно решение, но знайте другие. Часто проблема SEO может быть решена несколькими способами, и может быть трудно бороться с желанием заполнить ваши документы SEO, исчерпывающе выделяя все доступные варианты. Сражайтесь сложнее и предоставьте только одно возможное решение. Устранение необходимости принимать решение приведет к тому, что разработчики будут более склонны к реализации. Однако, если команда разработчиков отклоняет одно решение, подготовьте другое решение. Например, если они не могут переместить сайт из поддоменов в подкаталоги, предложите обратный прокси-сервер.
• Бизнес-кейсы и расстановка приоритетов. Это, пожалуй, самая ценная вещь, которую вы можете сделать, чтобы получить поддержку в организации и вверх по ней, что приводит к дополнительному давлению на команду разработчиков, чтобы добиться своей цели. Применение значения доллара к стоимости ваших реализаций делает идею действия более убедительной. Приоритизация рекомендаций через этот объектив также помогает. Конечно, мы все знаем, что никто не может по- настоящему предсказать размер возможности, поэтому сделайте это с помощью какой-то понятной методологии, чтобы вы могли добиться успеха.
• Понять их методологию развития. Будь то ловкий, водопад, XP, какая-то комбинация или что-то новое, что делает только одна команда в мире, постарайтесь понять это. Слушай, я не могу стоять, когда кто-то подбегает ко мне за столом, пока я в глубокой концентрации, чтобы задать мне вопрос, который они могли бы прогуглить. Точно так же разработчики ненавидят, когда SEO приходят к ним и говорят им, что им нужно нарушать то, как они обычно работают, чтобы соответствовать рекомендациям SEO. Поэтому, если эта команда работает в спринте, узнайте у своего мастера Scrum, когда заканчивается цикл спринта и когда лучше всего выполнить ваши требования в последующем спринте. Вам также следует работать непосредственно с этим человеком, чтобы превратить рекомендации в истории для включения в их решение по управлению проектами, чтобы команда могла придерживаться стандартного рабочего процесса, а не переводить свою работу в то, как они работают.
• Развивайте отношения с командой разработчиков. Это кажется очевидным, но мягкое умение дружить с командой разработчиков будет иметь большое значение в том, что у них больше шансов работать с вами. В большинстве случаев отношения между SEO и техническими командами очень транзакционные, поэтому они узнают о вас только тогда, когда вы чего-то хотите. Вместо этого, если вы потратите время на то, чтобы по-настоящему заинтересоваться этими людьми, вы обнаружите, что они просто люди, которые пытаются сделать все возможное, как вы и я.
• Обращение к их личным интересам. К предыдущему пункту есть возможность согласовать то, что вы пытаетесь сделать, с тем, что они пытаются сделать. Например, у одного из наших недавних клиентов была команда разработчиков, стремящаяся оптимизировать скорость страниц, но они смотрели более пристально на внутренние показатели, а не на внешние, на которые смотрит Google. Было гораздо легче получить согласие на этот набор рекомендаций, чем на любые другие, потому что он поддерживал мандат, который ему дал его начальник. Поэтому для меня было более ценно сосредоточиться на этом при разговоре с ним, чем на таких вещах, как перенаправления. Хотя для этого требовалась некоторая переориентация того, что я считал наиболее ценными задачами, это помогло немного сместить акцент на усилия по увеличению скорости страницы, чтобы обеспечить приоритетность выделенных мною элементов. Вы теряете некоторые, вы выигрываете некоторые - до тех пор, пока результат будет доходом!

Делай, что можешь, чтобы сбалансировать весы

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

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

Мнения, выраженные в этой статье, принадлежат автору гостя и не обязательно относятся к Search Engine Land. Штатные авторы перечислены Вот ,

Об авторе