Внедрение SEO в среде разработки

1. Сверху вниз и полная ответственность компании
2. Сделать SEO функцией продукта
3. Эффективное определение размеров задач
4. Эффективно расставляя приоритеты задач
5. Создание системы SEO Pull
6. Параллельно и не в последовательности
7. Решение технической задолженности

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

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

Сверху вниз и полная ответственность компании

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

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

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

Это часто означает, что SEO должен использовать два подхода.

1. Они должны выполняться как восходящая деятельность, пытаясь проникнуть через менеджеров проектов или инженеров. Это может быть функцией одолжения и дружбы. Это работает, но скорость выполнения медленная.
2. Другой подход заключается в том, что SEO должен постоянно доводить привратников до продукта / веб-сайта. Это битва, когда задачи ставятся в очередь каждый месяц или квартал. В эту битву вовлечены заинтересованные стороны вокруг компании, которые также пытаются получить доступ к ограниченным ресурсам.

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

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

Сделать SEO функцией продукта

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

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

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

Эффективное определение размеров задач

Многие оптимизаторы передают задачи в отчете без эффективного списка задач. Более сложные консультанты SEO могут создать список задач. Еще более изощренные оптимизаторы будут отдавать приоритет этому списку.

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

Это ограничено, потому что:

1. Побочный проект многих SEO-специалистов обычно заключается в упрощении настроек сайта.
2. Не учитывает устаревшие настройки и ограничения разработки конкретного сайта

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

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

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

Эффективно расставляя приоритеты задач

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

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

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

Создание системы SEO Pull

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

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

Параллельно и не в последовательности

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

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

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

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

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

Решение технической задолженности

Одним из главных препятствий на пути развития SEO является технический долг ,

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

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

Разработка без учета последствий для SEO порождает технический долг, который придется погасить, чтобы правильно выполнить SEO. Возможно, был отправлен код, который по своей сути не был ошибочным с точки зрения быстрой и грязной перспективы (хотя на самом деле это может быть проблемой), но потому, что SEO не рассматривался. Из-за этого задачи, которые должны быть по своей природе простыми, не являются. Чтобы выполнить задачу, разработка, возможно, должна сначала погасить этот долг.

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

Похожие

Комментарии