Может войдёшь?
Черновики Написать статью Профиль

Комментарии Lord_Alfred

  1. Простите, шта ? первый раз об этом слышу.

Всё верно. Гугл зачастую индексирует страницы, которые закрыты в robots.txt, но на них есть ссылки на сайте. Но эти страницы не показывает в результатах поиска, а пишет что-то в духе «содержимое страницы закрыто robots.txt» (это можно встретить при поиске через «site:domain.tld»)

Proger_XP

Google замечательно показывает «закрытые» страницы даже в обычном поиске без site: — а вот вместо вырезки со страницы (под заголовком и URL) он действительно пишет «содержимое страницы закрыто robots.txt».

Очень часто натыкаюсь на подобные результаты, по-моему со Stack Overflow.

Спасибо за замечания)

  1. но есть два момента, из-за которых вы делаете два запроса вместо одного

и

  1. Нет смысла дополнительно вначале проверять общее число записей в таблице, это можно определить из второго запроса.

Тут тоже на самом деле не всё так просто. Возможно, что у человека, кто потом заберет этот код себе — не будут созданы индексы по фильтрации, которая у меня заложена в методе PHP

Proger_XP
  1. чтобы не «насиловать» сервер в случае DDOS

О, ну это просто отговорка — в любом веб-приложении тонна мест, где можно получить DDoS: та же авторизация по определению требует тяжёлых вычислений хэша, или фильтр каких-нибудь товаров, который не может покрыть все поля индексами. А некоторые типы атаки (на канал) вообще не требуют никаких действий от сервера, ими можно завалить даже отдачу статики, безо всяких PHP. Конечно, специально создавать бутылочные горлышки не нужно, но именно защищаться от DDoS нужно на другом уровне (сетевом).

  1. в любом случае COUNT будет быстрее SELECT

Это спорно и зависит от типа запроса. Например, если в запросе нет ORDER B Y, то SELECT от SELECT с COUNT отличается только тем, что первый передаёт данные по сети, а второй нет. Если БД стоит на том же сервере, что и PHP — накладные расходы на копирование данных через память минимальны, зато сложный WHERE выполняется в обоих запросах дважды, что в зависимости от настроек БД и доступной памяти может не кэшироваться.

ИМХО, в первую очередь код должен быть кратким и «красивым» (последнее субъективно). Остальное это предоптимизация, которая обычно приносит больше проблем, чем пользы.

С зеркалами сейчас ситуация такая (сужу по гуглу) — они учитываются, если ссылка стоит с сайта, на который и ссылаются. То есть если на сайте есть ссылки на главную и на первую страницу одновременно (а так и есть в настоящий момент), то это считается зеркалом.

PS: лучше код гляньте, скажите — правильная ли реализация или я что-то не учел или мог бы сделать лучше?

Да, я в курсе, что он на Laravel, поэтому и добавил этот комментарий.

Поисковики учитывают это по-разному, поэтому некоторые плохие люди могут натолкать кучу ссылок со сторонних ресурсов на такие «зеркала» или «пустышки», этим самым пошатнув позиции сайта в серпе.

Proger_XP

ИМХО, это не может быть так — «зеркала» можно создать на любом сайте вообще без усилий, добавив любой параметр к URL (...?foo=bar); с «пустышками» сложнее, но тоже реально. Если такие проблемы и были, то когда-то давно, в то же время, когда URL были «обязаны» с точки зрения SEO иметь расширение .html, а JS-страницы не индексировались вообще.

К слову, эти же огрехи применимы и к текущей версии Habravel:

https://laravel.ru/?page=999999

https://laravel.ru/?page=0

https://laravel.ru/?page=-1000

Proger_XP
  1. К слову, эти же огрехи применимы и к текущей версии Habravel:

Потому что Habravel (внезапно) написан на Laravel, а автор описывает общую «проблему» Laravel. Не знаю, насколько это именно проблема в SEO, ИМХО, поведение логичное и поисковики его должны учитывать.

← Назад | Дальше → Движется на Habravel