Должно ли это быть /about_us или /about-us?
С точки зрения удобства использования я лично считаю, что /about-us намного лучше для конечного пользователя, но Google и большинство других веб-сайтов (и фреймворки javascript) используют шаблон именования underscore. Это просто вопрос стиля? Есть ли проблемы совместимости с тире?
Это всего лишь предположение, но, похоже, они выбрали тот, который люди, скорее всего, не будут использовать в имени. Таким образом, вы можете иметь имя, которое включает в себя дефисное слово, и по-прежнему использовать подставку в качестве разделителя слов, например. UseTwo-wayLinks можно преобразовать в use_two-way_links.
В вашем примере /about -us будет каталогом с именем переносимого слова "about-us" (если бы такое слово существовало, а /about _us было бы каталогом с двухсловной фразой "о нас", преобразованной в одна строка небелых символов.
Из Центра Google для веб-мастеров
Рассмотрите возможность использования пунктуации в вашем URL-адрес. URL-адрес http://www.example.com/green-dress.htmlдля нас гораздо полезнее, чем http://www.example.com/greendress.html. Мы рекомендуем использовать дефисы (-) вместо подчеркивания (_) в вашем URL-адрес.
Это не просто тире против подчеркивания:
Google не рассматривал подчеркивание как разделитель слов в прошлом, что, по моему мнению, было довольно сумасшедшим, но, видимо, сейчас. Из-за этой истории тире предпочтительнее. Несмотря на то, что подчеркивания теперь разрешены с точки зрения SEO, я все же считаю, что тире являются лучшими.
Одно из преимуществ заключается в том, что ваш средний полу-компьютер-неграмотный веб-серфер гораздо чаще может набирать тире на клавиатуре, они могут даже не знать, что такое подчеркивание.
Вот несколько моментов в пользу тире:
Я всегда использовал подчеркивания, теперь я использую их только для частей веб-сайта, которые я не хочу, чтобы кто-либо напрямую связывал файлы js, css,... и т.д.
С точки зрения SEO, тире, кажется, предпочтительный способ обработки, для подробного объяснения, от уст лошадей http://www.mattcutts.com/blog/dashes-vs-underscores/.
Другая проблема, которая, кажется, встречается чаще, чем у программистов, заключается в том, что когда подчеркивается гиперссылка с подчеркиваниями, вы не можете видеть символ подчеркивания. Продвинутые пользователи будут работать, но Joe Public, вероятно, не будет.
По-прежнему используйте символы подчеркивания в коде, предпочитая тире, хотя программисты понимают их, большинство других людей этого не делают.
У Джеффа есть некоторые мысли по этому поводу: http://www.codinghorror.com/blog/archives/000574.html
У обоих есть недостатки. Я бы посоветовал вам выбрать один и быть последовательным.
Гуру SEO Джим Вестергрен проверил это еще в 2005 году с строгой точки зрения SEO и пришел к выводу, что + (плюс) на самом деле лучший разделитель слов. Однако это не кажется разумным и может быть связано с ошибкой в алгоритмах поисковых систем. Он рекомендует - (тире) как для удобочитаемости, так и для SEO.
Мне больше нравится подчеркивание. Прежде всего, они совпадают с моим обычным опытом программирования variable_names_are_not-subtraction, во-вторых, и я считаю, что это уже упоминалось, слова могут иметь дефисы, но у них никогда не бывает подчеркивания. Чтобы выбрать действительно глупый пример, "страна национального государства" отличается от "страны национального государства". Первый переводит что-то вроде "земли национальных государств" (подумайте "это здесь страна пистолета! Лучше двигаться дальше, y'hear?" ), Тогда как последний выглядит как список когда-то синонимов. http://example.com/nation-state-country/, как представляется, не означает то же, что и http://example.com/nation-state_country/, и все же, если дефисы являются разделителями/ "пробелами" в дополнение к символам в словах, это может быть. Последнее кажется более ясным относительно фактической цели, тогда как первое похоже больше похоже на этот список, если что-нибудь.
Подчеркивает замену пробелов, где пробелы недопустимы. Черточки (дефисы) могут быть частью слова, поэтому объединение слов с дефисами, которые уже включают дефисы, является уродливым/запутанным.
Плохо:
/low-budget-movies
Хорошо:
/low-budget_movies
Я думаю, что тире лучше с точки зрения пользователя, и это не будет мешать SEO.
Не знаете, где и почему было подписано соглашение о подчеркивании.
Немного более знающий обсуждение
Я предпочитаю тире на основе того, что подчеркивание может быть скрыто в какой-либо степени по ссылке подчеркивания. Текстовые URL-адреса в основном предназначены для распознавания с первого взгляда, а не для правильной грамматики, поэтому аргумент сохранения тире для использования в переносимых словах ограничен.
Если точность текстового URL важна, это когда вы читаете его кому-то, и в этом случае вы не хотите путать подчеркивание для пробела (или наоборот).
A также находит тире более эстетично, если это что-то важно.
Лично я бы избегал использовать about-us или about_us и просто использовал.
Для просмотра конечным пользователем я предпочитаю "about-us" или "about us" not "about_us"
У некоторых старых веб-хостинга и DNS-серверов на самом деле возникают проблемы с разбором символов подчеркивания для URL-адресов, поэтому они могут участвовать в таких соглашениях.
Я лично избегал бы всех тире и подчеркиваний и выбирал camelCase или PascalCase, если его в коде.
Статья в Википедии о camelCase объясняет некоторые причины ее истоков. Они составляют
Если пользователь увидит строку, я не сделаю ничего из вышеизложенного и не буду использовать "О нас". или "AboutUs", если я должен был, поскольку camelCase распространился на обычное использование в некоторых областях, таких как имена продуктов. i.e ThinkPad, TiVo
В URL-адресах разрешены пробелы, поэтому вы можете просто использовать "/о нас" в ссылке (хотя это будет закодировано до "/about %20us". Но, честно говоря, это всегда будет личное предпочтение, поэтому есть нет реального ответа на этот вопрос.
Я бы согласился с тем, что тире могут появляться в словах, поэтому пробелы должны быть преобразованы в символы подчеркивания.
Лучше использовать. -/как разделители, потому что _, кажется, не является разделителем.
http://www.sistrix.com/blog/832-how-long-may-a-linktext-be.html