Есть ли смысл в переименовании индексного файла?

Добрый день!

Традиционно индексным файлом является index.php (index.html). Соответственно, сайт открывается по адресу http://localhost/ и по адресу http://localhost/index.php. И получается, как бы, два дублирующих адреса главной страницы, что нехорошо с поисковой точки зрения.

А с помощью DirectoryIndex мы можем сделать главной какую-то другую страницу, например main55.html. И тогда дублирования не будет.

Применяется ли это на практике?

0

да делайте как удобно, не надо чье-то мнение за эталон брать
вопрос изначально какой был? есть ли смысл переименовывания индекса, чтобы не было дубля. ответ - не имеет т.к. дубль все равно останется. собственно корень и тот индексный, в который переименовали.

всякие ситуации могут быть.
если сайт из 2х страниц, то дольше только городить будет эту единую точку входа...

еще для примера, постоянно наблюдаю сайты на wordpress, у которых та самая точка входа в виде index.php
дальше на сайт в случайное время залетает безбашенный бот, который запросов 100/сек делает.
"пробивает" наличие каких-то нужных ему скриптов/уязвимостей.
на сайте этого конечно же нет... но есть та самая единая точка входа, которая на каждый такой запрос запускает полностью wp движек только чтобы он сгенерировал 404 страницу. и делается это с выполнением десятков php скриптов и запросов к базе за эдак 0.5-1сек, нормально так нагружая cpu.
и вот в такой ситуации сайты, сделанные по старинке будут спокой-но жить на копеешном хостинге. даже не будет никто замечать этих набегов (а они происходят более чем регулярно на абсолютно любые сайты).
а владельцы модных/современных будут вынуждены повышать тариф, переезжать на vps и т.д. если конечно не знают как бороться с подобной проблемой.

или другой пример.
все тот же wordpress, но с кэширующим плагином.
у нас все как положено - чпу, точка входа в виде /index.php
но дальше при первом запросе генерируется физически папка и файл со страницой.
а все последующие web-сервер проверяет если есть такой на диске, то отдает моментально сам. а если нет, тогда уж с /index.php спрашивает.
т.е. имеем и то и то.

1

Сообщение от vlad-55 Вы делаете сайты без ЧПУ?

ЧПУ - это не обязательно "буквы". /post(s)/1234 - вполне себе ЧПУ Но буквы проще запомнить, особенно если их немного. Что мешает использовать на сайте адреса, похожие на "короткие ссылки", но осмысленные, например /proverka-gipotezy (можно и из двух частей: /work(s)/proverka-gipotezy)?

Добавлено через 5 минут
Адреса из двух частей вообще самые "ходовые", т.к. уже соответствуют REST.

Просто возьмите за правило использовать, например, /post/1234, а не /post[/]?id=1234. Вроде бы здесь очевидно, что лучше (проще). Но это не значит, что строку запроса (query string) не нужно использовать вовсе

Добавлено через 5 минут

Сообщение от estic Адреса из двух частей вообще самые "ходовые", т.к. уже соответствуют REST.

В головной части сайта у одной из коллекций можно скрывать первую часть, например /post/1234 в CMS может превратиться в /1234 в головной части сайта. Кстати, на этом примере видно, что для такого сокращения лучше подходят коллекции не с числовыми идентификаторами (в адресах), а с символьными. Вот я собрал примеры, показанные ранее на этом форуме: hyde.pageshop.ru/tables

1

Сообщение от EvgenUA но дальше при первом запросе генерируется физически папка и файл со страницой.

Мне кажется, что по такому принципу работает hostcms - пишет в базу, но создает статические файлы в папке hostcmsfiles. В каждом из этих статических файлов находится статья. Завтра надо спросить и их ТП.

0

Сообщение от vlad-55 Мне кажется, что по такому принципу работает hostcms

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

Добавлено через 5 минут

Сообщение от ft4l Индекс так и намекает вобщем-то,) что для вывода списков.

А не списки какие адреса имеют, /path/[index.php]?id=1234 что ли? Просто раньше и не списки могли в индексных файлах хранить, т.к. внутреннее перенаправление было плохо развито. Раз уж решились опуститься до индексных файлов, не нужно себе изменять: /collection/item/[index.php] Т.е. нужно "разбрасывать" индексные файлы по всем каталогам. Они могут быть однообразными и представлять собой просто точки входа для какого-то общего, подключаемого в них, кода.

Сообщение от ft4l у меня тут в компе просто россыпи статики открыто доступны и один индексный php для всех хостов/location

У меня на домашнем сервере тоже достаточно статики. Но она вся "описана" в базах данных. Каталог домашних хостов сделан на парковочном скрипте, который может обеспечивать работу не только этого каталога, но и других хостов. Однако другие хосты обычно все-таки работают на другом ПО.

1

Сообщение от estic ?id=1234 что ли?

я так и не остановился на чём-то одном чвще монолитный микс какой-то, дажу если после ?
а потом опцмонально обычные пары xxx=yyy, если захочется .)
то /?xxx-xxx-xxx-000-000-000 т.е. порядок сначала слова, если есть, потом числа, если есть
то /?xxx-000-xxx-000.000 т.е. числа к слову
то ещё как-то ) хоть со слешами, хоть с какими одинаковыми или разными разделителями и без

Разобрать на нужное так-то никогда не проблема... бывает потом проблема с замисованием разного для разных ссылок.
От аналогов http_build_query() до порой того, что вообще лютый writeonly-код
написал, проверил, и перестал понимать ) но всё с упором на быстродействие

Сообщение от estic в базах данных

Тоже бывало... для fulltext-индекса на несколько гигов сканировал текст
... местами пытался для добавления keyword-ов к страничкам статики всплывающие формы на лету добавлять.
Но как-то времени не всегда... даже на использование. ... и устаревает уж многое, а поддножание тоже время.
Спартанский вариант всё больше... нож,штаны,тапки и нет подушки )

0

Ну если уж прям докапываться, то дублей намного больше двух
http://localhost/index.php
http://localhost/index.php?param1=arg1
http://localhost/index.php?param2=arg1

ну и т.д.

Поэтому в коде страницы нужно указывать "оригинал" адреса страницы через тэг canonical

0

Сообщение от Alex1126 Ну если уж прям докапываться, то дублей намного больше двух

Здесь может не быть вообще ни одного дубля - все три страницы могут иметь разный контент.

Сообщение от estic Называется "полностраничным кэшем в файлах

Очевидно, что это возможно только для статических файлов. А если на странице предусмотрены комментарии?

Кстати, РНР совсем не будет нагружаться, если будут классические адреса страниц. Типа new.html

0

Сообщение от vlad-55 все три страницы могут иметь разный контент.

могут... но будут-ли
я проверил ,) к адресу этой страницы добавил ещё... получилось что-то типа thread3205172-page2.html?cyber-pipiber
контент тот же

0

Сообщение от ft4l могут... но будут-ли

Так это от разработчика зависит - если сделаете контент, зависящий от динамического адреса, то он и будет разный.

0

Сообщение от Alex1126 Поэтому в коде страницы нужно указывать "оригинал" адреса страницы через тэг canonical

А я вот часто не использую canonical, т.к. нет нужды:
hyde.pageshop.ru/index.php
hyde.pageshop.ru/index.php?param1=arg1
hyde.pageshop.ru/index.php?param2=arg1

Обычно даже сложные случаи блокируются (или корректируются) наподобие hyde.pageshop.ru/? (вопросительный знак в конце пути).

0

Сообщение от estic А я вот часто не использую canonical

А я использую canonical всегда и делаю это на автомате.

0

Сообщение от vlad-55 Очевидно, что это возможно только для статических файлов. А если на странице предусмотрены комментарии?

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

А в плане адресации, например наличия строки запроса (query string) или отсутствия расширения имени файла в адресе, больших проблем нет. Кэширование, естественно, может работать не только за счет Web-сервера или его модулей, но и другого посреднического ПО. А для файловой системы запрашиваемый адрес можно преобразовывать, например кэш /page?p=1234 считывать из /cache/page#1234

Добавлено через 4 минуты

Сообщение от vlad-55 А я использую canonical всегда и делаю это на автомате.

Это понятно. Вы не имеете хороших средств защиты от появления дублирующихся страниц. Т.е. в данном случае без canonical и шага нельзя сделать.

0

Сообщение от vlad-55 если сделаете контент, зависящий от динамического адреса

Тут скорее: если не сделаете отлуп всех адресов которые не из тех которые хотите разрешать.
... в смысле выводы 404,редиректы и всё такое... не без напрягов и не 100% на ранних стадиях выявляется.
Но мало кто таким заморачивается... пусть хоть "войну и мир" по частям шлют... нужное в адресе есть, welcome.
Так что Alex1126 дельное замечанние сделал...
хотите помочь поисковым ботам, на случай появления в сети тучи нецензурных ссылок , делайте canonical )
и query_sttring a=1?&b=2 ничем не лучше b=2&a=1 ... практически... но canonical надо один
с /a1/b2/ больше вероятность что обратного варианта просто нет... но в query_sttring чаще любое пролезает

... попробовал сейчас thread3205172-page3.html, редиректит на page2.html но это другое... по делу и на поздней стадии.)
несуществующий thread - 404 , без canonical ))

0

Сообщение от estic Вы не имеете хороших средств защиты от появления дублирующихся страниц.

Не совсем так.
Моя платформа не плодит дубликатов в принципе, она просто не может этого сделать. Но наличие canonical на странице расценивается поисковиками как плюс к качеству сайта. И я не стал от этого отказываться.

0

Сообщение от vlad-55 Здесь может не быть вообще ни одного дубля - все три страницы могут иметь разный контент.

могут, но если не будут, то это будет дубль

0

Сообщение от vlad-55 Моя платформа не плодит дубликатов в принципе, она просто не может этого сделать.

Тогда зачем нужна эта тема?

Сообщение от vlad-55 Но наличие canonical на странице расценивается поисковиками как плюс к качеству сайта.

Нет такого критерия. На это могут указать только какие-то автоматические анализаторы сайтов или сами "SEO-специалисты", использующие или не использующие такие анализаторы.

Добавлено через 5 минут
Они просто "угадывают", т.к. без canonical проблемы будут у многих.

0

Сообщение от estic Они просто "угадывают", т.к. без canonical проблемы будут у многих.

Проблемы у кого? У посетителей сайта или у владельцев сайта?

0

Сообщение от Инженер_3 Проблемы у кого? У посетителей сайта или у владельцев сайта?

У владельцев в плане SEO. Если много ссылок на сайте ведет на один и тот же контент - значит будут проблемы. Что бы их не было - применяют атрибут rel="canonical"
Вот для примера новый адрес страницы на которой мы сейчас общаемся https://www.cyberforum.ru/apache/thread3205172-page2.html?re=re-re И эта страница выдаёт тот же контент.

0

Сообщение от black1385 У владельцев в плане SEO. Если много ссылок на сайте ведет на один и тот же контент - значит будут проблемы. Что бы их не было - применяют атрибут rel="canonical" Вот для примера новый адрес страницы на которой мы сейчас общаемся Есть ли смысл в переименовании индексного файла? И эта страница выдаёт тот же контент.

А зачем делать сотни ссылок с разными параметрами на одну страницу?
Или думают, что поисковые роботы поднимут страницу выше - так проще использовать <h1> и title

0

Сообщение от Инженер_3 А зачем делать сотни ссылок с разными параметрами на одну страницу?

Это могут делать конкуренты и размещать эти ссылки на своих фейковых сайтах. Поисковики будут эти ссылки индексировать, а проблемы будут у тебя.

0