Сейчас продвигаю очередной сайт медицинского центра в Майами и снова поражаюсь, до какой степени можно "убить" WordPress.
Сайт еле грузится, внутри — три (!) разных визуальных конструктора, десятки лишних плагинов, половина из которых не только бесполезна, но ещё и конфликтует друг с другом.
Такое ощущение, что сайт собирали методом: поставим всё подряд — авось заработает.
И самое интересное — это далеко не первый проект из США, в котором сталкиваюсь с подобным хаосом.
То ли у нас разработчики сильнее и привыкли работать аккуратнее, то ли в США одни по**исты.
И да, заказчики в этом смысле одинаковы везде: кнопки пусть светятся, тексты поправьте, баннер побольше — а всё, что реально влияет на результат, потом, не сейчас.
В итоге SEO, скорость загрузки, индексация, безопасность — всё страдает.
Сайт еле грузится, внутри — три (!) разных визуальных конструктора, десятки лишних плагинов, половина из которых не только бесполезна, но ещё и конфликтует друг с другом.
Такое ощущение, что сайт собирали методом: поставим всё подряд — авось заработает.
И самое интересное — это далеко не первый проект из США, в котором сталкиваюсь с подобным хаосом.
То ли у нас разработчики сильнее и привыкли работать аккуратнее, то ли в США одни по**исты.
И да, заказчики в этом смысле одинаковы везде: кнопки пусть светятся, тексты поправьте, баннер побольше — а всё, что реально влияет на результат, потом, не сейчас.
В итоге SEO, скорость загрузки, индексация, безопасность — всё страдает.
⚡️ Как за 10 секунд найти «узкое место» в работе процесса на сервере (Linux)
Раз уж вчера начал говорить про тормозные сайты и оптимизацию, то давайте немного углубимся в эту тему.
Если сервер начал тормозить, а вы не хотите копаться часами — вот два простых инструмента, которые сразу покажут, где проблема.
Когда сервер начинает «тупить», нет смысла смотреть PID всех процессов подряд. Проверять нужно только те, которые реально могут нагружать систему.
✅nginx стоит анализировать тогда, когда страницы начинают отвечать медленно, появляются 502/504 ошибки или воркеры оказываются забиты под завязку. Однако важно помнить: сам по себе nginx редко является причиной проблем — он чаще "пострадавший", а не виновник.
✅php-fpm или php нужно проверять, если сайт зависает, процессор загружен под 100%, страницы генерируются слишком долго или воркеры начинают "залипать".
✅mysql или mariadb становятся главным подозреваемым, когда запросы к базе данных выполняются медленно, появляются блокировки таблиц, а выборки занимают секунды вместо миллисекунд. Во многих случаях именно база — источник узкого места на сервере.
✅java, node или python-приложение следует анализировать, если само приложение активно потребляет CPU или память, особенно при росте нагрузки или очередей запросов.
✅redis или postgres нужно проверять тогда, когда задержки связаны с кэшем или базой данных: например, ключевые операции начинают выполняться медленно, или система зависает из-за блокировок.
Как посмотреть, какие процессы запущены?
Лично я чаще всего использую команду top — она показывает список процессов в реальном времени, автоматически обновляется каждые несколько секунд и сразу видно, кто именно нагружает процессор. Вы можете скачать из репозиториев htop — улучшенная версия top (удобнее, с цветами).
Чтобы узнать PID нужного сервиса, можно использовать команду pidof, например:
Эта команда, к примеру, вернёт идентификатор процесса, если nginx запущен в системе.
Итак, начнем:
✅ Показывает, что процесс делает на CPU
✅ Определяет, есть ли проблемы с кешем
✅ Отлично помогает понять, «алгоритм тупит» или «железо не справляется
Команда pidstat показывает в реальном времени, что именно происходит внутри процесса:
• Загрузка CPU по каждому потоку — помогает понять, забито ли одно ядро или нагрузка распределена равномерно.
• Ожидания по I/O — если процесс «висит», это может быть не вычисление, а медленный диск или очередь на чтение/запись.
• Своп — если начала использоваться swap-память, значит оперативка закончилась, и система резко начинает тормозить.
• Блокировки потоков — бывает, что CPU почти не загружен, а программа всё равно «тормозит» — причина в том, что поток ждёт освобождения ресурса, а не считает.
📌 Когда использовать:
✅ Непонятно, почему nginx/php/java «грузит проц»
✅ Процесс «жрёт CPU», но запросы обрабатываются медленно
✅ Подозреваете I/O
✅ Нужно быстро сузить круг проблем, не подключая профайлеров
📌 Главное правило
nginx, сам по себе почти никогда не причина тормозов.
MySQL — почти всегда.
PHP — в 50% случаев.
Так что диагностировать всех сразу не надо — сначала ищем жрущий процесс через top, а потом именно его можно препарировать.
Раз уж вчера начал говорить про тормозные сайты и оптимизацию, то давайте немного углубимся в эту тему.
Если сервер начал тормозить, а вы не хотите копаться часами — вот два простых инструмента, которые сразу покажут, где проблема.
Когда сервер начинает «тупить», нет смысла смотреть PID всех процессов подряд. Проверять нужно только те, которые реально могут нагружать систему.
✅nginx стоит анализировать тогда, когда страницы начинают отвечать медленно, появляются 502/504 ошибки или воркеры оказываются забиты под завязку. Однако важно помнить: сам по себе nginx редко является причиной проблем — он чаще "пострадавший", а не виновник.
✅php-fpm или php нужно проверять, если сайт зависает, процессор загружен под 100%, страницы генерируются слишком долго или воркеры начинают "залипать".
✅mysql или mariadb становятся главным подозреваемым, когда запросы к базе данных выполняются медленно, появляются блокировки таблиц, а выборки занимают секунды вместо миллисекунд. Во многих случаях именно база — источник узкого места на сервере.
✅java, node или python-приложение следует анализировать, если само приложение активно потребляет CPU или память, особенно при росте нагрузки или очередей запросов.
✅redis или postgres нужно проверять тогда, когда задержки связаны с кэшем или базой данных: например, ключевые операции начинают выполняться медленно, или система зависает из-за блокировок.
Как посмотреть, какие процессы запущены?
Лично я чаще всего использую команду top — она показывает список процессов в реальном времени, автоматически обновляется каждые несколько секунд и сразу видно, кто именно нагружает процессор. Вы можете скачать из репозиториев htop — улучшенная версия top (удобнее, с цветами).
Чтобы узнать PID нужного сервиса, можно использовать команду pidof, например:
pidof nginx
Эта команда, к примеру, вернёт идентификатор процесса, если nginx запущен в системе.
Итак, начнем:
sudo perf stat -d -p $PID -- sleep 10
✅ Показывает, что процесс делает на CPU
✅ Определяет, есть ли проблемы с кешем
✅ Отлично помогает понять, «алгоритм тупит» или «железо не справляется
pidstat -wstu -p $PID 1
Команда pidstat показывает в реальном времени, что именно происходит внутри процесса:
• Загрузка CPU по каждому потоку — помогает понять, забито ли одно ядро или нагрузка распределена равномерно.
• Ожидания по I/O — если процесс «висит», это может быть не вычисление, а медленный диск или очередь на чтение/запись.
• Своп — если начала использоваться swap-память, значит оперативка закончилась, и система резко начинает тормозить.
• Блокировки потоков — бывает, что CPU почти не загружен, а программа всё равно «тормозит» — причина в том, что поток ждёт освобождения ресурса, а не считает.
📌 Когда использовать:
✅ Непонятно, почему nginx/php/java «грузит проц»
✅ Процесс «жрёт CPU», но запросы обрабатываются медленно
✅ Подозреваете I/O
✅ Нужно быстро сузить круг проблем, не подключая профайлеров
📌 Главное правило
nginx, сам по себе почти никогда не причина тормозов.
MySQL — почти всегда.
PHP — в 50% случаев.
Так что диагностировать всех сразу не надо — сначала ищем жрущий процесс через top, а потом именно его можно препарировать.
👍1
Ошибки разработчиков сайтов в эпоху AI.
Будет полезно разработчикам, SEO-специалистам и всем, кто пилит сайты на React, Next.js, Vue, Nuxt и прочие SPA-фреймворки.
Самая частая проблема — владельцы сайтов блокируют не тех ботов. В попытке защититься от паразитных они закрывают доступ и тем, кто как раз формирует базу знаний для нейросетей. В итоге ИИ просто не видит сайт. Контент есть, но не для моделей — значит, вас нигде не процитируют.
Вторая ошибка — всё рендерится через JavaScript. На экране у пользователя текст появляется, а вот робот его не видит. Для ИИ это пустая страница, даже если вы написали идеальную статью.
Третья — спрятанный контент. Авторизация, «доступ только после входа» — для нейросетей это просто закрытая дверь. А если бот не может прочитать страницу, он не включит её в свои ответы. И да, это значит, что ваш бренд не будет существовать в ИИ-поиск
Сегодня SEO — это не просто "собрать семантику и пофиксить метатеги". Главный враг сайта — не Google, а плохие UI-решения на JavaScript. Если сайт работает через React/SPA, но сделан без понимания, как это влияет на индексацию — он уже мёртв в поиске.
Google умеет рендерить JavaScript. Но не всегда и не полностью. И уж тем более не умеют это делать нейросети (ChatGPT, Perplexity и т.д.).
Полностью на CSR — плохо для SEO.
Полностью на SSR — тяжело и дорого в поддержке.
Поэтому нормальный подход сейчас — гибрид:
-важные страницы (категории, карточки, блоги, услуги) отдаются как SSR,
-динамические штуки (фильтры, корзина, личный кабинет) — через CSR.
Как исправить (кратко):
1.Только <a href=""> для внутренних ссылок — никаких onClick-роутов.
2.SSR или pre-render для важного контента и навигации.
3.Link-компоненты должны рендерить полноценную ссылку, не div.
4.Проверять сайт глазами бота через curl: curl -A "Googlebot" https://site.com
5. Отдельная перелинковка в HTML, а не только в interface.
Самое важное:
Если сайт доступен только через JS-роутинг — для Google он не связан внутри.
Для поисковика он выглядит как набор разрозненных страниц, а не структура.
Будет полезно разработчикам, SEO-специалистам и всем, кто пилит сайты на React, Next.js, Vue, Nuxt и прочие SPA-фреймворки.
Самая частая проблема — владельцы сайтов блокируют не тех ботов. В попытке защититься от паразитных они закрывают доступ и тем, кто как раз формирует базу знаний для нейросетей. В итоге ИИ просто не видит сайт. Контент есть, но не для моделей — значит, вас нигде не процитируют.
Вторая ошибка — всё рендерится через JavaScript. На экране у пользователя текст появляется, а вот робот его не видит. Для ИИ это пустая страница, даже если вы написали идеальную статью.
Третья — спрятанный контент. Авторизация, «доступ только после входа» — для нейросетей это просто закрытая дверь. А если бот не может прочитать страницу, он не включит её в свои ответы. И да, это значит, что ваш бренд не будет существовать в ИИ-поиск
Сегодня SEO — это не просто "собрать семантику и пофиксить метатеги". Главный враг сайта — не Google, а плохие UI-решения на JavaScript. Если сайт работает через React/SPA, но сделан без понимания, как это влияет на индексацию — он уже мёртв в поиске.
Google умеет рендерить JavaScript. Но не всегда и не полностью. И уж тем более не умеют это делать нейросети (ChatGPT, Perplexity и т.д.).
Полностью на CSR — плохо для SEO.
Полностью на SSR — тяжело и дорого в поддержке.
Поэтому нормальный подход сейчас — гибрид:
-важные страницы (категории, карточки, блоги, услуги) отдаются как SSR,
-динамические штуки (фильтры, корзина, личный кабинет) — через CSR.
Как исправить (кратко):
1.Только <a href=""> для внутренних ссылок — никаких onClick-роутов.
2.SSR или pre-render для важного контента и навигации.
3.Link-компоненты должны рендерить полноценную ссылку, не div.
4.Проверять сайт глазами бота через curl: curl -A "Googlebot" https://site.com
5. Отдельная перелинковка в HTML, а не только в interface.
Самое важное:
Если сайт доступен только через JS-роутинг — для Google он не связан внутри.
Для поисковика он выглядит как набор разрозненных страниц, а не структура.
Многие компании и владельцы сайтов до сих пор мыслят по-старому: "Нанимаем по дешевке SEO-шника, пусть пишет статьи, выведет наш сайт в топ — и всё будет хорошо". Но так больше не работает. В 2025 году люди принимают решения совсем по-другому.
Они больше верят ролику в TikTok, чем статье на экспертном сайте. Перед покупкой идут читать не блог на сайте, а обсуждения в соц. сетях.
А нейросети вроде ChatGPT вообще не упоминают сайт, если не смогли получить данные из-за блокировок, скриптов или закрытого контента.
И если у бренда нет живого присутствия в соцсетях — он сразу выглядит подозрительно. Сейчас недостаточно просто попасть в ТОП. Этого уже мало. Людям важно не только найти сайт — им нужно захотеть выбрать именно вас. Бренд должен быть узнаваемым, живым, с понятной репутацией.
Сегодня побеждает не тот, кто выше в поиске, а тот, кому верят.
Они больше верят ролику в TikTok, чем статье на экспертном сайте. Перед покупкой идут читать не блог на сайте, а обсуждения в соц. сетях.
А нейросети вроде ChatGPT вообще не упоминают сайт, если не смогли получить данные из-за блокировок, скриптов или закрытого контента.
И если у бренда нет живого присутствия в соцсетях — он сразу выглядит подозрительно. Сейчас недостаточно просто попасть в ТОП. Этого уже мало. Людям важно не только найти сайт — им нужно захотеть выбрать именно вас. Бренд должен быть узнаваемым, живым, с понятной репутацией.
Сегодня побеждает не тот, кто выше в поиске, а тот, кому верят.
Сегодня уже недостаточно просто «сделать SEO по чеклисту» и ждать роста. Алгоритмы стали умнее и теперь смотрят не на то, насколько красиво вы вписали ключевые слова в текст, а на то, живой ли у вас бренд вообще. И вот самое интересное — поисковые системы и нейросети всё больше ведут себя как люди. Они обращают внимание не только на «плотность ключей», а на то, есть ли у вас реальная жизнь за пределами сайта. Это и есть настоящие EEAT факторы.
Им важно, кто вас упоминает и в каком контексте. Есть ли брендовые запросы, то есть действительно ли люди ищут именно вас, а не просто «стоматолог рядом». Считаются отзывы — не только на вашем сайте, а в открытых сервисах, где вас сложно подделать. Смотрят на активность: есть ли соцсети, живое общение, упоминания на форумах, кто-то реально обсуждает компанию или всё мёртво.
И да — это значит, что даже для Google уже важно, не просто что вы пишете, а кто вы и как с вами взаимодействуют пользователи. Боты стали думать ближе к тому, как думает человек. А значит, и бизнесам пора перестать быть пустыми сайтами.
Им важно, кто вас упоминает и в каком контексте. Есть ли брендовые запросы, то есть действительно ли люди ищут именно вас, а не просто «стоматолог рядом». Считаются отзывы — не только на вашем сайте, а в открытых сервисах, где вас сложно подделать. Смотрят на активность: есть ли соцсети, живое общение, упоминания на форумах, кто-то реально обсуждает компанию или всё мёртво.
И да — это значит, что даже для Google уже важно, не просто что вы пишете, а кто вы и как с вами взаимодействуют пользователи. Боты стали думать ближе к тому, как думает человек. А значит, и бизнесам пора перестать быть пустыми сайтами.
Три часа ночи. Мне не спится, и я решил поковыряться в настройках телефона. Открыл список приложений и удивился. Обычный файловый менеджер, с функциями как у стандартного проводника, занимает почти 400 мегабайт. Простая программа для заметок, какие в институте раньше писали на C++, — больше 300. А, ведь раньше программы с гораздо большим функционалом не превышали пары мегабайт.
Разработчики, кажется, совсем перестали думать о том, как оптимизировать свои приложения.
Та же история со многими сайтами: их нагружают анимацией и картинками, но не следят за тем, как это грузится и работает. Увидеть траффик по 200-300 мб при загрузке главной страницы, хотя там нет ничего особенного, уже далеко не редкость.
CMS, визуальные редакторы, готовые библиотеки - отучили нас думать. А, что..... Пусть код грязный, зато быстро.
"Неограниченные" ресурсы придают уверенности и шепчут на ушко: Видишь, у тебя быстро работает. У других значит тоже не будет проблем.
Если у вас быстрый интернет, вы можете не замечать проблем. Сайт открывается — и хорошо. Но представьте человека, допустим, строителя Васю.
Он сидит в помещении, где связь слабая, хочет зайти на сайт, что-то заказать. А вместо сайта — лишь белый экран, который не грузится уже десять секунд. Он, скорее всего, просто уйдет.
Совсем уйдет, а вы потеряете клиента. Возможно, постоянного...
Поэтому быстрая загрузка страницы — это очень важно. И дело не в том, что это фактор ранжирования.
Это вопрос простого уважения к людям и их времени. И вашей конверсии их в лояльных клиентов.
Даже самая лучшая реклама и обещание золотых гор не смогут удержать пользователя, если сайт не откроется в первые пару секунд.
Разработчики, кажется, совсем перестали думать о том, как оптимизировать свои приложения.
Та же история со многими сайтами: их нагружают анимацией и картинками, но не следят за тем, как это грузится и работает. Увидеть траффик по 200-300 мб при загрузке главной страницы, хотя там нет ничего особенного, уже далеко не редкость.
CMS, визуальные редакторы, готовые библиотеки - отучили нас думать. А, что..... Пусть код грязный, зато быстро.
"Неограниченные" ресурсы придают уверенности и шепчут на ушко: Видишь, у тебя быстро работает. У других значит тоже не будет проблем.
Если у вас быстрый интернет, вы можете не замечать проблем. Сайт открывается — и хорошо. Но представьте человека, допустим, строителя Васю.
Он сидит в помещении, где связь слабая, хочет зайти на сайт, что-то заказать. А вместо сайта — лишь белый экран, который не грузится уже десять секунд. Он, скорее всего, просто уйдет.
Совсем уйдет, а вы потеряете клиента. Возможно, постоянного...
Поэтому быстрая загрузка страницы — это очень важно. И дело не в том, что это фактор ранжирования.
Это вопрос простого уважения к людям и их времени. И вашей конверсии их в лояльных клиентов.
Даже самая лучшая реклама и обещание золотых гор не смогут удержать пользователя, если сайт не откроется в первые пару секунд.
Стратегия "давайте напишем 100 статей и всё само вырастет" умерла. Людей больше не интересуют одинаковые тексты вроде "10 советов, как выбрать стоматолога в Майами". Таких статей — сотни, и они никому не нужны.
Пользователи больше не верят безликим SEO-текстам, где одни и те же фразы крутятся по кругу. Им нужен живой опыт, эмоции, история, узнаваемый голос. Они хотят видеть, кто стоит за контентом, а не просто набор слов под ключевые запросы.
✅Текст без личности просто шум.
✅Текст без доверия воспринимается как спам.
✅Текст без бренда превращается в мусор для ИИ.
И вот что интересно: как только появляется бренд, всё меняется. SEO снова начинает работать. Люди начинают делиться, возвращаться, запоминать. Алгоритмы тоже реагируют — потому что видят интерес, упоминания, поведение.
Самое важное правило: "Не важно, сколько страниц вы написали. Важно, сколько из них живут и работают сегодня."
SEO 2015: публикуем как можно больше
SEO 2025: управляем тем, что уже опубликовано
Большинство сайтов теряют трафик не потому, что "Google ужесточил ранжирование", а потому что контент тупо стареет и гниёт.
Да, это реальная проблема — называется content decay. Это когда материалы, которые раньше давали трафик, тихо перестают работать. Не за день, а постепенно: меньше показов, меньше переходов, меньше доверия.
Пользователи больше не верят безликим SEO-текстам, где одни и те же фразы крутятся по кругу. Им нужен живой опыт, эмоции, история, узнаваемый голос. Они хотят видеть, кто стоит за контентом, а не просто набор слов под ключевые запросы.
✅Текст без личности просто шум.
✅Текст без доверия воспринимается как спам.
✅Текст без бренда превращается в мусор для ИИ.
И вот что интересно: как только появляется бренд, всё меняется. SEO снова начинает работать. Люди начинают делиться, возвращаться, запоминать. Алгоритмы тоже реагируют — потому что видят интерес, упоминания, поведение.
Самое важное правило: "Не важно, сколько страниц вы написали. Важно, сколько из них живут и работают сегодня."
SEO 2015: публикуем как можно больше
SEO 2025: управляем тем, что уже опубликовано
Большинство сайтов теряют трафик не потому, что "Google ужесточил ранжирование", а потому что контент тупо стареет и гниёт.
Да, это реальная проблема — называется content decay. Это когда материалы, которые раньше давали трафик, тихо перестают работать. Не за день, а постепенно: меньше показов, меньше переходов, меньше доверия.
Сайт Rostics так намекает на остроту? Или я что-то не понимаю😂 Ещё и меню сломанное...
😁2
Давайте честно: если кто-то сегодня обещает вам мгновенные результаты в GEO-продвижении — он просто пиз... приукрашивает. Эта технология ещё слишком молодая по сравнению с классическим SEO.
Она только формируется: развивается, меняется, обрастает новыми алгоритмами. Поэтому называть себя "суперэкспертом" в области, которая ещё даже не устоялась, — ну… слишком по-цыгански, смело.
При этом сами принципы видимости в AI-поиске остаются прежними:
нужно технически привести сайт в порядок, создавать узкие, полезные, решающие конкретные задачи материалы, работать над цифровым PR и укреплять ссылочный профиль.
Она только формируется: развивается, меняется, обрастает новыми алгоритмами. Поэтому называть себя "суперэкспертом" в области, которая ещё даже не устоялась, — ну… слишком по-цыгански, смело.
При этом сами принципы видимости в AI-поиске остаются прежними:
нужно технически привести сайт в порядок, создавать узкие, полезные, решающие конкретные задачи материалы, работать над цифровым PR и укреплять ссылочный профиль.
По сути, PageRank рассчитывается как вес страницы, разделённый на процентную релевантность ссылки по отношению к теме, на которую она ведёт.
Здесь важно понимать: дело не в количестве ссылок, а в их ценности. Иногда десять правильно подобранных ссылок дадут больше эффекта, чем тысяча случайных бэклинков.
Одна ссылка с главной страницы, к примеру, BBC может стоить миллион ссылок с обычных сайтов - и я не преувеличиваю, это суть работы алгоритма. То есть, вместо бесполезных ссылок по типу 1000 за 500 рублей, лучше доплатить и взять одну качественную тематическую.
Здесь важно понимать: дело не в количестве ссылок, а в их ценности. Иногда десять правильно подобранных ссылок дадут больше эффекта, чем тысяча случайных бэклинков.
Одна ссылка с главной страницы, к примеру, BBC может стоить миллион ссылок с обычных сайтов - и я не преувеличиваю, это суть работы алгоритма. То есть, вместо бесполезных ссылок по типу 1000 за 500 рублей, лучше доплатить и взять одну качественную тематическую.
Честно говоря, меня удивило, сколько обращений по плагину WB2WP посыпалось в последнее время. Поэтому я решил всё-таки продолжить его развитие.
В ближайшее время выложу скрипт, который подтягивает цены с клиентского сайта Wildberries и работает в связке с плагином без привязки к API. Следом в работе — обратная выгрузка: передача данных из WordPress на Wildberries. На третьем месте в очереди — поддержка вариативных товаров.
Изначально я делал плагин под свой магазин и даже не задумался об одежде, обуви и других категориях — у меня совсем другой ассортимент.
Дальше посмотрим, как пойдёт. Планов много, а вот времени, как всегда, непростительно мало…
В ближайшее время выложу скрипт, который подтягивает цены с клиентского сайта Wildberries и работает в связке с плагином без привязки к API. Следом в работе — обратная выгрузка: передача данных из WordPress на Wildberries. На третьем месте в очереди — поддержка вариативных товаров.
Изначально я делал плагин под свой магазин и даже не задумался об одежде, обуви и других категориях — у меня совсем другой ассортимент.
Дальше посмотрим, как пойдёт. Планов много, а вот времени, как всегда, непростительно мало…
🔥1
Если хочешь подняться в локальном рейтинге по услуге в Google, начни с Google Business Profile.
Это одна из самых важных вещей.
Обнови профиль: поставь правильную основную категорию, добавь услуги и напиши нормальное описание, где будет фраза вроде “physical therapy in Miami”.
Это помогает Google сразу понять, чем ты занимаешься и в каком городе работаешь.
Проработай отзывы — особенно полезно, если в отзывах упомянуты город и нужная услуга.
Google такие вещи быстро подхватывает. После этого сделай на сайте отдельную страницу под запрос “physical therapy in Miami”.
На ней должны быть чёткое описание, контактные данные, адрес и фотографии. Обязательно добавь раздел FAQ, но не придумывай вопросы сам — ищи популярные. Такие страницы хорошо работают в локальном поиске и часто поднимаются в топ.
Проверь, чтобы название, адрес и телефон совпадали на всех площадках: Yelp, Healthgrades, ZocDoc и других. Если где-то данные отличаются, Google может путаться.
Как-то был клиент: вроде и с отзывами у него всё гладко, и карточка оформлена хорошо, но до топа он всё равно не дотягивал. Через аудит в Semrush мы посмотрели его присутствие в каталогах — на половине площадок были указаны левые или устаревшие номера и адреса. После того как всё исправили, пошёл рост. Смешно, но многие даже не думают это проверять.
И самое простое, что реально работает, — фото. Загружай новые снимки клиники, сотрудников и процесса работы. На продвижении был суши-ресторан, который за счёт только фото попал в локальный блок с картой.
Это БАЗА. Тут нечего придумывать и изобретать велосипед.
Это одна из самых важных вещей.
Обнови профиль: поставь правильную основную категорию, добавь услуги и напиши нормальное описание, где будет фраза вроде “physical therapy in Miami”.
Это помогает Google сразу понять, чем ты занимаешься и в каком городе работаешь.
Проработай отзывы — особенно полезно, если в отзывах упомянуты город и нужная услуга.
Google такие вещи быстро подхватывает. После этого сделай на сайте отдельную страницу под запрос “physical therapy in Miami”.
На ней должны быть чёткое описание, контактные данные, адрес и фотографии. Обязательно добавь раздел FAQ, но не придумывай вопросы сам — ищи популярные. Такие страницы хорошо работают в локальном поиске и часто поднимаются в топ.
Проверь, чтобы название, адрес и телефон совпадали на всех площадках: Yelp, Healthgrades, ZocDoc и других. Если где-то данные отличаются, Google может путаться.
Как-то был клиент: вроде и с отзывами у него всё гладко, и карточка оформлена хорошо, но до топа он всё равно не дотягивал. Через аудит в Semrush мы посмотрели его присутствие в каталогах — на половине площадок были указаны левые или устаревшие номера и адреса. После того как всё исправили, пошёл рост. Смешно, но многие даже не думают это проверять.
И самое простое, что реально работает, — фото. Загружай новые снимки клиники, сотрудников и процесса работы. На продвижении был суши-ресторан, который за счёт только фото попал в локальный блок с картой.
Это БАЗА. Тут нечего придумывать и изобретать велосипед.
https://dzen.ru/a/aMPABt2MtlmyZIlS
Мне кажется, получился действительно хороший и нестандартный кейс по внешнему трафику для маркетплейсов. Проект сам по себе не сложный, а результат вышел лучше чем думали и стабильным.
Мне кажется, получился действительно хороший и нестандартный кейс по внешнему трафику для маркетплейсов. Проект сам по себе не сложный, а результат вышел лучше чем думали и стабильным.
Дзен | Статьи
Продвижение бренда на Wildberries через создание Q&A сервиса по использованию материалов.
Статья автора «IT DevOps Web SEO от Алексея» в Дзене ✍: Категория «товары для мастеров красоты» перегрета. Карточки похожи, УТП часто формальны.
Типичный понедельник — это когда те самые люди, что в пятницу вечером нервно писали “срочно надо к понедельнику!”, сообщают: “Ну… мы тут всё переосмыслили”. И всё, что было "срочно", внезапно никому не нужно.
Уже какое-то время мне всё чаще попадается информация про Angie — в статьях, обсуждениях, примерах конфигураций. Это форк nginx, который развивают ребята из бывшей core-команды.
Angie во многом совместим с nginx, но у него изначально упор на современные сценарии: микросервисы, API, WebSockets и т.п.
Я смотрел на него скорее из любопытства… пока не столкнулся с задачей, где разница становится очень заметной.
Допустим, у вас есть такой сценарий:
/api/users → сервис №1
/api/orders → сервис №2
/api/admin → отдельный сервис + авторизация
На бумаге всё звучит просто. Но если попытаться собрать это на nginx, начинается хорошо знакомый квест:
—куча location-блоков
—переменные, которые нужно тащить между блоками
—поддержка Upgrade для WebSocket’ов
—отдельная логика для разных upstream’ов
—ручная сборка хедеров
Через пару итераций конфиг превращается в слоёный пирог, где каждый новый маршрут — маленькая архитектурная боль.
Работает, но выглядит всё это так, будто сервер просит пощады.
🚀 А вот как ведёт себя Angie
Такой сценарий можно разложить спокойно и без танцев с бубном: разнести сервисы, использовать отдельные upstream-блоки, health-checks и при этом не городить монстра из конфигов — за счёт более современной логики и нормального проектирования.
То есть ты решаешь ту же задачу, но:
✅ структура чище
✅ логика понятнее
✅ риск ошибиться ниже
✅ расширять конфиг проще
Давайте посмотрим на прикрепленную картинкой часть конфига:
1. health_check: в Angie можно указывать health_check прямо в upstream. Это даёт оперативное исключение упавших бэкендов из пула без сторонних инструментов.
2. proxy_upgrade on — упрощает настройку WebSocket-проxies (вместо пары proxy_set_header Upgrade и Connection "upgrade").
И самое приятное — всё выглядит так красиво, как будто так и должно работать изначально, без тех костылей, которые тянет за собой nginx.
Если проект растёт, появляются сервисы, маршруты, отдельные API-ветки и требуются health-checks — nginx начинает скрипеть.
Angie во многом совместим с nginx, но у него изначально упор на современные сценарии: микросервисы, API, WebSockets и т.п.
Я смотрел на него скорее из любопытства… пока не столкнулся с задачей, где разница становится очень заметной.
Допустим, у вас есть такой сценарий:
/api/users → сервис №1
/api/orders → сервис №2
/api/admin → отдельный сервис + авторизация
На бумаге всё звучит просто. Но если попытаться собрать это на nginx, начинается хорошо знакомый квест:
—куча location-блоков
—переменные, которые нужно тащить между блоками
—поддержка Upgrade для WebSocket’ов
—отдельная логика для разных upstream’ов
—ручная сборка хедеров
Через пару итераций конфиг превращается в слоёный пирог, где каждый новый маршрут — маленькая архитектурная боль.
Работает, но выглядит всё это так, будто сервер просит пощады.
🚀 А вот как ведёт себя Angie
Такой сценарий можно разложить спокойно и без танцев с бубном: разнести сервисы, использовать отдельные upstream-блоки, health-checks и при этом не городить монстра из конфигов — за счёт более современной логики и нормального проектирования.
То есть ты решаешь ту же задачу, но:
✅ структура чище
✅ логика понятнее
✅ риск ошибиться ниже
✅ расширять конфиг проще
Давайте посмотрим на прикрепленную картинкой часть конфига:
1. health_check: в Angie можно указывать health_check прямо в upstream. Это даёт оперативное исключение упавших бэкендов из пула без сторонних инструментов.
2. proxy_upgrade on — упрощает настройку WebSocket-проxies (вместо пары proxy_set_header Upgrade и Connection "upgrade").
И самое приятное — всё выглядит так красиво, как будто так и должно работать изначально, без тех костылей, которые тянет за собой nginx.
Если проект растёт, появляются сервисы, маршруты, отдельные API-ветки и требуются health-checks — nginx начинает скрипеть.
Главное в LLM SEO — понимать намерения пользователя. Создавайте такой контент, который точно отвечает на конкретные вопросы вашей аудитории.
Делайте информацию чёткой, структурированной, легко читаемой. Пишите в разговорном, естественном стиле — так, чтобы текст действительно было приятно воспринимать.
Такой подход помогает языковым моделям лучше понимать ваш материал и выше ранжировать страницы.
FAQ, блоки ответов, вопросы в естественной формулировке — начинайте с главного.
Сразу давайте чёткий ответ, а затем добавляйте связанные вопросы, примеры и пояснения.
Опирайтесь на надёжные источники, приводите ключевые факты в виде списков или таблиц, добавляйте доказательства и контекст.
Оптимизируйте текст под разговорные запросы, а не просто под набор ключевых слов. Выясните, какие вопросы действительно задаёт ваша аудитория, и дайте на них ясный ответ уже в первых абзацах страницы.
Однако для тех, кто изначально создавал контент для людей, а не только для поисковых систем, по сути ничего не поменялось.
Делайте информацию чёткой, структурированной, легко читаемой. Пишите в разговорном, естественном стиле — так, чтобы текст действительно было приятно воспринимать.
Такой подход помогает языковым моделям лучше понимать ваш материал и выше ранжировать страницы.
FAQ, блоки ответов, вопросы в естественной формулировке — начинайте с главного.
Сразу давайте чёткий ответ, а затем добавляйте связанные вопросы, примеры и пояснения.
Опирайтесь на надёжные источники, приводите ключевые факты в виде списков или таблиц, добавляйте доказательства и контекст.
Оптимизируйте текст под разговорные запросы, а не просто под набор ключевых слов. Выясните, какие вопросы действительно задаёт ваша аудитория, и дайте на них ясный ответ уже в первых абзацах страницы.
Однако для тех, кто изначально создавал контент для людей, а не только для поисковых систем, по сути ничего не поменялось.
Листал VC в поисках чего-нибудь любопытного и наткнулся на очередную «экспертную» статью про установку n8n на свой сервер. Но дело даже не в качестве материала — в нём снова не оказалось самого важного: нормального руководства по безопасности. Стало интересно, открыл Google, пролистал несколько первых страниц… и снова нигде об этом ни слова.
Особенно странно всё это выглядит в PDF-гайде, сгенерированном нейросетью человеком, который называет себя IT-коучем и экспертом по цифровизации...
Если n8n-сервер настроен неправильно, то любой посторонний может получить доступ практически ко всем данным и процессам, которые проходят через вашу автоматизацию.
Это одна из самых опасных ваших ошибок, потому что сервер зачастую хранит чувствительную бизнес-информацию.
1️⃣ если n8n развернут без N8N_BASIC_AUTH_ACTIVE=true, он доступен всем;
2️⃣ если открыт порт 5678 без firewall — сервис уязвим;
3️⃣ если вы не включили N8N_ENCRYPTION_KEY, данные сохраняются в plaintext.
P.S. На самый частый вопрос — «Да кому нужен мой сервер? Как его вообще найдут?» — ответ прост: находят его не люди, а поисковые системы, которые автоматически сканируют сеть. Достаточно погуглить, как работают такие сервисы, как Shodan или Censys — и всё сразу становится очевидно.
P.P.S. Эти три пункта — это не руководство по безопасности. Это лишь самая базовая основа. Если кому-то будет интересно могу продолжить...
Особенно странно всё это выглядит в PDF-гайде, сгенерированном нейросетью человеком, который называет себя IT-коучем и экспертом по цифровизации...
Если n8n-сервер настроен неправильно, то любой посторонний может получить доступ практически ко всем данным и процессам, которые проходят через вашу автоматизацию.
Это одна из самых опасных ваших ошибок, потому что сервер зачастую хранит чувствительную бизнес-информацию.
P.S. На самый частый вопрос — «Да кому нужен мой сервер? Как его вообще найдут?» — ответ прост: находят его не люди, а поисковые системы, которые автоматически сканируют сеть. Достаточно погуглить, как работают такие сервисы, как Shodan или Censys — и всё сразу становится очевидно.
P.P.S. Эти три пункта — это не руководство по безопасности. Это лишь самая базовая основа. Если кому-то будет интересно могу продолжить...
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2
Включив телевизор, спустя 20 минут вместо обещанных двух, ты непроизвольно задумываешься: всё-таки где-то раньше было проще. Но я хотел вообще написать не про это, а про блокировку WhatsApp, о которой все вокруг трубят.
Ведь проблема там куда глобальнее, чем просто то, что родственники не будут пересылать вам открытки. А в том, что во многих мелких и не очень бизнесах вся воронка продаж, записи да и вся первичная коммуникация: рассылки по клиентской базе, напоминания о записи и тд.
Вот где основная беда. Сейчас у части клиентов подключаем MAX бизнес( да, такое есть) и дублируем в него автоворнки. Плюс добавляем дополнительные кнопочки для связи на сайтах.
Отделы продаж запрашивают e-mail и никнеймы в телеграмм у действующих клиентов. Предновогодний период и так никогда не был простым, а в этом году он прямо бьет все рекорды.
Ведь проблема там куда глобальнее, чем просто то, что родственники не будут пересылать вам открытки. А в том, что во многих мелких и не очень бизнесах вся воронка продаж, записи да и вся первичная коммуникация: рассылки по клиентской базе, напоминания о записи и тд.
Вот где основная беда. Сейчас у части клиентов подключаем MAX бизнес( да, такое есть) и дублируем в него автоворнки. Плюс добавляем дополнительные кнопочки для связи на сайтах.
Отделы продаж запрашивают e-mail и никнеймы в телеграмм у действующих клиентов. Предновогодний период и так никогда не был простым, а в этом году он прямо бьет все рекорды.
👎1