Подарили мне два блока коллекционных карточек КХЛ — ощущения прямо как в детстве, с альбомами и стикерами.
🔥2
Минцифры Пензы планировали прямой эфир о проблемах с интернетом — но эфир не состоялся… из-за проблем с интернетом.
Wildberries вводит плату за использование внутреннего API.
С января 2026 года все облачные сервисы — официальные партнёры компании — смогут работать с API личного кабинета только после покупки специальных пакетов запросов.
💡 Что это значит:
Точные тарифы объявят в ноябре, но уже понятно, что изменения затронут:
— системы внутренней аналитики,
— биддеры,
— репрайсеры.
Очевидно, что стоимость их услуг вырастет.
С января 2026 года все облачные сервисы — официальные партнёры компании — смогут работать с API личного кабинета только после покупки специальных пакетов запросов.
💡 Что это значит:
Точные тарифы объявят в ноябре, но уже понятно, что изменения затронут:
— системы внутренней аналитики,
— биддеры,
— репрайсеры.
Очевидно, что стоимость их услуг вырастет.
Ловите бесплатный совет, как смотреть только качественный контент в шортсах/клипах: если слышите нейроозвучку, сразу свайп.
SEO для стоматологии в Google — это не про «алгоритмы», это про доверие и порядок в деталях.
Все хотят попасть в топ-10 Google...
Кто-то заказывает тысячи ссылок, кто-то пишет километры текстов...
Но правда в том, что для локального бизнеса — это не главное...
Важно одно: когда человек набирает “veneers near me”, чтобы он увидел именно вас.
А значит, нужно не «накручивать SEO», а быть понятным для Google и удобным для клиента.
📍Что реально влияет на результат:
— правильный адрес и категория в Google Business Profile;
— живые, свежие отзывы с фото;
— структурированный сайт с понятной логикой и быстрой загрузкой;
— одинаковые данные (NAP) на всех площадках.
Всё остальное — вторично.
Можно потратить тысячи долларов на ссылки, но если Google не уверен, где вы находитесь и как вас зовут — он покажет того, кто понятнее.
Адрес + отзывы + контент + карта + скорость = рост.
Это не какая-то магия, а математика доверия.
Все хотят попасть в топ-10 Google...
Кто-то заказывает тысячи ссылок, кто-то пишет километры текстов...
Но правда в том, что для локального бизнеса — это не главное...
Важно одно: когда человек набирает “veneers near me”, чтобы он увидел именно вас.
А значит, нужно не «накручивать SEO», а быть понятным для Google и удобным для клиента.
📍Что реально влияет на результат:
— правильный адрес и категория в Google Business Profile;
— живые, свежие отзывы с фото;
— структурированный сайт с понятной логикой и быстрой загрузкой;
— одинаковые данные (NAP) на всех площадках.
Всё остальное — вторично.
Можно потратить тысячи долларов на ссылки, но если Google не уверен, где вы находитесь и как вас зовут — он покажет того, кто понятнее.
Адрес + отзывы + контент + карта + скорость = рост.
Это не какая-то магия, а математика доверия.
Если твои знания в IT устаревают каждые полгода — это не значит, что “технологии слишком быстро меняются”.
Это значит, что ты застрял на уровне инструментов, а не принципов.
Ты выучил, как пользоваться конкретными тулзами — Ahrefs, Jenkins, Docker, Semrush, Kubernetes — но не понял, зачем и как они работают под капотом. Не разобрался в том, на каких принципах строится поисковая система или инфраструктура.
В SEO это выглядит так: человек юзает кучу чек-листов, но не понимает, как ПС ранжирует документы. Он обновляет СЯ, пишет “оптимизированные” тексты, но не может объяснить, почему сайт теряет позиции при смене кластера.
В DevOps, к примеру — то же самое. Можно выучить десяток YAML-файлов и команд, но не понимать, как устроен CI/CD-процесс, зачем нужен контроль версий или что такое инфраструктура как код в философском смысле.
Когда ты держишься только за инструменты, ты всегда догоняешь.
Появился новый фреймворк — ты снова ученик.
Сменился стек — твои знания обнулились.
Настоящая экспертиза — не в “знании Docker”, а в понимании принципов автоматизации, изоляции и воспроизводимости.
Не в “работе с SEO-инструментами”, а в понимании и поиске того, как поисковики принимают решения и что ранжируют.
Если твои навыки обесцениваются каждый год — это не потому, что индустрия нестабильна.
Это потому, что ты строишь карьеру на песке инструментов, а не на фундаменте принципов.
Это значит, что ты застрял на уровне инструментов, а не принципов.
Ты выучил, как пользоваться конкретными тулзами — Ahrefs, Jenkins, Docker, Semrush, Kubernetes — но не понял, зачем и как они работают под капотом. Не разобрался в том, на каких принципах строится поисковая система или инфраструктура.
В SEO это выглядит так: человек юзает кучу чек-листов, но не понимает, как ПС ранжирует документы. Он обновляет СЯ, пишет “оптимизированные” тексты, но не может объяснить, почему сайт теряет позиции при смене кластера.
В DevOps, к примеру — то же самое. Можно выучить десяток YAML-файлов и команд, но не понимать, как устроен CI/CD-процесс, зачем нужен контроль версий или что такое инфраструктура как код в философском смысле.
Когда ты держишься только за инструменты, ты всегда догоняешь.
Появился новый фреймворк — ты снова ученик.
Сменился стек — твои знания обнулились.
Настоящая экспертиза — не в “знании Docker”, а в понимании принципов автоматизации, изоляции и воспроизводимости.
Не в “работе с SEO-инструментами”, а в понимании и поиске того, как поисковики принимают решения и что ранжируют.
Если твои навыки обесцениваются каждый год — это не потому, что индустрия нестабильна.
Это потому, что ты строишь карьеру на песке инструментов, а не на фундаменте принципов.
Роскомнадзор неожиданно заблокировал серверы Amazon — из-за этого отвалилось огромное количество сервисов...
Раздел часто задаваемых вопросов должен включать вопросы, которые люди действительно задают — ещё лучше, если они действительно «часто» задаются.
Регулярно вижу разделы FAQ, которые, полностью выдуманы SEO-специалистами или контент-райтерами, чтобы просто расширить ширину охвата ключей.
Регулярно вижу разделы FAQ, которые, полностью выдуманы SEO-специалистами или контент-райтерами, чтобы просто расширить ширину охвата ключей.
Вроде бы и радостно, а всё равно тревожно. Ведь остаются ещё логистика и хранение, про которые здесь ни слова.
P.S. Зато этот месяц по работе с кабинетами прошёл ударными темпами: снизили расходы на рекламу клиенту, пересмотрели упаковку товаров, переработали часть инфографики и SEO.
И вот — вместо 2% маржи (от этих цифр хотелось плакать) мы уже вышли на обнадёживающие 16%.
P.S. Зато этот месяц по работе с кабинетами прошёл ударными темпами: снизили расходы на рекламу клиенту, пересмотрели упаковку товаров, переработали часть инфографики и SEO.
И вот — вместо 2% маржи (от этих цифр хотелось плакать) мы уже вышли на обнадёживающие 16%.
Все чаще слышу страшилки про то, что ИИ вот-вот оставит нас без работы. Серьёзно? Какой, простите, ИИ?
Он что, сам придумает, что вы хотели, если вы и сами этого не знаете?
Половина людей не может составить нормальное ТЗ, другая — связать две мысли без «ну ты понял».
Он что, сам придумает, что вы хотели, если вы и сами этого не знаете?
Половина людей не может составить нормальное ТЗ, другая — связать две мысли без «ну ты понял».
Сейчас продвигаю очередной сайт медицинского центра в Майами и снова поражаюсь, до какой степени можно "убить" 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 он не связан внутри.
Для поисковика он выглядит как набор разрозненных страниц, а не структура.