Большая часть советов по техническому SEO написана либо для разработчиков, либо ими же, из-за чего владелец бизнеса застревает между непониманием проблемы и невозможностью попросить её исправить. Вам не нужно писать код, чтобы поставить задачу тому, кто это делает, — нужно знать, как выглядят простыми словами те немногие проблемы, которые реально важны, и что должна делать исправленная версия.
Можно ли вообще найти сайт
Прежде всего поисковая система должна иметь возможность дойти и прочитать каждую страницу, которую вы хотите ранжировать. Простыми словами: нет ли файла, случайно блокирующего поисковики от определённых страниц (это случается чаще, чем должно бы, когда сайт переходит из тестовой среды в рабочую и настройку забывают переключить обратно), и есть ли карта сайта — простой список всех страниц — реально отправленная и поддерживаемая актуальной. Попросите разработчика подтвердить оба пункта напрямую, а не предполагайте, что всё в порядке; это самая распространённая техническая проблема, которая молча не даёт хорошему контенту вообще попасть в рассмотрение.
Достаточно ли быстро загружается сайт, чтобы удержать ожидающего
Скорость страницы — фактор ранжирования и, что важнее, фактор того, останется ли посетитель достаточно долго для конверсии. Вам не нужно понимать алгоритмы сжатия изображений, чтобы задать правильный вопрос: как сайт работает на смартфоне среднего класса при обычном соединении, а не на быстром офисном вайфае разработчика на новом ноутбуке. Просите результат реального теста скорости, а не заверение, что «всё нормально».
Есть ли у каждой страницы один чёткий адрес
Дублирующиеся или нечёткие адреса страниц — один и тот же контент, доступный по двум разным URL, или страница, меняющая адрес без перенаправления со старого, — путают поисковики насчёт того, какую версию ранжировать, и могут незаметно тратить впустую авторитет, накопленный страницей. Исправление, которое внедряет разработчик, техническое; то, о чём стоит просить, — нет. Спросите, есть ли у каждой важной страницы ровно один канонический адрес, и корректно ли перенаправляются старые адреса при переименовании или переносе страницы, вместо того чтобы просто ломаться.
Имеет ли смысл структура страницы без просмотра кода
Заголовки должны читаться как план — один главный заголовок, затем логичная последовательность подзаголовков — потому что такая структура помогает и читателям, и поисковикам понять, о чём страница на самом деле. Это можно проверить самостоятельно без каких-либо знаний кода: прочитайте только заголовки страницы сверху вниз и посмотрите, складываются ли они в разумный план содержания. Если нет, структура страницы нуждается в доработке, независимо от того, насколько чист код под капотом.
Безопасен ли сайт и удобен ли на мобильном
Сайт без защищённого соединения (значок замка в адресной строке браузера) и сайт, ломающийся или требующий масштабирования на экране телефона, оба создают трение, которое поисковики и посетители фиксируют одинаково — как причины не доверять странице или не оставаться на ней. Оба пункта быстро проверяются без технических знаний: посмотрите на адресную строку в поисках замка и откройте сайт на своём телефоне.
Постановка задачи разработчику по этому поводу
Ничто из перечисленного не требует от вас читать хоть строчку кода — требуется знать, какие вопросы отличают реальную техническую SEO-проблему от того, что просто звучит технически. Это чек-лист, по которому наша команда веб-разработки проходится при создании каждого сайта, и это хорошая отправная точка для любого разговора с разработчиком, независимо от того, делается ли работа внутри компании или отдаётся на аутсорс — дисциплина, входящая в более широкий подход из нашей схемы SEO-стратегии.
