Технічне SEO — це практика забезпечення того, щоб пошукові системи могли знаходити, сканувати, відображати, розуміти та індексувати вміст веб-сайту, а також щоб базова доставка не створювала перешкод для ранжування. Воно відрізняється від роботи з контентом та авторитетом тим, що стосується інфраструктури сайту, а не того, що він говорить або хто на нього посилається. Його функція значною мірою сприяє: технічний стан рідко сам по собі призводить до рейтингу, але технічні збої надійно запобігають цьому.
Фундаментальні вимоги не надто привабливі. Сторінки повинні повертати правильні коди стану, бути доступними через посилання, що скануються, і не блокуватися випадково директивами у файлі robots або метаінструкціями. Канонічні теги повинні об'єднувати дублікати версій одного й того ж контенту, а не фрагментувати сигнали через варіації параметрів, ідентифікатори сеансів та невідповідності протоколів чи піддоменів. Перенаправлення повинні вирішуватися за один крок, а не через ланцюжки, які втрачають сигнал і марнують ресурси сканування. Кожна з цих проблем є радше дефектом, ніж оптимізацією, і кожна з них є поширеною на сайтах, які розвивалися протягом багатьох років.
Рендеринг став тією сферою, де сучасні сайти найчастіше зазнають невдачі. Контент, зібраний у браузері за допомогою JavaScript, не гарантовано буде проіндексований так само, як розмітка, що надається сервером, оскільки рендеринг відбувається на окремому етапі з обмеженими ресурсами. Сайти, створені як односторінкові додатки без рендерингу на стороні сервера або попереднього рендерингу, часто виявляють, що значна частина їхнього контенту або не індексується, або індексується без важливих елементів. Єдиною надійною перевіркою є перевірка того, що насправді бачить пошукова система, а не того, що відображає браузер.
Структура сайту та внутрішнє посилання знаходяться на межі технічної роботи та роботи з контентом. Те, як сторінки посилаються одна на одну, визначає як те, що буде знайдено, так і те, як розподіляється авторитет на сайті, а структурні проблеми призводять до появи сторінок-сиріт, доступних лише через карту сайту, глибоких сторінок, для доступу до яких потрібно багато кліків, а важливих шаблонів, які майже не отримують внутрішніх посилань. Ці проблеми невидимі під час аудиту на рівні сторінок, і для їх виявлення потрібно сканувати весь сайт.
Масштаб визначає, які проблеми мають значення. На невеликому сайті ефективність сканування практично не має значення, а зусилля витрачаються на контент і структуру. На великому каталожному сайті з фасетною навігацією ті самі технічні рішення визначають, чи витрачатимуть пошукові системи свій ліміт на сканування на цінні сторінки, чи на мільйони комбінацій фільтрів, які ніколи не повинні були бути доступними для сканування. Визначення категорії, до якої належить сайт, запобігає як нехтуванню, так і протилежній помилці застосування рішень корпоративного масштабу до сайту, який їх не потребує.
Пріоритезація – це та область, де технічні аудити найчастіше не приносять користі, оскільки автоматизовані інструменти генерують сотні висновків без зважування за наслідками. Відсутній метаописи на сторінці, яку ніхто не відвідує, зображення без альтернативного тексту в нижньому колонтитулі та директива шаблону, яка блокує індексацію цілої категорії товарів, – все це відображається як проблеми, і лише один з них щось коштує. Сортування висновків за кількістю сторінок, на які вони впливають, обсягом трафіку, який представляють ці сторінки, та тим, чи перешкоджає проблема індексації, а не просто відхиляється від найкращої практики, перетворює лякаючий список на короткий набір елементів, вартий часу на розробку.
Оскільки ці проблеми виникають у шаблонах, конфігурації сервера та архітектурі застосунків, а не в редакційному контролі, їх усунення зазвичай вимагає інженерних, а не маркетингових можливостей. На практиці маркетингові послуги взаємодія визначає та пріоритезує проблеми, впровадження відбувається за розробка продуктуа компоненти рендерингу та швидкості безпосередньо перетинаються з веб-продуктивність робота, тому ці дві дисципліни є найефективнішими, коли вони мають спільний портфель робіт, а не конкурують за один і той самий час інженерії.