Инструмент стоит в Google на позиции 1,8. Кликов нет.

У нас есть страница, которая чинит текст, набранный не в той раскладке: вставляешь rfr ltkf — получаешь «как дела».

За 28 дней по этому запросу: 69 показов, средняя позиция 1,8, один клик.

Сначала решили, что дело в позиции, и надо подниматься. Потом посмотрели соседние запросы:

ghbdtn! — позиция 1,0, ноль кликов
ghbdtn — 163 показа, позиция 5,3, ноль кликов

В Яндексе та же картина: 111 показов на позициях 7–8, ноль кликов.

Пошли смотреть выдачу руками. Google пишет сверху «Возможно, вы имели в виду: как дела» и разворачивает ответ ИИ. Задача решена до того, как человек дошёл до органики. Мы там третьи — и это не имеет значения.

Вывод, который дорого обошёлся: есть запросы, где клика не будет ни при какой позиции. Выше первой подняться некуда.

Проверили, во что это обходится в сумме. Страницы, где поисковик отвечает сам:

Калькулятор времени — 2 235 показов, 9 кликов
Конвертер регистров — 1 922 показа, 3 клика
Калькулятор возраста — 1 364 показа, 4 клика

Около 5 500 показов в месяц, которые не станут трафиком никогда.

И отдельно про chmod. Выпустили в сентябре, спрос был, ниша казалась свободной. Запрос chmod 600 — 325 показов, позиция 5,2, ноль кликов: Google показывает расшифровку прав прямо в выдаче. На самой странице 26 открытий и ноль использований — люди заходят посмотреть и уходят.

Инструмент прошёл все наши фильтры и оказался мёртвым.

Теперь перед тем, как писать ТЗ, вбиваем целевой запрос в Google и Яндекс. Если ответ уже в выдаче — идея отклоняется, какой бы ни была частотность.

Обратная сторона того же правила работает: «сколько дней до итогового сочинения» — CTR 33 % с позиции 1,4. Потому что эту дату поисковик наизусть не знает, а Новый год знает: «сколько дней до нового года» даёт ноль кликов.

Кликают там, где готового ответа нет.

Почему encodeURIComponent не кодирует ! ' ( ) *

Проверьте в консоли:

encodeURIComponent("a b!'()*")
→ a%20b!'()*

Пробел закодирован, а пять символов остались как есть. Это не баг, а дата.

Функция появилась в ECMAScript 3 в 1999 году и честно следовала тогдашнему стандарту адресов — RFC 2396. В нём ! ' ( ) * считались «безопасными» знаками, которые можно не трогать.

В 2005 году вышел RFC 3986, и эти пять знаков переехали в зарезервированные: у них появился служебный смысл в адресе. А encodeURIComponent остался прежним — менять поведение функции, на которую опирается весь веб, никто не стал.

Где это стреляет на практике.

— Подписи запросов. OAuth 1.0 и подпись AWS считают хэш от строго закодированной строки. Скобка, оставленная как есть, даёт другую подпись, и сервер отвечает 401 без объяснений.
— Markdown. Ссылка вида [текст](https://…?q=(1)) обрывается на первой закрывающей скобке.
— Сравнение адресов. Один и тот же параметр, закодированный в браузере и на бэкенде, получается двумя разными строками.

Как починить: догнать вручную после штатной функции.

encodeURIComponent(s).replace(/[!'()*]/g, c => "%" + c.charCodeAt(0).toString(16).toUpperCase())

Бонус, чтобы стало совсем весело: URLSearchParams кодирует ту же строку по третьим правилам — формам HTML. Пробел там становится +, скобки и апостроф кодируются, а звёздочка снова нет:

q=a+b%21%27%28%29*

Три функции в одном браузере — три разных ответа на вопрос «как закодировать строку». Перед тем как сравнивать или подписывать адреса, стоит знать, какая из них работала на каждой стороне.

P.S. Пока писал заметку, заметил, что наш кодировщик URL про эти пять символов предупреждал, но кодировал их так же, как браузер. Теперь там есть режимы «Строго по RFC 3986» и «Как форма (URLSearchParams)», а таблица рядом показывает, как каждый из них кодирует эти пять символов и пробел: https://bringer.ru/tools/url?type=rfc3986&utm_source=telegram