Люди, кто разбираеться в раскрутке и размещению сайтов? Можете ли разъяснить следующий вопрос: понимают / индексируют ли поисковые системы скрипты, которые создают разделы следующим образом name.php?page=01.
Я хочу разобраться в этом вопросе более детально, так как не все поисковики эту строчку понимают , или я не прав?

1. Вроде как давно уже понимают. По крайней мере, в результатах поиска такое встрачается уже несколько лет.
2. Независимо от индексации человеку такие адреса, как правило, неудобны.

1. Я слышал, что не все. Один мой приятель занялся разыскивать фирму для раскрутки своего проекта и его огорчили. Сказали, что поисковики работают с html 2.0.

2. Этот вопрос всегда был актуален. Есть идеи по этому поводу? Может где эта тема на форуме уже обсуждалась?

Тебе какие поисковики нужны-то? Самые популярные уже давно все понимают.
А вообще такие адреса и впрямь надо резать. И катком давить.

da-khosh писал(а):

Сказали, что поисковики работают с html 2.0.

"Ох уж мне эти сказочники" (c)

da-khosh, понимать понимают. Все крупные. То есть я даже не смогу сходу назвать кто и не понимает. Но... есть кучка малегьких но:
1. лимиты на такие урлы ниже.
2. бойтесь параметров носящих имя id, sid и т.п. даже если это не сессии.
3. пункт 1 имеет следствие: сделав модрерайт и ссылки помните что паук будет тащить документы как html, то есть дернуть сразу сто-двести запросто. А так как у вас там пхп скажем спрятан то все может упасть просто. Такой вот минидос.

Pgprint, что под п. 3 подразумевается? как соотносится чпу, пхп и падение от ста-двухсот запросов?

Long, лимиты на количество одновременно дергаемых файлов html у бота выше чем на php. Оно и ясно как бы почему. Но если ты скрыл от бота что у тебя там динамика, то тащить он это будет от всей своей ботовой души. А база то не резиновая. Она сдохнет раньше апача.
Ты в логи посмотри как паук посещает жирный сайт. Поймешь.

da-khosh, понимают и великолепно индексируют.
Pgprint, можно оптимизацией несколько лет заниматься и ни разу не столкнуться с твоими 1 & 3.

Pgprint, еще раз - при чем тут связка - чпу-пхп-падение_сервера? каждое звено по отдельности - понятно, но каким образом пытаетесь выстроить логику объяснения - не понятно. мод_реврайт внесет задержку? определенно внесет, только это будет столь не существенная величина, что ее можно не рассматривать. динамическая страница обрабатывается сервером дольше чем чистый хтмл? кто спорит? но делать статичные сайты в наше время - нонсенс. большое количество одновременных запросов может завалить сервер? да, безусловно, на этом строятся атаки. но как связать это все с тем, что мод_реврайт - это плохо? имхо, кому-то нужно больше спать

Long, Pgprint пишет, что робот при единичном заходе на сайт берет больше страниц, которые он считает статическими, чем страниц, которые он (робот) считает динамическими. Что мод_реврайт - плохо - Pgprint не писал.

@TSV, конечно можно. Это как на охоту ходить. Можно ходить всю жизнь и никого не подстрелить. Но если заниматься эьтим профессионально...

Long, на пальцах: один и тот же сервер способен ообработать Х обращений в секунду к стационарному файлу page_i_.html Если на этом сервере стоит еще и база, то файл page.php?x=i1 (скажем страницу данного форума) тот же сервер если спросить Х раз в секунду - сервер умрет. Потому что работы больше. То что отдавать по запрсу сперва надо собрать. Это для пхпбб будет что-то около 90 запросов к базе. Вопрос не в задержке изза времени обработки модрерайтом. Вопрос в базе. Она может не успевать. Поисковые машины это учитывают и дергают динамические файлы с меньшей интенсивностью. Для большинства сайтов это не критично, но это как в примере @TSV, только если вы не занимаетесь этим профессионально. Собственно если вы прочтете что я написал, то возможно узреете что я нигде не сказал что модрерайт это плохо. Я просто сказал что надо помнить о таком побочном эффекте. Ибо в такой ситуации будет у вас реквест тайм аут и паук не получит ничего. В результате половина ваших страниц будет болтаться в индекс и из индекса как дерьмо в проруби. Вы вникайте в суть вопроса, а то как с вашим ответом про обязательность копирайта получается.

Pgprint, … если заниматься профессионально, то для борьбы с пиковыми загрузками сервера можно и нужно другие методики применять. заботиться, например, (1) о том, чтобы оптимизировать код и чтобы запросы были "полегче". (2) Можно закэшировать, наконец. Можно самомУ, можно, например, с помощью специально обученного squid'а.

ЗЫ. Всегда предпочитаю для определения того, какую нагрузку сервер выдержит, а какую нет, оперировать конкретными цифрами. Цифры же показывают, что для грамотно построенного сайта вероятность его "перегрузки" пауками Google, Yandex, Rambler, Aport ничтожно мала. Роботы-то "вежливые", единовременно много не тащут.

@TSV, я разве сказал что это смертельная проблема и нет способа борьбы? Просто это то, о чем стоит помнить. Пиковая загрузка в такие моменты сильно превышает среднюю. Насчет вежливости роботов вы можете посчитать на серчэнджинсах стон владельца www.bpn.ru

Цитата:

Сегодня гугль за 1,5 часа съел 7500 страниц! При этом участвовали боты с 113 разными IP. За 1,5 часа мой сервак был завален около 4 раз!!! И все потому что боты посылали в секунду от 50 до 450!!!!! запросов одновременно.

И почитать пример куска ответа гугля на вопрос "почему меня нет в кеше"

Google писал(а):

The Google index contains two types of pages: fully indexed and partially indexed pages. Your page is currently partially indexed. Because our robots were unable to completely review its content during our last crawl, your site appears without a cached copy or detailed title. Instead, it's listed by its URL.

То есть никто не говорит что это смертельная проблема, просто надо помнить о ней.

Pgprint писал(а):

… Сегодня гугль за 1,5 часа съел 7500 страниц! …

это очень мало!. +2 запроса в секунду к средней нагрузке. Слёзы.

Pgprint писал(а):

… И все потому что боты посылали в секунду от 50 до 450!!!!! … запросов одновременно.

… а это элементарно лечится настройками сервера, теми самыми, которые ограничивают число одновременных подключений.

Pgprint писал(а):

То есть никто не говорит что это смертельная проблема, просто надо помнить о ней.

Дык. Вот только методы должны быть грамотные. Настройки сервера, оптимизация скриптов, кэширование и т.д. ЧПУ делать все равно нужно.

… подумал еще немного … 113 разных IP, от 50 до 450 запросов одновременно … робот Гугля? Точно робот Гугля, а не DOS-атака, которая под него косит? Точно-точно? Не то, чтобы не верю совсем, но "меня терзают смутные сомнения".

@TSV, что вы мне толчете то что я сам написал?

Pgprint писал(а):

сделав модрерайт и ссылки помните что паук...

Что вы мне рассказываете как с этим бороться? Вопрос не об этом был. Как бороться понятно. Это все очевидно. Я просто обратил внимание спрашивающего дабы он не забыл об этом вопросе.

@TSV, точно, точно гугль. IP то неподделаешь. Вы просто больших сайтов видать не трогали. Это еще по божески. Бывает хуже.

Pgprint, всем-всем понятно как бороться? Писалось для автора топика по большей части, который как раз хочет разобраться более детально. А я писал о том, что "слухи о немедленной смерти сервера сильно преувеличены". Можно смело отложить вопрос на потом, и на начальном этапе не париться об этом совсем.

@TSV, нельзя не потом. Потому как ты узнаешь о том что это самое "потом" наступило сразу после того как сервер упадет. А паук в это время запрашивает и запрашивает. И получает ответы что мол а все, пирожных нет. И опосля уже владелец сайта верешит "как же так?!" и получает процитированные выше ответы от гугля.

А насчет того что не всем понятно ты прав конечно. Некоторым и суть проблемы то неясна

Pgprint, больших - трогал-трогал. Но в Рунете, а там трафик гораздо меньше. То есть, резюмируя, заботиться о том, чтобы робот сервер не завалил, нужно при соблюдении (как минимум!) 5-ти условий:
1. Сайт должен быть большим, ориентировочно выше 10,000 страниц
2. Сайт должен быть ориентирован на, скажем так, общемировую аудиторию. Не Рунет
3. Запрос единичной страницы должен быть относительно "тяжелым", т.е. есть база, страницы динамические, запрос одной создает сильную нагрузку на базу.
4. У сайта должна быть высокая посещаемость, т.е. уже высокий средний уровень загрузки. Иными словами, мало резервов производительности
5. Конфигурационный файл сервера должен быть кривым
… уже хорошо получилось …

ЗЫ. Я там выше писал, что приведенные цифры нагрузки - небольшие. Халява, в общем-то.

Pgprint, можно-можно на потом. Грубо гря, существует способ оперативно "поставить пробку в пробоину", а затем "починить как положено". Типа этого:
1. Заметил, что нагрузка высокая
2. Первым делом залез в конфигурацию сервера и ограничил число подключений. Это очень быстро.
3. Потом пишется мааахонький и простенький скрипт кэширования, который вывод сервера перехватывает (output buffering) и кэширует просто как файл html. Это тоже быстро.
4. Потом неспешно настраиваем squid или еще какой прокси на сервере, чтобы кэшировал. Поднимаем число одновременных подключений.
5. Потом неспешно оптимизируем скрипты, чтобы выдача была быстрей. Поднимаем число подключений еще, то есть сервер опять работает штатно.

PS. Я делаю пп. 2,3 & (может быть) 5 сразу, но я-то параноик...

1. Results 1 - 10 of about 6,330 from bpn.ru
2. www.bpn.RU
3. это понятие относительное. Вы считаете что нетяжелое, а оно бац - и тяжелое оказалось.
4. загрузку трудно назвать словом "высокая"
5. понятие кривости относительно. Вы считаете ровное, а оно бац - и кривое.

Факт: "За 1,5 часа мой сервак был завален около 4 раз!!"

Вопрос не в том большие ли загрузки. Вопрос в том, окажутся ли они достаточными что бы уронить вас здесь и сейчас. Слова "да ну, разве это большие были нагрузки, это ж мы одной левой" задним числом не помогут, даже если правильны.

Ладно, лирика все это. Все итак ясно. Есть факт. Вопрос о том является ли факт проблемой и какого она размера это уже беспредметный разговор и обсасывание пальцев. Дело отношения, кому и кобыла невесте.

Pgprint, это всё понятно... А при чём здесь bpn.ru к этому разговору?

@TSV, это был пример. Сайт удволетворяет вашим критериям. Сайт с не шибко большой посещаемостью, в рунете, менее 10000 страниц, но изза того что загрузка в течении 10 секунд возрасла в 30 раз оно упало. Пример того что все казалось нормальным, пока не йухнулось. Пример того что о проблеме надо помнить ДО. Просто иллюстрация того, что на html лимиты заметно выше могут быть. Пример того, как проблема которую вы считаете неважной может выстрелить в голову.

Pgprint, с чего ты (или Вы?) взял(и), что я считаю проблему неважной? Я о ней просто знаю. И знаю, когда о ней следует заботиться, а когда - не стоит.

ЗЫ. Дык что, именно этот сайт и упал? Собственно, туда ему и дорога. Мне лично он абсолютно не кажется нормальным!

устроим как оффтопик коли вы его начали. Модератор нас перенесет надеюсь. Я сам ваш последний пост перетащить не смогу.

А вот gunbroker.com по вашему как, нормальный сайт или нет?

Pgprint, не хочу ибо незачем. gunbroker.com мне пофигу. bpn.ru - ненормальный. Слишком громоздкая структура. База данных, набитая большим количеством мусора. Большая куча страниц, которые генерятся, причем "тяжелыми" выборками из базы. Короче говоря, лично для меня сайт этот просто "вопит" о том, что (а) его структуру нужно разгрузить, (б) нужно всерьез озаботиться разгрузкой сервера и оптимизацией скриптов. Тяжелый и бестолковый сайт.

@TSV, о-о-о! Это вы орлинным взором структуру базы по отдающемуся html вычисляете?
Это вы с Long обсудите лучше. Он вас юридическим вопросам поучит, вы структуру базы по html определять его научите.
А я удаляюсь.

Pgprint, удаляйтесь на здоровье. Про базу - смешно звучит.

Во-первых, бОльшую часть структуры можно вычислить действительно по отдаваемым данным, неважно, в каком они формате. В HTML, или, как в описанном случае, XHTML (почему-то англоязычный, правда ).

А во-вторых, не нужна она там почти, база эта сраная. Совсем. Но это уже ИМХО.

Ах вы не только по отдаваемым данным умеете структуру базы узнавать. Вы еще и сайты с каталогами объектов недвижимости и поисками в нем строите без базы
Ну вы, батенька, феномен (С) анекдот известный.

Pgprint, не надо бычиться! не надо важничать! Надо для начала внимательно прочитать то, что написано!

Несколько контрольных вопросов:
1. Исходя из чего строится структура базы данных?
2. Обязательна ли для сайта по недвижимости база данных?
3. Возможно ли создать эффективный сайт по недвижимости, не используя MySQL?
4. Что такое реляционная база данных и что такое сетевая?

ЗЫ. Знаний о предмете маловато у Вас, батенька!

@TSV, вот найдешь хотя бы один "эффективный сайт по недвижимости" с каталогом не использующий мускуля или чего-то аналогичного - поговорим. Что бы не рассуждать о принципиальных возможностях. Теоретик-феномен. (С) все тот же.

Pgprint, так мы на ты или на Вы? Никак не пойму.

Эффективный сайт по недвижимости? Могу предложить по климатической технике. Эффективно работает, базы не использует.

Я же говорю - бычиться не надо. Знаний у меня все равно по этому предмету больше, как собственно теоретических, так и практического опыта.

Цитата:

… пункт 1 имеет следствие: сделав модрерайт...

я рассуждаю логически. если говорите, что B есть следствие А, а С есть следствие В, то получаем, что С есть следствие А. соответственно получаем, что используя мод_реврайт при достаточно большой нагрузке сервер выпадет в даун. даже в пылу спора давайте будем говорить правильно, чтобы логика у нас не нарушалась. ок? а то исходя из вашей логики, если я не буду использовать мод_реврайт, но у меня будут динамические страницы, будет все ок.

Спасибо за таки рассуждения.
Я, конечно, не всё понял, но 20-40% усёк!
Мне до ваших знаний далеко, но зато, почитав, есть над чем подумать.