Mike Blazer

Оказывается, страницы постов в Instagram имеют один и тот же текст в теге <title>. Жаль что у Instagram нет сеошников. Они могли бы это легко поправить с помощью Programmatic SEO. @MikeBlazerX

Попробуйте функцию "Custom Search" в Screaming Frog для обноружения возможностей внутренней перелинковки Для крупных сайтов с большим количеством контента может быть сложно проанализировать все статьи сайта, а чтение всего контента и поиск случаев, когда используется подходящий анкорный текст, отнимает много времени. К счастью, Screaming Frog упрощает эту задачу: 1. Откройте Screaming Frog 2. Перейдите в раздел Configuration > Custom > Custom Search 3. Нажмите "Add". Убедитесь, что выбрано значение "Contains Text", а затем введите желаемый якорный текст. 4. Повторите этот процесс для всех анкорных текстов, которые вы хотите найти 5. Начните поиск. По окончании вы можете перейти в раздел "Custom Search" и найти страницы с наибольшим количеством повторений искомого текста. @MikeBlazerX

Издатели контента и владельцы партнерских сайтов сейчас в ярости от Google. Я вижу все больше и больше твитов, в которых утверждается, что Google "разрушает их бизнес" из-за обзоров ИИ и последних обновлений алгоритма, - пишет Райан Стюарт. Google думает то же самое о вас! Google считает, что вы разрушили их бизнес, обманывая их с таким трудом созданный алгоритм и монетизируя их СЕРПы. Вы десятилетиями присасывались к титьке бесплатного трафика Google только для того, чтобы продвигать чужие продукты или продавать дерьмовые рекламные места на своем сайте. Вы практически не добавили ценности рынку, вы просто были прокладками. Ответы ИИ не крадут ваш контент. Если бы вы действительно в это верили, вы бы не стали индексировать свои сайты. Google делает то, что, по их мнению, лучше для пользователей. Предоставляет быстрые результаты на запросы, не заставляя их переходить на ваш контент, перегруженный словесной рвотой, которая была создана в первую очередь для ранжирования в Google. Прав ли Google в этом случае? Нет ни правых, ни виноватых. Google может делать со СВОИМ продуктом все, что захочет. Google ничего нам не должен. @MikeBlazerX

​Приложение BERT Automatic Interlinking Streamlit App V2 использует модель Sentence Transformers для поиска глубоких связей между страницами на сайте для их перелинковки. Оно имеет несколько практических применений: — Перелинковка связанных продуктов в тексте категории — Показать связанные категории на существующих страницах категорий — Найти связанный контент для содействия конверсии (блоги, руководства покупателя и т. д.) — Показать товары, наиболее тесно связанные со страницами категорий, для повышения релевантности. — Отображать связанные блог-посты В отличие от других систем перелинковки страниц, это приложение не использует якорный текст или метрики ссылок. Вместо этого оно формирует логические связи между страницами, чтобы повысить удовлетворенность пользователей и потенциально увеличить доход. Новые возможности включают кластеризацию, отсечение минимального сходства, выбор трансформаторов предложений, а также мультиязычный трансформатор, обученный 50 языкам. Варианты визуализации теперь предлагают древовидную или радиальную диаграмму с полной настройкой и обновлением в режиме реального времени. Минимальный балл сходства можно регулировать, чтобы контролировать строгость соответствия, а для уточнения входных данных доступны различные операции с файлами и опции фильтрации. Чтобы воспользоваться приложением, выполните следующие действия: 1. С помощью выбранного вами краулера веб-сайтов (например, Screaming Frog) создайте файл с результатами краулинга. Убедитесь, что файл содержит как минимум колонку URL и колонку для содержимого, которое вы хотите связать (например, теги H1, заголовки страниц или содержимое блога). 2. Загрузите файл с результатами краулинга в интерфейс приложения в формате CSV или Excel. 3. Сопоставьте столбцы в файле с нужными полями в приложении. По умолчанию приложение автоматически сопоставляет столбцы URL и H1, если они соответствуют соглашениям Screaming Frog об именовании. 4. Настройте параметры приложения в соответствии с вашими потребностями: — Выберите модель Transformer: paraphrase-MiniLM-L3-v2 (самая быстрая), all-MiniLM-L6-v2 (сбалансированная) и paraphrase-multilingual-MiniLM-L12-v2 (мультиязычная). — Установите порог, определяющий, насколько похожими должны быть страницы, чтобы считаться связанными. Более высокие показатели означают более строгое сопоставление. — Настройте способ группировки связанных страниц: древовидная или радиальная диаграмма. 5. Примените фильтры для очистки данных, например, удалите дубликаты страниц, отфильтруйте пагинированные URL-ы и сохраните только урлы с индексируемым статусом. 6. Запустите приложение, чтобы обработать файл и сгенерировать рекомендации по перелинковке. 7. Приложение отобразит результаты в виде визуализации в режиме реального времени. Вы можете настроить параметры визуализации, чтобы лучше понять взаимосвязи. Экспортируйте результаты. 8. Помните об ограничениях приложения, таких как максимум 1000 строк в одном входном файле и 15 совпадений в одном URL. Если вам нужно обработать больше данных, подумайте о предварительной фильтрации вашего файла. Приложение: https://bertlinker.streamlit.app/ Инструкция: https://leefoot.co.uk/portfolio/bert-automatic-interlinking-streamlit-app-v2/ @MikeBlazerX

Не удаляйте контент только ради SEO! Удаление старого контента — это довольно распространенный совет, но если делать это неправильно, можно навредить вашему сайту (или сайтам клиентов). Прежде чем приступать к удалению, необходимо провести аудит эффективности контента. Как это поможет? 1. Качество сайта: Google оценивает не только метрики на уровне отдельных страниц, но и качество всего сайта в целом. 2. Поток ссылочного веса: Удаление страниц может уменьшить количество внутренних ссылок, что приведет к увеличению PageRank, передаваемого по оставшимся ссылкам. 3. Улучшение краулинга: Удаление ненужных страниц позволяет поисковым роботам не тратить время на "мусор". Но есть и риски! Удаление контента может нанести значительный вред. Вот пять основных рисков: 1. Входящие ссылки: Удаление страниц с входящими ссылками может негативно сказаться на вашем ранжировании. Потеря таких ссылок означает потерю ссылочного веса. 2. Внутренние ссылки: Внутренние ссылки не только передают вес, но и обеспечивают релевантность с помощью анкорного текста. Удаление страниц может нарушить тематическую структуру и PageRank других страниц. 3. Трафик не из поисковых систем: Не весь трафик идет из поисковых систем. Некоторые страницы могут получать межсайтовый и прямой трафик (например, из социальных сетей или закладок). Удаление таких страниц может не понравиться пользователям. 4. Сезонные/трендовые изменения: Органический трафик страницы может быть низким или отсутствовать из-за сезонных факторов. В определенные моменты он может значительно увеличиваться. Не ориентируйтесь только на "недавние" данные о трафике, иначе можете упустить сезонные пики. 5. Воронка продаж: Конверсия — это постепенный процесс. Пользователи могут посещать множество страниц (информационных, доверительных и т. д.) на разных устройствах и/или аккаунтах. Удаление таких страниц может негативно сказаться на конверсиях. @MikeBlazerX

Один из способов узнать, какие поля в метаданных вашего изображения "читает" Google, - использовать инструмент проверки URL в GSC -> live test -> View tested page -> Source Вы увидите, какие метаданные извлекаются. Они показаны первыми, а затем за ними следует двоичный код. @MikeBlazerX

​В Википедии существует список достоверных источников, которые часто обсуждаются ее редакторами. Источники оцениваются от "Общедостоверных" до "В чёрном списке". Этот список может служить косвенным индикатором того, как другие оценивают надежность и качество веб-сайта, подобно пищевым этикеткам NewsGuard. Он обеспечивает объективный взгляд через призму редакторов Википедии. Владельцы сайтов и SEO-специалисты могут использовать этот список, чтобы: 1) Проверить рейтинг надежности своего сайта и прочитать обсуждения редакторов, 2) Проанализировать другие сайты в своей нише, чтобы понять, чему стоит подражать или чего избегать, 3) Понять, почему определенные сайты считаются надежными или ненадежными, 4) Проверять списки по конкретным нишам, если сайта нет в основном списке, 5) Посмотреть, где определенные сайты цитируются в качестве источников в Википедии. Этот список не является исчерпывающим, поэтому отсутствие сайта не обязательно говорит о его надежности. Звездные источники могут не нуждаться в обсуждении. Дополнительные списки надежных источников по темам и странам можно найти в "Путеводителе по источникам страничного патруля" (Page Patrol Source Guide). Вы можете воспользоваться поиском Википедии с помощью команды "insource", чтобы найти, где конкретный сайт упоминается в качестве источника во всех статьях Википедии. Изучение списка надежных источников Википедии может дать владельцам сайтов ценную объективную информацию о том, как их сайт и контент воспринимаются другими людьми, что может помочь в проведении улучшений, особенно после значительного обновления алгоритмов. https://www.gsqi.com/marketing-blog/wikipedia-reliable-sources-proxy-quality-raters/ @MikeBlazerX

Знаете ли вы, что в Chrome есть встроенная функция записи ваших действий? Вы можете записывать действия на любом сайте, а затем воспроизводить их, чтобы убедиться, что они работают или автоматизировать повторяющиеся задачи. Классно же? Как думаете, как можно эту фичу применить в работе по SEO? @MikeBlazerX

Различные способы загрузки JavaScript с помощью тегов <script> в HTML Оптимизация загрузки скриптов: Различия между сценариями async и defer defer - более старый, async - чуть более новый. Оба хорошо поддерживаются. Интуитивная разница между async и defer заключается в том, что async имеет тенденцию выполняться раньше (им не нужно ждать разбора HTML и построения DOM, а также извлечения других скриптов). "Стандартный" немодульный <script> (подразумевается type=text/javascript, нет async, нет defer) ❌ блокирует HTML-парсер ℹ️ немедленно загружается, разбирается и выполняется, перед любыми последующими <script> в HTML ✔️ гарантирован порядок выполнения ❌ блокирует событие DOMContentLoaded ❌ учитывая вышеизложенное, не подходит для некритического кода, так как может привести к "единой точке отказа" и задержке запуска динамических веб-приложений `defer` скрипты: ℹ️ для inline (non-module) скриптов, defer игнорируется и не имеет эффекта (они выполняются немедленно) 💡 если вам действительно нужно, вы можете использовать base64 хак ℹ️ для inline (module) скриптов, defer подразумевается (автоматически) ✔️ загружаются без блокировки HTML-парсера ✔️ гарантирован относительный порядок выполнения нескольких defer скриптов (если у всех есть src) ⚠️ однако, это баг в IE9- ℹ️ выполняются после разбора DOM (но перед поднятием DOMContentLoaded) ❌ блокирует событие DOMContentLoaded (если скрипт не async defer) async скрипты: ℹ️ для inline (non-module) скриптов, async игнорируется и не имеет эффекта ℹ️ для inline (module) скриптов, async поддерживается source - для выполнения вне очереди, как можно скорее ✔️ загружаются без блокировки HTML-парсера ⚠️ выполнение вне очереди; выполняются, как только доступны ⚠️ относительный порядок выполнения async скриптов не гарантирован (также относится к async, type=module скриптам) ⚠️ не ждут завершения разбора HTML; могут прервать построение DOM (особенно, если загружаются из кэша браузера) ⚠️ блокируют событие load (но не DOMContentLoaded) ⚠️ не поддерживаются в IE9- async defer скрипты: — интерпретируются как async; возврат к defer для древних браузерных движков, не поддерживающих async (IE9...) Больше информации найдете тут: https://gist.github.com/jakub-g/385ee6b41085303a53ad92c7c8afd7a6 @MikeBlazerX

Необходимы ли теги H1 для ранжирования? В 2020 году компания Moz провела эксперимент, чтобы определить влияние тегов H1 на ранжирование в органическом поиске. Поводом для эксперимента послужило наблюдение, что в своих блог-постах Moz использует теги H2 для заголовков вместо H1, что являлось багом их CMS. Что они тестировали Эксперимент проводился в пропорции 50/50. Половина заголовков блога была заменена на теги H1, а другая половина осталась в виде тегов H2. Цель состояла в том, чтобы измерить разницу в органическом трафике между двумя группами в течение восьми недель. Результаты Результаты показали, что изменение заголовков блог-постов с H2 на H1 не привело к статистически значимой разнице в органическом трафике. Это говорит о том, что Google способен понять контекст страницы независимо от того, завернут ли основной заголовок в тег H1 или H2. https://moz.com/blog/h1-seo-experiment @MikeBlazerX