Как лучше сделать короткие адреса и структуру сайта

12 3
Independence
На сайте с 29.10.2005
Offline
428
1806

На сайте желательно сделать адреса вида: domen.com/3429012 ; в том числе чтобы было просто ссылаться на его страницы.

Но дело в том, что таких адресов там не 1, не 2, и даже не 100, а скорее всего счет будет идти на тысячи, может и на десятки тысяч (ну на сотни адресов точно поначалу). (желательно чтобы было: domen.com/3429012; а не domen.com/3429012.html - но такой вариант проще)

Насколько я понимаю, один из вариантов - сделать через htaccess; и я делал через htaccess уже подобные вещи, но там не было так много страниц, которые бы к нему обращались (и не было, что весь сайт через записи в htaccess работает). Через htaccess будет нормально все работать и несколькими строчками в нем можно это сделать, или это может слишком напрягать сервер, будут возникают какие-то глюки, и лучше сделать как-то по-другому? А может лучше вообще отказаться от этой идеи.

В принципе вопрос может быть и по структуре, у каждой страницы будет свой текст и свои картинки. Для каждого адреса вида domen.com/3429012 лучше свою отдельную папку создавать типа /3429012/ , где и хранить все содержимое для каждого такого адреса? И опять же это получится нужно тысячи папок на сервере сделать будет. Или лучше сделать как-то иначе. То есть общую папку с html-файлами (где будут только html-файлы), общую папку с картинками (где будут только картинки для этих html-страниц) и т.п.

Russ1an
На сайте с 25.03.2015
Offline
60
#1

У вас сайт на чистом html? Если планируете такое количество страниц, то лучше ипользовать движок, там можно и такие урлы сделать.

Достойный дом для любимых проектов https://clck.ru/PT7Vo
M
На сайте с 04.12.2013
Offline
223
#2

Забудьте уже про 90-ые. Опирайтесь на более современные понятия и используйте более современные решения, например: Короткие ссылки средствами G-Drive – вместо редиректов в корневой таблице можно разместить страницы и даже первое, второе и еще что-то третье и т.д. одновременно (хотя обычно в корне находятся сущности одного типа, не считая узловых элементов других типов).

В принципе вопрос может быть и по структуре, у каждой страницы будет свой текст и свои картинки. Для каждого адреса вида domen.com/3429012 лучше свою отдельную папку создавать типа /3429012/ , где и хранить все содержимое для каждого такого адреса?

Это вполне нормально. Адреса не конфликтуют между собой: /3429012 и /3429012/обвес – что еще размещать для обвеса в узле, как не страницу, к кот. этот обвес относится. Например, в админке для упомянутого выше фронта дефолтом используется такая адресация для обвеса:

/files/3429012/обвес

/images/3429012/обвес

И опять же это получится нужно тысячи папок на сервере сделать будет.

Это да. Можно все смешать в одной папке или как-то делить на группы, размещая файлы отдельных групп в разных папках.

То есть общую папку с html-файлами

Про это вообще забудьте. Данные страниц размещаются в БД, а если нужен какой-то статичный кэш, то к примеру /cache/3429012.html, но это не «адреса» для пользователей.

Домены и скрипт для коротких ссылок: https://u75.ru/domains-for-shortcuts
Independence
На сайте с 29.10.2005
Offline
428
#3
Russ1an:
У вас сайт на чистом html? Если планируете такое количество страниц, то лучше ипользовать движок, там можно и такие урлы сделать.

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

Как будет сделан сайт, я сейчас думаю (поэтому эту тему и открыл); вполне возможно, что часть контента будет на .html; но однозначно, что и интерактив тоже будет (должна быть поисковая система по различным параметрам, как минимум; в идеале стоит сделать возможность пользователям-клиентам самостоятельно добавлять/редактировать информацию и добавлять фотки, но я не исключаю, что можно сделать это и так, что все это будет делаться владельцем сайта (для пользователей, правда, это менее удобно будет); ну и еще должна быть система регистрации на сайте и приема платежей, опять же если делать не допотопный вариант (вот мой Paypal или счет в банке, переводите деньги туда), а интерактив; правда, это зависит и от количества пользователей-клиентов, если их будет не очень много, то может быть можно вполне работать "допотопно", не заморачиваясь на эти вещи типа авторедактирования контента и автоматического приема платежей и продления услуги).

В принципе база, по которой ведется поиск и соответствующие ей .html-страницы при этом могут существовать отдельно.

Опять же, при желании из любой базы можно нагенерировать статичных .html-страниц, если чистый .html предпочтительнее, чем работать через запросы к базе данных.

PS: на сайте будут пользователи-клиенты и пользователи-посетители, которым интересна информация от первых; ну в общем, это похоже на проекты, где производители предлагают свои товары (им нужна возможность размещать информацию о них, их фотки, цены и пр.), а посетители интересуются этими товарами, их описанием, ценами и контактными данными производителей;

пользователи-клиенты сайта - это первые; пользователи-посетители сайта - это вторые;

PPS: на следующий коммент отвечу позже, после изучения ссылок и пр.;

S
На сайте с 30.09.2016
Offline
469
#4
Independence:
в состоянии написать движок самостоятельно под данный проект

И в чём тогда проблема? Нужна-то всего лишь таблица соответствий - либо в виде файла, либо в виде записей в БД, - MySQL или аналогичной.

Отпилю лишнее, прикручу нужное, выправлю кривое. Вытравлю вредителей.
Russ1an
На сайте с 25.03.2015
Offline
60
#5

Достаточно странные вопросы для человека, который способен написать движок.

[Удален]
#6
Independence:
domen.com/3429012.html

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

2. указание расширения у файла помогает избежать кучи технических проблем, при обработке url js скриптами на стороне клиента

Independence
На сайте с 29.10.2005
Offline
428
#7
Sitealert:
И в чём тогда проблема? Нужна-то всего лишь таблица соответствий - либо в виде файла, либо в виде записей в БД, - MySQL или аналогичной.

Естественно, будет база данных. Но вопрос, как лучше сделать короткие адреса на сайте и распределять(хранить) данные на сервере, остается.

S
На сайте с 30.09.2016
Offline
469
#8
Independence:
вопрос, как лучше сделать короткие адреса на сайте и распределять(хранить) данные на сервере, остается.

Короткие адреса - как решите, так и сделаете. А способ хранения данных не зависит от наличия или отсутствия коротких адресов.

Independence
На сайте с 29.10.2005
Offline
428
#9
Russ1an:
Достаточно странные вопросы для человека, который способен написать движок.

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

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

Другая проблема, с которой я столкнулся, это атаки на один из сайтов и проектов. Из-за сложностей с ноутбуками и невозможности на них какое-то время работать, и из-за др. сложностей, я меньше стал следить за сайтами, и что на них происходит. Один из сайтов взломали, были попытки взлома e-mail, который используется как контактный для доменов. Домены возможно хотели увести. На сайте произошло то, что там залили в одну из папок какие-то левые html-страницы, переправляющие на левый адрес. Ну и там вопрос в том, что я не совсем определил, где проблема. То есть это у хостера где-то дыра есть, или где-то в коде скриптов, или еще в чем-то проблема, и как это произошло.

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

Еще, когда программируешь что-то, то все же прибегаешь и к тому, что другие сделали тоже. Напр., если говорить о сессиях, то есть модуль CGI::Session, можно, конечно, писать код для сессий самому, но можно использовать такого типа модули. Ну и да, подозрение было и на то, и довольно серьезное, что дырка может быть в этом или еще каком-то модуле, который писал не я, но который в проекте используется.

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

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

---------- Добавлено 13.09.2018 в 18:53 ----------

burunduk:
1. было заявление гугла, что подобные имена (набор цифр) ухудшают пользовательский опыт
2. указание расширения у файла помогает избежать кучи технических проблем, при обработке url js скриптами на стороне клиента

Такой адрес типа domen.com/3429012 пользователи могут давать в т.ч. где-то в социальных сетях (Facebook, Twittier и пр.), хотя возможно это и не столь важно в данном случае. Этот адрес скорее всего будет наноситься на фотку (если не на все, то хотя бы на одну - титульную); и адрес на фотке/картинке типа "domen.com/3429012" мне кажется выглядит лучше, чем "domen.com/3429012.html" и тем более лучше, чем какие-то более длинные адреса; к тому же он и короче.

Я смотрю, как сделано на некоторых др. проектах в этой сфере и не только. Там у них есть некий ID у страниц/объявлений, есть возможность поиска и по ID, кстати. У одного из проектов сделано так, что есть что-то типа короткого адреса типа "website.com/74833728", опять же, чтобы люди могли отправить кому-то короткую ссылку (на картинки они кажется адрес этот не наносят), но при указании этого адреса в строке браузера перекидывает на страницу типа "website.com/data.php?showid=74833728"

Мне такая адресация, при том, что короткие адреса у них в какой-то степени есть, не нравится.

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

И что я скорее всего сделаю свою систему адресации страниц сайта. Я не знаю, что за ID используют другие сайты в этой области (и вообще сайты), возможно это какой-то рандомный (или последовательный) ID, который выставляется страницам(объявлениям) и какой-то смысловой нагрузки эти ID не несут (я не нашел в них этого). Я в качестве одной из опций проекта думаю использовать систему осмысленных адресов (скорее всего цифровых).

Ну напр., можно на сайте у страниц иметь адреса вида - site.com/Russia/Kalmykiya/Elista/Tovar1.html - и для гугла, и для пользователей это очень наглядно, но это довольно длинный адрес получается (а если это вообще город типа Екатеринбурга или Красноярска, где еще каким-то образом нужно название области прописать в адресе). Можно вместо этого использовать код региона, индекс, или др. систему адресации. У товаров возможно ГОСТ есть, артикул и пр., который цифровой и так далее. Т.е. на сайте будет не site.com/Mebel/Kresla/Tovar1.html, а тоже может быть что-то типа цифрового адреса. Эти примеры без указания конкретной темы; а что так можно сделать.

Суть еще в том, что пока я не предполагаю, что все будет пущено на самотек, то есть мы создаем клиентам что-то типа CMS, а они уже сами как хотят, так на сайт информацию и добавляют, редактируют и пр. (т.е. пополняют и редактируют нашу базу данных). Я склоняюсь к тому, что с ними будет довольно активное взаимодействие по информации, которая будет публиковаться. Т.е. и адрес будет не абы как генератором выставляться, а он будет выдаваться по некоторому алгоритму. Также скорее всего будут выставляться свои теги под каждым объявлением(страницей), соответственно будет поиск не только по полям в базе данных (там будет довольно расширенный поиск, которого нет на других сайтах), но и поиск по тегам, будут прописываться правильные вещи в плане поисковой оптимизации, и пр., пр. - это будет делаться силами нашего сайта, а не клиентами, которые в этом возможно не разбираются. Это также позволит держать сайт оптимальным по содержанию, без лишнего информационного мусора, чтобы клиенты не набивали свои страницы лишней и посторонней информацией. К дизайну скорее всего это тоже относится. И т.д. все расписывать не буду и это уже посторонняя информация не по теме.

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

M
На сайте с 04.12.2013
Offline
223
#10

Independence, обычно, когда используют числовые id, добавляют осмысленный слаг перед ними, например /posts/100500.

12 3

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий