Комментарии 48
Ну стоит подтянуть знания. Точно стоит :)
1. Забудьте про PageSpeed, пожалуйста. Если вы не знаете что с ним делать, то лучше вообще не трогать. 80% его рекомендаций просто бесполезно делать.
2. Комментировать правильно — хорошо, но «понизить позиции за комментарии в коде»… хм. Этот сеошник сломался, несите следующего. Если, конечно речь не идет о том, чтобы закомментировать 100+ строк — это уже просто некрасиво.
3. Закрывать пагинацию от индексации имеет смысл в том случае, если у вас есть страница с общим списком товаров (вот прям все 100500 телевизоров на обдной странице без всякого ajax). Да и это спорное решение.
4. Canonical работать не будет, т.к. в предыдущем пункте вы закрыли весь контент от индексации, т.е. от анализа роботом, а для признания страницы канонической робот _должен_ сравнить контент обеих страниц.
1. Забудьте про PageSpeed, пожалуйста. Если вы не знаете что с ним делать, то лучше вообще не трогать. 80% его рекомендаций просто бесполезно делать.
2. Комментировать правильно — хорошо, но «понизить позиции за комментарии в коде»… хм. Этот сеошник сломался, несите следующего. Если, конечно речь не идет о том, чтобы закомментировать 100+ строк — это уже просто некрасиво.
3. Закрывать пагинацию от индексации имеет смысл в том случае, если у вас есть страница с общим списком товаров (вот прям все 100500 телевизоров на обдной странице без всякого ajax). Да и это спорное решение.
4. Canonical работать не будет, т.к. в предыдущем пункте вы закрыли весь контент от индексации, т.е. от анализа роботом, а для признания страницы канонической робот _должен_ сравнить контент обеих страниц.
Это некое обобщение многих-многих внедренных SEO-аудитов. Спорить не буду, учиться всегда есть чему и подтягивать знания) Учту ваш комментарий, спасибо)
Про PageSpeed тоже считаю, что этот инструмент не подходит для оценки, но действительно попадаются те, кто считает хорошую оценку в нем — оценкой вашей работы в том числе. Поэтому совсем о нем не думать тоже не получается.
Про PageSpeed тоже считаю, что этот инструмент не подходит для оценки, но действительно попадаются те, кто считает хорошую оценку в нем — оценкой вашей работы в том числе. Поэтому совсем о нем не думать тоже не получается.
Не сомневаясь в том, что вы внедряли, КМК, аудиты были на редкость скучные и однообразные?) А если аудит не помог, то во всем был обвинен коварный гуглояндекс?
Достаточно очевидно, что в компаниях подобные аудиты пишутся по имеющимся шаблонам. Это же не весь аудит, малая часть. Просто когда ты например знаешь, что в меню обычно присутствуют циклические ссылки, само собой их закрывать сразу, а на новых проектах, где этого нет — мозолит глаза, вот и хочется, чтобы такие моменты сразу учитывались.
О PageSpeed. Откуда Вы взяли цифру 80%? Приведите примеры бесполезных рекомендаций.
PageSpeed это очень ценный инструмент, рекомендации которого нужно выполнять по нескольким причинам:
1) эти рекомендации действительно работают. Разработчики которые знают что делают с легкостью добиваются оценки выше 90 балов.
2) pagespeed дает вам относительную оценку которая учитывается гуглом при ранжировании проекта в выдаче. То есть даже если Вы правы, и какая то из рекомендаций действительно является глупостью, выполнить ее стоит хотя бы потому, что она даст проекту лишних попугаев в индексации.
PageSpeed это очень ценный инструмент, рекомендации которого нужно выполнять по нескольким причинам:
1) эти рекомендации действительно работают. Разработчики которые знают что делают с легкостью добиваются оценки выше 90 балов.
2) pagespeed дает вам относительную оценку которая учитывается гуглом при ранжировании проекта в выдаче. То есть даже если Вы правы, и какая то из рекомендаций действительно является глупостью, выполнить ее стоит хотя бы потому, что она даст проекту лишних попугаев в индексации.
Разработчики не пользуются Goggle Page Speed. Для этих целей есть Dev Tools со всеми метриками, таймингами и прочими FPS. Или Lighthouse. Или еще куча инструментов. Так что да, GPS это чисто сеошный фетиш, зачастую бесполезный.
Повторяю то что вероятно от Вас ускользнуло —
Пожалуйста примеры его бесполезности.
LightHouse в DevTools выдает ровно те же рекомендации что и PageSpeed. В некоторых случаях чуть более подробные описание проблемы бывают LightHouse и наоборот. Например в LightHouse нельзя сравнить свои показатели со средними по больнице, или в LightHouse нет подсказки средней пользовательской скорости загрузки вашей страницы.
Плюс несколько дополнительных рекомендаций связанных с SEO PWA и прочим, что является просто чек листом для нормального разработчика.
То есть даже если Вы правы, и какая то из рекомендаций действительно является глупостью, выполнить ее стоит хотя бы потому, что она даст проекту лишних попугаев в индексации.
зачастую бесполезный.
Пожалуйста примеры его бесполезности.
LightHouse в DevTools выдает ровно те же рекомендации что и PageSpeed. В некоторых случаях чуть более подробные описание проблемы бывают LightHouse и наоборот. Например в LightHouse нельзя сравнить свои показатели со средними по больнице, или в LightHouse нет подсказки средней пользовательской скорости загрузки вашей страницы.
Плюс несколько дополнительных рекомендаций связанных с SEO PWA и прочим, что является просто чек листом для нормального разработчика.
>Пожалуйста примеры его бесполезности.
Сравните отчеты по этой странице в Lighthouse (без PWA метрик) и Goggle Page Speed. В первом вполне конкретные on-page проблемы, во втором 80% претензий вида «уменьшить размер на 114 Б (21 %)» к CDN. Если для вас GPS более информативен — у меня нет задачи вас переубеждать.
Сравните отчеты по этой странице в Lighthouse (без PWA метрик) и Goggle Page Speed. В первом вполне конкретные on-page проблемы, во втором 80% претензий вида «уменьшить размер на 114 Б (21 %)» к CDN. Если для вас GPS более информативен — у меня нет задачи вас переубеждать.
GPS соглашусь порой выдает замечания к своим же скриптам и до недавнего времени на страницах которые реально тормозят выдавал хорошие баллы. Сейчас опомнились и ввели вторую метрику по скорости. Но. Боюсь что ранжирование поисковиком от того же google производится по аналогичным критериям может быть даже работает тот же программный код. Так что выполнять оптимизацию по результатам GPS все же имеет ощутимый результат если не для конечного пользователя контента то по крайней мере для более высокого поискового рейтинга
Я не говорил что GPS абсолютно бесполезен. Да, иногда вполне может пригодиться. Например скачать пожатые им же ресурсы. Быстро оценить загрузку, найти тяжелые картинки.
>Боюсь что ранжирование поисковиком от того же google производится по аналогичным критериям может быть даже работает тот же программный код.
Зачем гуглу юзать кастрированный GPS, когда у него прекрасный Lighthouse? А под закрытым капот наверняка и более продвинутый движек оценки загрузки.
>…все же имеет ощутимый результат … для более высокого поискового рейтинга
Я не видел ни одного кейса, где «подняли сайт в зеленую зону по GPS — прыгнули из топ-20 в топ-10». Из топ-100 в топ-50, 30, 40 видел. Но там трафика нет.
Повторю свое мнение: GPS полезен владельцам сайта или сеошникам, чтобы быстро оценить есть ли проблемы. Но решать эти проблемы будут разрабы, которые будут использовать другие, более информативные инструменты. Говорю вам как владелец, сеошник и разраб =)
>Боюсь что ранжирование поисковиком от того же google производится по аналогичным критериям может быть даже работает тот же программный код.
Зачем гуглу юзать кастрированный GPS, когда у него прекрасный Lighthouse? А под закрытым капот наверняка и более продвинутый движек оценки загрузки.
>…все же имеет ощутимый результат … для более высокого поискового рейтинга
Я не видел ни одного кейса, где «подняли сайт в зеленую зону по GPS — прыгнули из топ-20 в топ-10». Из топ-100 в топ-50, 30, 40 видел. Но там трафика нет.
Повторю свое мнение: GPS полезен владельцам сайта или сеошникам, чтобы быстро оценить есть ли проблемы. Но решать эти проблемы будут разрабы, которые будут использовать другие, более информативные инструменты. Говорю вам как владелец, сеошник и разраб =)
Откуда цифру? С нескольких сотен проектов.
Примеры бесполезных рекомендаций? Пожалуйста:
— уменьшить css на 2 байта
— убрать скрипты (в отдельный файл или вниз страницы) — и пофиг, что ломается статистика GA или коллтрекинг.
— уменьшить картинку на 700байт
И это большая часть их рекомендаций.
1. Работают, но далеко не все. Добиться высокой оценки несложно. Только это бессмысленно и не оправдывает приложенных усилий.
2. Гугл не учитывает это при ранжировании. То, что вы где-то прочитали про взаимосвязь скорости загрузки и позиции — это о другой скорости. Сайт, у которого 100 баллов легко может стоять ниже того, у которого 50 в зависимости от других факторов.
Но если вы сделали почти идеальный сайт и так уверены во всем, что внутри, то можете от скуки и попугаев добавить. Я ж не говорю, что он вредный — но тратить серьезное время на то, чтобы уменьшить вес страницы на сотню-другую байт (!) такое себе решение.
Примеры бесполезных рекомендаций? Пожалуйста:
— уменьшить css на 2 байта
— убрать скрипты (в отдельный файл или вниз страницы) — и пофиг, что ломается статистика GA или коллтрекинг.
— уменьшить картинку на 700байт
И это большая часть их рекомендаций.
1. Работают, но далеко не все. Добиться высокой оценки несложно. Только это бессмысленно и не оправдывает приложенных усилий.
2. Гугл не учитывает это при ранжировании. То, что вы где-то прочитали про взаимосвязь скорости загрузки и позиции — это о другой скорости. Сайт, у которого 100 баллов легко может стоять ниже того, у которого 50 в зависимости от других факторов.
Но если вы сделали почти идеальный сайт и так уверены во всем, что внутри, то можете от скуки и попугаев добавить. Я ж не говорю, что он вредный — но тратить серьезное время на то, чтобы уменьшить вес страницы на сотню-другую байт (!) такое себе решение.
Для желающих особо выделиться и перфекционистов — прорабатываем страницы постраничной пагинации. Список действий при этом достаточно простой:
Ставим на все страницы, кроме первой, тег <meta name=”robots” content=”noindex, follow”>. Это скажет поисковому роботу, что контент индексировать не надо, но если встретит ссылки — то надо по ним перейти и проиндексировать новые страницы…
Не совсем ясно. Текст с разделением на страницы содержит каждая страница свой контент. Почему его не следует индексировать кроме самой первой страницы?
Насколько я понимаю, это будут страницы с дублирующимся контентом. Поэтому важна только первая страница, а на остальных — лишь ссылки на элементы, которые там представлены
Проконсультировалась с SEO-специалистами) Робот может принять 2 и последующие страницы пагинации как целевые, и начнет туда гнать трафик, поскольку индексирует он именно текстовое содержимое страницы. Нам же важно, чтобы целевой была именно 1 страница. А от robots noindex, follow мы будем отходить, т.к. Google недавно заявил, что будет такие мета-теги воспринимать и как nofollow. Так что вывод — склеиваем канониклом) Статью сейчас обновлю.
Все на так однозначно. Мне на ум приходят два варианта использования постраничного вывода.
1-й условно назовем его динамичский — когда содержание страниц постоянно обновляются — например новости. Тогда действительно индексировать не нужно ни первую ни последующие страницы но обязательно чтобы каждая новость имела свою ссылку на отдельную страницу новости по которой будет проиндексирован ее контент.
Первую страницу тоже можно приндексировать чтобы был вход на раздел с новостями например
2-й условно назовем ее статический — когда содержание страниц не меняется со временем, например это статья, которая раззделена на несколько страниц или литературное произведение. Тогда контен нужно иденксировать и на первой и на последующей странице. И если мы захотим почитать про друга детства велкиого комбинатора Колю Остен-Бакена то нам гарантирована выдача этого контента на той странице где он и расположен см. petrov.com.ua/GoldCalf/pages/10.htm
Я бы сказа другое. Обо всем этом можно забыть, если только страница не содержит старого доброго html (Я намекаю на динамически генерируемый контент на стороне браузера при помощи JavaScript/Angular/React/Vue) А это сейчас очеь даже актуально.
1-й условно назовем его динамичский — когда содержание страниц постоянно обновляются — например новости. Тогда действительно индексировать не нужно ни первую ни последующие страницы но обязательно чтобы каждая новость имела свою ссылку на отдельную страницу новости по которой будет проиндексирован ее контент.
Первую страницу тоже можно приндексировать чтобы был вход на раздел с новостями например
2-й условно назовем ее статический — когда содержание страниц не меняется со временем, например это статья, которая раззделена на несколько страниц или литературное произведение. Тогда контен нужно иденксировать и на первой и на последующей странице. И если мы захотим почитать про друга детства велкиого комбинатора Колю Остен-Бакена то нам гарантирована выдача этого контента на той странице где он и расположен см. petrov.com.ua/GoldCalf/pages/10.htm
Я бы сказа другое. Обо всем этом можно забыть, если только страница не содержит старого доброго html (Я намекаю на динамически генерируемый контент на стороне браузера при помощи JavaScript/Angular/React/Vue) А это сейчас очеь даже актуально.
Google уже давно индексирует контент, генерируемый javascript: краулер поддерживает возможности аналогичные Google Chrome 41.
Ждал этого комментария. см. habr.com/post/417503/#comment_18903677
Отчвечу немного подробнее.
1. Это делает только google
2. Рендеринг генериуемого контента зн\анимат на пару порядков больше и времени и памяти на стороне бота. Что ставит по сомнение тот факт, что это google делает для всех абсолютно страниц. Скорее всего масштабы такого индексирования более ограничены. И Вы ниегде не найдете мне документа от google который говорит иное. Онги говорят только что они могут это делать.
3. С учетом того что в выдаче google с некоторого времени ставится дружественностть для работы на мобильных (слабых) девайсах и скорость рендеринга — такие приложения ообречены плестить в хвосте рейтингов.
1. Это делает только google
2. Рендеринг генериуемого контента зн\анимат на пару порядков больше и времени и памяти на стороне бота. Что ставит по сомнение тот факт, что это google делает для всех абсолютно страниц. Скорее всего масштабы такого индексирования более ограничены. И Вы ниегде не найдете мне документа от google который говорит иное. Онги говорят только что они могут это делать.
3. С учетом того что в выдаче google с некоторого времени ставится дружественностть для работы на мобильных (слабых) девайсах и скорость рендеринга — такие приложения ообречены плестить в хвосте рейтингов.
Я преждлагаю Вам и всем кому инетересно лично убедиться в этом
Вот один из очень популрных ресурсов — документация по последней версии роутера react reacttraining.com/react-router/core/guides/testing
Эта мега-популярный ресурс с очень большой посещаемостью.Теперь попробуем нати фразу из первого абзаца этой страницы
Далее пробуем найти эту фразу в google. Мы ее естественно находим но не на этом ресурсе.
Может быть там хитрый robots.txt? Нет. Вот такой:
Вот один из очень популрных ресурсов — документация по последней версии роутера react reacttraining.com/react-router/core/guides/testing
Эта мега-популярный ресурс с очень большой посещаемостью.Теперь попробуем нати фразу из первого абзаца этой страницы
React Router relies on React context to work. This affects how you can test your components that use our components.
Далее пробуем найти эту фразу в google. Мы ее естественно находим но не на этом ресурсе.
Может быть там хитрый robots.txt? Нет. Вот такой:
User-agent: Twitterbot
Disallow:
Ну если уж откровенно, то проблема притянута за уши. SSR даже в виде кривых костылей решал проблему индексирования react/angular/vue приложений. А уже сейчас там вполне стабильные коробочные решения. Например Nuxt.js для Vue: генерит статичные html которые индексируются вполне без проблем.
Ssr это уже не spa. Если Вы имеете в виду изоморфные ониже универсальные приложения то да проблема у решают. Но их не так много тк сложность разработки существенно увеличивается. Что касается упомянутых продуктов — да есть хорошие наработки по изоморфные приложениям. Что касается конкретно из этого перечня angular — там было даже в из коробки по крайней мере в старых версиях. Но по возможностям если я не ошибаюсь только генерация статических файлов и все. Сложно назвать проблему протянутой за уши если она реально существуют а возможные пути ее решения редко применяют.
SSR это решение проблемы индексации реактивных сайтов/SPA/приложений.
Очень спорно. Я не фронт, но уверен что любой мидл прикрутит SSR за рабочий день в к любому реактивному сайту. Хоть в статику, хоть поднять ноду на сервере и вот оно — изоморфное приложение. Возможно я не прав и фронтэндеры меня поправят.
Но их не так много тк сложность разработки существенно увеличивается … а возможные пути ее решения редко применяют.
Очень спорно. Я не фронт, но уверен что любой мидл прикрутит SSR за рабочий день в к любому реактивному сайту. Хоть в статику, хоть поднять ноду на сервере и вот оно — изоморфное приложение. Возможно я не прав и фронтэндеры меня поправят.
Это намного сложнее. На готовое приложение прикрутить изоморфносль просто невозможно. Она должна закладываться изначально
У автора идеи изоморфносль приложения из airbnb на эту роль несколько лет. Airbnb наконец недавно стал изоморфен
У автора идеи изоморфносль приложения из airbnb на эту роль несколько лет. Airbnb наконец недавно стал изоморфен
Возможно я не прав и фронтэндеры меня поправят.
Очень зависит от приложения. Если это изначально не было заложено в систему — будут проблемы. Возможно большие. Для примера — вы наверняка натыкались на SPA которые грузятся несколько секунд. Отдельный вопрос — роутинг конкретного приложения. Отдельный вопрос работа с асинхронными методами. Отдельный вопрос всякие заглушки и анимации. На самом деле, это может отнять как от относительно небольшого времени, до масштабных изменений в архитектуре SPA приложения.
Если бы все было просто все бы сейчас разрабатывали изоморфные приложениям. Next и nuxt решают большинство вопросов хотя порождают и новые проблемы. То что spa загружаются дольше чем классика это скорее не исключение а правило. Тк сначала грузятся скрипты хорошо если не все а разработчик использует code splitting — только потом начинают грузится картинки ТК соответствующие элементы только что были созданы скриптами. На слабых телефонах ещё включается, фактор медленного выполнения скриптов.
Да ещё чуть не забыл плюс время на пару-тройку загрузки при и для многоязычных сайтов переводы интерфейса
Да ещё чуть не забыл плюс время на пару-тройку загрузки при и для многоязычных сайтов переводы интерфейса
Поддержка JS не означает отсутствие любых проблем с индексацией. А SPA это тем более специфичный сегмент. Разработчикам приложений необходимо соблюдать все те же самые соглашения, обычно присущие контентным ресурсам, касательно урлов, метаданных, контента и разметки.
Вбейте "site:reacttraining.com testing". Там видно, что Google проиндексировал некоторые страницы. Но в целом сайт сделан без учета требований SEO отсюда результат.
Конкретно для react на удивление мало толковых руководств как правильно готовить client side в плане SEO, а поддержка со стороны фреймворков никакущая чтобы заработало само. В общем не удивительно.
Страницы пагинации вполне можно использовать во благо. Например типичный список товаров, отсортированный по цене. На первой странице цены 10-8 т.р., на второй 8-6 т.р., на третьей 6-4 т.р. и так далее. Добавляем в title и meta диапазон, подставляем в описание страницы, разрешаем индексирование и… вуаля, ищемся по запросам вида «купить кроссовки от 4 до 6 тысяч».
<meta name=”robots” content=”noindex, follow”> — лучший вариант для страниц пагинации. Многие используют canonical, что в корне неверно. Canonical используется если у вас есть одна страница, доступная по нескольким URL.
Не забыть создать 404 ошибку
Добавить файл — robots.txt
В next prev и canonical использовать абсолютный url, а не относительный
И в зеркалах не забыть про index.php и index.html
А так же что зеркала клеятся через 301, а не через 302 редирект
Добавить файл — robots.txt
В next prev и canonical использовать абсолютный url, а не относительный
И в зеркалах не забыть про index.php и index.html
А так же что зеркала клеятся через 301, а не через 302 редирект
"Блог компании Яндекс" точно есть на сайте, по идее Google тоже.
В общем, странно читать что-то по поисковой оптимизации не от этих компаний.
Кроме конкретных правил, которые дают сами поисковики, все остальное в SEO — это древний примитивный культ с кучей течений, но которые являются чисто догматами верований и никак не соответствует реальности.
В общем, Хабр не место для такого!
Без танца с бубном, SEO (рекомендации поисковых систем) не дает ожидаемых результатов. А рекомендации ПС, часто нуждаются в дополнении под конкретные случаи.
Рекомендации ПС объективны. Все остальное в SEO по принципу когда-то что-то показалось и теперь я считаю, что это правильно, хотя я мог ошибочно оценить результаты, например, не я что-то сделал хорошо, а конкурент плохо или раньше что-то помогало, а потом стало вредить вообще, но на основании того, что мне это помогало, я это уже не проверяю и использую.
Написал от первого лица, но я не сеошник...
В общем, Хабр — это технический ресурс. Даже если люди ошибаются в технических вопросах, то это измеряемо и другие могут на это указать, что нельзя сказать про SEO.
Рекомендации ПС объективны
Рекомендации пс тоже субъективны. Но они гораздо ближе к истине.
Все остальное в SEO по принципу когда-то что-то показалось и теперь я считаю, что это правильно, хотя я мог ошибочно оценить результаты, например, не я что-то сделал хорошо, а конкурент плохо или раньше что-то помогало, а потом стало вредить вообще, но на основании того, что мне это помогало, я это уже не проверяю и использую.
Вы слишком утрируете, на самом деле методы оптимизации (с целью влияния на поисковую выдачу) проверяются по много раз с течением времени и по мере изменений алгоритмов пс. Зависит от добросовестности и опыта оптимизатора.
Рекомендации ПС не могут быть объективны сейчас. По-хорошему, ничьи рекомендации не могут быть объективны, поскольку поиск работает по принципу черного ящика.
И Мэтт Каттс в свое время в твиттере и Сегалович (или Садовский) в каком-то из интервью говорили прямо, что формулы ранжирования настолько усложнились, что в отделе поиска просто нет человека, который полностью от и до понимал бы что как и почему происходит. Именно поэтому гуглояндекс может давать только очень обобщенные рекомендации, следование которым позволяет почти гарантированно не попасть под фильтр, но не более.
А вот частности свои для каждого конкретного сайта.
И Мэтт Каттс в свое время в твиттере и Сегалович (или Садовский) в каком-то из интервью говорили прямо, что формулы ранжирования настолько усложнились, что в отделе поиска просто нет человека, который полностью от и до понимал бы что как и почему происходит. Именно поэтому гуглояндекс может давать только очень обобщенные рекомендации, следование которым позволяет почти гарантированно не попасть под фильтр, но не более.
А вот частности свои для каждого конкретного сайта.
внешние ссылки — это те, которые ведут на другие сайты и получается уводят ваших посетителей в другое место;
Всем таким ссылкам мы добавляем атрибут ‘rel=”nofollow”’, которые даст поисковым роботам понять, что по этой ссылке идти не надо и учитывать её не стоит.
не думаю что данный аттрибут как то учитывается сейчас для внешних ссылок. Иначе это сродни «клоакингу» — для пользователей это значит довольно важные ссылки раз они есть, а вот поисковым системам их учитывать не надо.
Гугл пишет, что учитывает https://support.google.com/webmasters/answer/96569?hl=ru.
А вот утверждение
достаточно спорно, существует мнение, что вес утекает в небытие.
А вот утверждение
Таким образом мы сохраняем вес страницы
достаточно спорно, существует мнение, что вес утекает в небытие.
Читаю некоторые комментарии и улыбаюсь:)
Во первых, не надо выдумывать из головы, учитывает поисковик тот или иной параметр, если о нем недвусмысленно написано в документациях от самого поисковика.
Во вторых, приведенные в статье примеры, в своем большинстве, однозначно нужно принимать во внимание перед созданием сайтов! Это совсем не сложно) В противном случае, мы можем получить (и часто так и выходит) сайт, который без танцев с бубнами можно только на контекстную рекламу пускать.
И в третих, большинство сайтов создаются для дальнейшего продвижения их в сети и привлечения лидов. И вот тут с сайтом, в том числе, начинают работать СЕО-шники, которые, как ты ни крути, будут давать кучу рекомендаций, которые стоит выполнять, включая и те, что написаны в статье. Да — это как кидать камушки в воду, и смотреть к чему все приведет, но! Если ничего вообще не делать — то результата уж точно не будет.
По поводу учета параметров весь вопрос с каким весом учитывает.
А пор поводу учета в начале ращрабортки могу только поддержать.
Но что делать если тербования СЕО прямо впротиворечат техническим интересам разработчиков которые хотят писать на Angular/React/Vue кторые во встречающемся в 99% случаев использую рендеринг на клиенте, который не инексирует никто кроме google, а google в свою очередь по на вопросы по поводу инрексирует ли он их отвесает уклончиво: да мы модеи это делать, а почкму бы и нет. И основной источник это интервью кого-то из их команды в котором он так ничего только не подтверждает и не опровергает.
А пор поводу учета в начале ращрабортки могу только поддержать.
Но что делать если тербования СЕО прямо впротиворечат техническим интересам разработчиков которые хотят писать на Angular/React/Vue кторые во встречающемся в 99% случаев использую рендеринг на клиенте, который не инексирует никто кроме google, а google в свою очередь по на вопросы по поводу инрексирует ли он их отвесает уклончиво: да мы модеи это делать, а почкму бы и нет. И основной источник это интервью кого-то из их команды в котором он так ничего только не подтверждает и не опровергает.
Что значит «хотят писать на Angular/React/Vue »? У всех технологий есть своя сфера применения. Если строители хотят построить дом обязательно из говна и палок, то лучше поискать других строителей, не?
Было бы хорошо если все делалось правильно. Вот проблема. Ведущие разработчики вдохновились идеей разрабатывать сайт на модной и востребованной на рынке труда технологией (плюсики к резюме). Эти технологии не дружественные СЕО. В качестве экспертов по этому вопросу выступают эти жде самые разработчики. Странно что они еще не подтянулись к комеентариям и не расскзалаи что все индексируется и никаких траблов не существует.
В общем случае: внешние ссылки — это те, которые ведут на другие сайты и получается уводят ваших посетителей в другое место. Всем таким ссылкам мы добавляем атрибут ‘rel=”nofollow”’, которые даст поисковым роботам понять, что по этой ссылке идти не надо и учитывать её не стоит. Таким образом мы сохраняем вес страницы.
Водопроводная аналогия в 2018 году, опять? Ещё же в 2005-2007 было показано на экспериментах, что она некорректна для ссылочного ранжирования, исходящие ссылки не влияют на вес страницы. Есть какие-нибудь свежие эксперименты на эту тему? Или это требование из разряда «деды наши ставили nofollow на внешние ссылки — и мы будем»?
А где же минимальная настройка Яндекс Вебмастер и Google Search Console? Где sitemap.xml? Где упоминание о https чтобы потом не мучиться и не терять трафик?
Вообще сейчас склонен думать что программисты просто не знают даже о таких простых вещах как robots.txt, не раз был свидетелем обвального падение трафика после некорректных «обновлений» сайта когда тупо забыли сделать нормальный роботс. А в такие дебри мало кто влезает.
Вообще сейчас склонен думать что программисты просто не знают даже о таких простых вещах как robots.txt, не раз был свидетелем обвального падение трафика после некорректных «обновлений» сайта когда тупо забыли сделать нормальный роботс. А в такие дебри мало кто влезает.
Самое главное.
— При редизайне: Не забудьте проверить что новый сайт отвечает на все старые ссылки которые уже проиндексированы поисковиками.
В противном случае ваши страницы выпадут из индекса гугла и яндекса и сайт очень не скоро (а может и никогда) уже не вернется на прежние позиции.
— При редизайне: Не забудьте проверить что новый сайт отвечает на все старые ссылки которые уже проиндексированы поисковиками.
В противном случае ваши страницы выпадут из индекса гугла и яндекса и сайт очень не скоро (а может и никогда) уже не вернется на прежние позиции.
Не забудьте проверить что новый сайт отвечает на все старые ссылки которые уже проиндексированы поисковиками.
Типовой случай, без всяких редизайнов: были ссылки вида /article/1202 или /article/1202-custom-name-from-title-of-the-article. SEO приказало убрать ID из ссылок. Стало /article/name-name-name или /name-name-name.
- Грабли первые: проигнорировать смену URL. Опаньки, сплошные 404.
- Грабли вторые: при смене title меняется URL. Старые ссылки умирают. Стало быть нужен некий динамический реестр старых ссылок. На моей памяти никто его не организовывал, всем лень, ибо много возни. А если типов сущностей полно, а управление ими слишком разнообразно, то… Ну вы поняли. А кто-то даже не подумал об этом.
- Грабли третьи: возможны коллизии по именам. Как одинаковые заголовки, так и разные, но с одинаковым транслитом
Первую проблему решить несложно. Главное её просто не проигнорировать. А вторую проблему обычно и не решают. Но зато SEO-лист претензий выполнили до последнего пункта. Сами SEO-ки тоже, скорее всего, ничего про это не скажут. В гороско...SEO-инструменте-с-галочками об этом ничего не написано.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
О чем должен помнить веб-разработчик, чтобы сделать всё по SEO-феншую