일부 웹 사이트에서 URL 끝에 "슬러그"를 추가하는 이유는 무엇입니까? [닫은]

111

이 웹 사이트를 포함한 많은 웹 사이트 는 URL 끝에 슬러그 ( 설명 적이지만 쓸모없는 텍스트를 말할 수있는 한)라고하는 것을 추가합니다.

예를 들어 사이트에서이 질문에 대해 제공하는 URL은 다음과 같습니다.

/programming/47427/why-do-some-websites-add-slugs-to-the-end-of-urls

그러나 다음 URL도 잘 작동합니다.

/programming/47427/

이 텍스트의 요점은 URL을보다 사용자 친화적으로 만드는 것입니까, 아니면 다른 이점이 있습니까?

url  seo  friendly-url  slug 
— 데이브 웹
소스
44
슬러그는 URL의 발신자 ID 이름 역할을합니다. 전화를받을 때 그 사람의 이름을 알 필요는 없지만 전화를 받을지 여부를 결정하는 데 도움이됩니다. 마찬가지로 URL 슬러그는 사용자가 링크를 클릭할지 여부를 결정하는 데 도움이되고 고유 한 컨텍스트를 제공합니다.
— Armstrongest
4
^^ +1,하지만 댓글이 아닌 답변으로 답글을 보는 것이 더 좋았을 것입니다 ..
— Dienekes
검색 엔진 결과의 순위에 도움이됩니다.
— Jay Smoke
stackoverflow.com/q/47427 도 작동합니다. : P
— Habeeb Perwad

답변:

166

슬러그는 URL을보다 사용자 친화적으로 만들고 링크를 클릭 할 때 예상되는 사항을 알고 있습니다. Google과 같은 검색 엔진은 검색 단어가 URL에 있으면 페이지 순위를 더 높입니다.

— Espo
소스
3
URL을 사용자에게 친숙하게 만드는 것 중 하나는 '검색 가능성'입니다. 즉, 주소 표시 줄에서 URL을 추측 할 수 있습니다. i.love.pets.com/search/cats+dogs 는 쉽게 i.love.pets.com/search/pug+puppies 등으로 이어질 수 있습니다
— Xian
12
시안, 이전에 그 주장을 들어 본 적이 있지만 조사 할 필요가 없다고 생각합니다. 괴짜를 제외하고 실제로 URL을 직접 입력하는 사람은 거의 없습니다. 가독성은 확실히 중요하며 점점 더 많은 사용자 가 URL을 보는 것 같지만 "추측"에 관해서는 소수가 극히 적다고 생각합니다.
— 눈꺼풀 없음 2009-06-02
4
@eyelidlessnes-나는 동의하지 않을 것입니다. 사람들이 URL을 수동으로 입력하지 않을 수도 있지만 URL을 생성한다는 증거를 보았습니다. 로그와 모니터링 장치를 살펴보면 하나의 사용자 세션이 어떤 작업을 수행 한 다음 URL을 수정하는 샘플을 볼 수 있습니다 (레퍼러 부족으로 입증 됨). 물론 모든 사람이 그렇게하는 것은 아니지만 트래픽의 양이 무시할 수있는 정도는 아닙니다.
— Joseph Ferris
@Xian. 예, URL 유형은 거의 없지만 슬러그는 본질적으로 호출자 ID입니다. 발신자의 이름은 필수는 아니지만 전화를 받을지 여부를 결정하는 데 도움이됩니다. 슬러그는 URL을보다 친숙하게 보이게하고 사용자가 URL을 클릭 할 가능성을 높입니다.
— Armstrongest
xian, 정확히 google.com/search?q=cat+puppy와 어떻게 다릅니 까? URL을 발견하는 사람들은 그렇게 할 것입니다. 나는 그것을한다.
— netrox
39

유용성은 하나의 이유입니다. 전자 메일에서 해당 링크를 받으면 무엇을 기대해야하는지 알 수 있습니다. SEO (검색 엔진 최적화)는 또 다른 이유입니다. Google과 같은 검색 엔진은 URL에 포함 된 키워드에 대해 페이지 순위를 높입니다.

— Michiel van Oosterhout
소스
2
Google이이 결정을 내린 이유가 무엇이라고 생각하십니까? 그 동기는 무엇입니까?
— Mike Clark
키워드가 URL에 포함 된 경우 페이지 순위가 더 높아진다는 Google 문서를 찾을 수 있습니까?
— chainwork 2011-07-05
@chainwork 아니요,하지만 검색 엔진이 페이지 순위를 매기는 데 사용하는 수백 개의 신호가 있으며 URL이 그러한 신호 중 하나임을 확신 할 수 있습니다.
— Michiel van Oosterhout
2
검색과 일치하는 URL의 키워드는 Google 결과에서 굵게 표시되어 검색을 수행하는 사용자에게 더 눈에 띄게합니다.
— chainwork
35

최근에 내 웹 사이트 URL 형식을 다음에서 변경했습니다.

www.mywebsite.com/index.asp?view=display&postid=100

에

www.mywebsite.com/this-is-the-title-of-the-post

변경 후 기사 클릭률이 약 300 % 증가했습니다. 변경 후 거의 영향을 미치지는 않았지만 SEO 목적 측면에서 사용자가 클릭하려는 것이 관련성이 있는지 여부를 결정하는 데 확실히 도움이됩니다.

— 케이티
소스
4
나는 당신의 포스트 제목이 결코 변하지 않기를 바랍니다. 많은 사람들이 죽은 링크와 그것들을 생성하는 웹 서비스를 싫어합니다.
— Nikita Rybak
6
그가 어떤 CMS 나 블로깅 소프트웨어를 사용하고 있는지 짐작할 수는 없지만, WordPress와 많은 유사한 소프트웨어의 경우 게시물이 이미 게시 된 후 게시물 제목을 수정해도 슬러그가 변경되지 않습니다 (그리고 정확히 언급 한 이유).
— Cyde Weys 2012
25

나는 잘못 입력 된 슬러그가 적절한 양식으로 301 리디렉션되어야한다는 다른 응답에 동의합니다. 즉,로 /programming/47427/wh리디렉션되어야합니다 /programming/47427/why-do-some-websites-add-slugs-to-the-end-of-urls. 언급되지 않은 또 다른 이점이 있습니다. 표준 URL로 리디렉션하지 않으면 거의 무한한 수의 중복 페이지가있는 것처럼 보입니다. Google은 중복 콘텐츠를 싫어합니다.

즉, 리디렉션하는 한 콘텐츠 ID에만 신경을 쓰고 슬러그에 대한 입력을 허용해야합니다. 왜?

/programming/47427/why-do-some-웹 사이트 -URL 끝에 슬러그 추가

... 죄송합니다. 메일 소프트웨어가 URL 끝을 잘랐습니다! 그래도 문제 없습니다./programming/47427

이 접근 방식 의 한 가지 큰 문제는 콘텐츠 제목에서 슬러그를 추출하는 경우 ASCII가 아닌 UTF-8 제목을 어떻게 처리 할 것인가?

— 코리 R. 킹
소스
1
좋은 게시물, 매우 유효한 포인트! +1 귀하의 질문에 "비 ASCII, UTF8 타이틀을 어떻게 처리 하시겠습니까?" 예를 들어 WordPress에서 사용하는 알고리즘이 있습니다. 600 자 이상이 허용되면이 정확한 문제에 대한 PHP 솔루션을 게시 할 것입니다. 정말로 알고 싶다면 질문으로 게시 해 주시면 기꺼이 답변 해 드리겠습니다;)
— Mathias Bynens 2009
1
re : "거의 무한한 중복 페이지 수"-비표준 URL에 대한 링크가있는 경우에만 발생합니다. 사이트 내에서 일관성을 유지하면 문제가 없어야합니다. URL이 잘리는 것에 대한 당신의 이론은 좀 어리석은 것입니다. URL은 어디에서나 잘릴 수 있습니다. 4742 이후에도 다른 질문으로 이어질 것입니다. URL에서 발생할 가능성이 적은 표준 문자, 숫자, 대시 및 / 또는 밑줄 만 고수하는 한.
— DisgruntledGoat
2
DisgruntledGoat가 제안했듯이 Google은 누군가가 다른 슬러그로 페이지에 링크하지 않는 한 기술적으로 중복 콘텐츠를 찾지 못하므로 Google 스파이더를 속여 중복 콘텐츠가 있다고 생각합니다. 거미가이 페이지를 싫어합니다 그래서, 방법은 사람을 이동)
— Austyn 마호니에게
기술적으로 페이지에 rel = "canonical"힌트를 삽입하는 경우 301 리디렉션을 수행 할 필요가 없습니다. "거의 무한한 중복 페이지 수"에 관계없이 Google은 유효한 유일한 표준 URL을 사용합니다. Amazon은 301을 수행하지 않습니다. 시도해보십시오 : amazon.com/lat-thinking-stragies/dp/0470942185 그러나 둘 다 수행하는 것이 좋습니다. 이유는 누군가가 완전히 수정 된 슬러그로 링크를 게시 할 수 있고 뷰어가이를 읽을 때 콘텐츠와 다르게 보이기 때문에 뷰어를 혼란스럽게합니다.
— 에단
"비 ASCII, UTF8 타이틀을 어떻게 처리 할 건가요?" 당신은 그것들을 퍼센트 인코딩합니다. 모든 최신 브라우저는 주소 표시 줄에 다국어 글로리 유니 코드를 실제로 표시하지만 클립 보드에 복사 할 때 ASCII, 퍼센트 인코딩 URL을 제공합니다.
— Stijn de Witt
14

대부분의 사이트에서 사용하는 이유는 아마도 SEO (검색 엔진 최적화) 일 것입니다. 야후는 URL 자체에서 검색 키워드의 존재에 합리적인 가중치를 부여했으며 Google 결과에도 도움이되었습니다.

최근에 검색 엔진은 URL의 키워드에 부여 된 가중치를 낮췄습니다.이 기술은 이제 합법적 인 것보다 스팸 사이트에서 더 일반적이기 때문일 것입니다. 이제 URL의 키워드는 검색 결과에 아주 작은 영향 만 미칩니다.

스택 오버플로 자체의 경우 SEO는 동기 부여 (오래된 습관은 힘들어 짐)이거나 단순히 사용성을위한 것일 수 있습니다.

— DGentry
소스
SEO가 요인입니다. 그러나 더 중요한 것은 당신이 말한 것처럼 사용성에 관한 것입니다.
— Armstrongest
14

기본적으로 리소스에 대해 더 의미있는 위치입니다. ID를 사용하는 것은 완벽하게 유효하지만 사람보다 기계에 더 많은 것을 의미합니다.

엄밀히 말하면 슬러그가 고유 한 경우 ID가 필요하지 않아야합니다. 날짜 내에서 범위를 지정하여 고유 한 슬러그를보다 쉽게 ​​확인할 수 있습니다.

즉 :

/2008/sept/06/why-some-websites-add-slugs-end-of-urls/

기본적으로 이것은 동일한 날에 두 개의 동일한 슬러그가 사용되는 낮은 가능성을 이용합니다. 충돌이있는 경우 일반적인 규칙은 슬러그 끝에 카운터를 추가하는 것이지만 다음과 같은 경우는 거의 없습니다.

/2008/sept/06/why-some-websites-add-slugs-end-of-urls/
/2008/sept/06/why-some-websites-add-slugs-end-of-urls-1/
/2008/sept/06/why-some-websites-add-slugs-end-of-urls-2/

많은 슬러그 알고리즘은 또한 URL을 짧게 유지하는 데 도움이되도록 "the"및 "a"와 같은 일반적인 단어를 제거합니다. 이 범위 지정 접근 방식을 사용하면 지정된 일, 월 또는 연도의 모든 리소스를 매우 간단하게 찾을 수 있습니다. 세그먼트를 잘라내기만하면됩니다.

또한 stackoverflow URL은 슬러그를 특징으로하기 위해 추가 세그먼트를 도입한다는 점에서 좋지 않습니다. 이는 각 세그먼트가 내림차순 리소스 계층을 나타내야한다는 생각을 위반하는 것입니다.

— 앤드류 잉그램
소스
11

슬러그라는 용어는 신문 / 출판 사업에서 유래되었습니다. 진행중인 스토리를 식별하는 데 사용되는 짧은 제목입니다. URL 의미론에 관심이있는 사람들은 URL에 짧은 축약 된 제목을 사용하기 시작했습니다. URL의 키워드가 페이지에 중요성을 더하기 때문에 SEO 영역에서도 효과가 있습니다.

아이러니하게도 많은 웹 사이트가 엄격하게 SEO 목적을 위해 URL에 제목 의 전체 직렬화 된 하이픈 버전을 배치하기 시작했습니다 . 이는 슬러그라는 용어가 더 이상 적용되지 않음을 의미합니다. 이것은 또한 많은 구현이 URL 끝에이 직렬화 된 버전의 제목을 붙이기 때문에 의미 론적 순수 주의자들의 순위를 매 깁니다.

— 앨런 스톰
소스
10

텍스트를 자유롭게 변경할 수 있습니다. 이 URL도 잘 작동하는 것 같습니다.

/programming/47427/why-is-billpg-so-very-awesome

— Billpg
소스
이런 종류의 버그 또는 기능입니까?
— Jakub Šturc
4
사실 제목이 수정 된 후에도 게시물에 액세스 할 수 있도록합니다 (따라서 새 URL이 있음).
— Dirk Vollmar
3
그러나 이상적으로는 각 인터넷 리소스 ( '문서')에는 URI가 하나만 있습니다. 따라서 기본적으로 동일한 문서를 다른 URI를 통해 볼 수 있도록 허용하면 SERP의 사이트에 부정적인 영향을 미칠 수 있습니다. 이것은 아마 내가 스택 오버플로에 대한 좋아하지 않는 유일한 일)
— 마티아스 Bynens
3
이것이 표준 페이지가 존재하는 이유이며 Stack Overflow는이를 사용합니다. =)
— Alix Axel
4
@Alix Axel : 301은 >표준 페이지를 리디렉션 합니다
— Mathias Bynens
6

이미 언급했듯이 '슬러그'는 사람과 검색 엔진을 돕습니다 ...

주목할 가치가있는 것은 페이지 소스에 표준 URL 이 있다는 것입니다.

이렇게하면 페이지가 여러 번 색인되는 것을 중지합니다.

예:

<link rel="canonical" href="http://stackoverflow.com/questions/47427/why-do-some-websites-add-slugs-to-the-end-of-urls">
— Robs
소스
3

검색 엔진뿐만 아니라 링크를 보낼 때 가독성을 잊지 마십시오. 누군가에게 첫 번째 링크를 이메일로 보내면 URL을보고 그 내용에 대한 일반적인 아이디어를 얻을 수 있습니다. 두 번째는 클릭하기 전에 해당 페이지의 내용을 표시하지 않습니다.

— 크리스 바 토우
소스
2

누군가에게 이메일을 보낸 경우 다른 사람이 설명이있는 URL을 구문 분석하도록하는 대신 설명을 실제로 작성하여 설명을 포함하는 것이 더 합리적이지 않을 것입니다. -하이픈으로 연결된 단어가 함께 붙어 있습니다.

— Kibbee
소스
당신은 분명히 Rick Roll'd가 된 적이 없습니다. 수신되는 링크는 몇 개입니까? 확인하십시오. 웃기다! <링크>. Youtube가 youtube.com/12345/evil-bikini-wax-job-not-work-safe와 같이 Urls를 수행했다면 좋을 것입니다. 링크를 더 신뢰할 수있게 만들고 클릭 여부를 결정하는 데 도움이됩니다.
— Armstrongest
1
그러나 내가 본 모든 MVC 시스템에는 여분의 악한 비키니 왁스 작업 비 작업 안전 부분이 필요하지 않으며 youtube.com/12345 및 대부분의 사람들처럼 쉽게 보낼 수 있습니다. 그런 것들을 우편으로 보내고 싶었던 사람은 빨리 제거하는 법을 배울 것입니다.
— Kibbee
2

첫째, SEO 및 사용자 친화적이지만 예제 (이 사이트)의 경우 제대로 수행되지 않았거나 올바르게 수행되지 않았습니다 (블랙 해트 트릭과 타인에 의한 순위 중독에 개방되어이 사이트에 나쁘게 반영 될 것입니다). .

만약

/programming/47427/why-do-some-websites-add-slugs-to-the-end-of-urls

내용이 있으면

/programming/47427/

과

/programming/47427/any-other-bollix

중복되지 않아야합니다. 그들은 실제로 현재 텍스트를 사용하지 않는 링크를 자동으로 감지해야하며 (분명히 슬러그는 질문 제목으로 정의되고 나중에 편집 할 수 있으므로) 301을 자동으로

/programming/47427/why-do-some-websites-add-slugs-to-the-end-of-urls

따라서 "하나의 콘텐츠에서 하나의 URI로"규칙을 확인하고 URI가 이동 / 변경되는 경우 이전 북마크가 301 리디렉션을 통해 따라 가거나 이동하는지 확인합니다 (지능형 브라우저가 북마크를 업데이트 할 수 있음).

— 앨런 도허티
소스
1
페이지 소스를 보면 다음을 찾을 수 있습니다. <link rel = "canonical"href = " stackoverflow.com/questions/47427/… "> 참조 : 여기 : googlewebmastercentral.blogspot.com/2009/02/…
— Armstrongest
0

이상적으로는 "슬러그"가 필요한 유일한 식별자 여야합니다. 실제로 이와 같은 동적 사이트에서는 고유 한 숫자 식별자가 있거나 Digg처럼 "슬러그"에 숫자를 추가 / 증가해야합니다.

— 카일 크로닌
소스
1
Digg 링크는 메인 페이지를 내려갈 때 처음 접한 링크였습니다. Digg가 얼마나 멀리 떨어졌는지 예시하는 것도 순전히 우연입니다. 성 중독에 대한 이야기가 세 번 게시되었습니다.
— Kyle Cronin
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.