programing

"친숙한 URL"은 무엇입니까?

nasanasas 2020. 12. 15. 19:24
반응형

"친숙한 URL"은 무엇입니까?


최근에 "친근한 URL"에 대해 (이 사이트와 다른 곳에서) 많은 토론을 읽었지만 정확히 무엇이 URL을 "친화적 인"것으로 만들고 우리가 정말로 관심을 갖는지 (특정 지점까지) 왜 그런지 잘 모르겠습니다. . 삽화:

다음은 대부분의 현재 웹 개발자가 "친숙한"것으로 간주하는 URL의 예입니다.

www.myblog.com/posts/123/this-is-the-name-of-my-blog-post

이것은 "불 우호적"으로 간주되는 반면 (즉, 나쁘고, 네안데르탈 인, 무지하고, 어리석은) :

www.myblog.com/posts.aspx?id=123

내 질문 :

  • "친숙한"URL에 문제의 블로그 게시물에 대한 중복 식별 정보가 포함되어 있지 않습니까? 즉, 게시물의 ID (123)가 있으면 왜 제목이 필요합니까? 이것은 "자신을 되풀이하지 마십시오"만트라의 위반이 아닐까요?
  • 사용자에 관한 한 URL 형식은 어떤 차이를 만들까요? 사용자가 실제로 전체 URL을 직접 입력 합니까 (물론 TLD 제외)? 사용자가 페이지의 내용을 확인하기 위해 페이지의 URL을 살펴본 적이 있습니까? URL에 블로그 게시물의 제목이 필요한 이유는 무엇입니까? 그게 페이지의 <title>태그와 내용이 아닌가?
  • 나는 종종 "친숙한"URL 양식이 선호되는 이유로 SEO를 듣는다. 검색 엔진 스파이더가 URL에 관심을 갖는 이유는 무엇입니까? 페이지 (및 페이지 내에 포함 된 다른 페이지에 대한 링크)를 크롤링하는 자동화 된 소프트웨어 조각이 아닙니까? 검색 엔진이 다른 소프트웨어 구성 요소 (예 : 데이터베이스 액세스 구성 요소)와 같이 작성된 경우 URL은 관계형 데이터베이스의 rowguid와 유사한 의미없는 식별자입니다. 위의 "친숙한"URL과 같은 것을 테이블의 기본 키로 사용하여 데이터베이스 스키마를 디자인하는 경우, 나는 (아주 정확하게) 씹힐 것입니다.

당연히 URL이 손을 뗄 수 있기 때문에 앞서 말했죠. 다음은 Amazon.com의 실제 URL입니다.이 URL은 올바른 생각을 가진 사람이 "친근"하다고 생각하지 않을 것입니다.

http://www.amazon.com/Bissell-Kitchen-Housewares/b/ref=amb_link_5001972_17?ie=UTF8&node=694500&pf_rd_m=ATVPDKIKX0DER&pf_rd_s=gp-center-5&pf_rd_r=1ZXNJFE0&pf_rd_p=405478901080&pf_rd_i=510901080pf_rd_i=510901HGH&pf_rd_17?ie=UTF8&node=694500&pf_rd_m=ATVPDKIKX0DER


Tim Berners-Lee (WWW 설계자)는 약 10 년 전에이 주제대한 훌륭한 기사를 썼습니다 .

  • 귀하의 예는 잘못된 URL이지만 ID와 "슬러그"(페이지 제목의 축약 된 하이픈 형식)가 모두 있기 때문이 아닙니다. 페이지 제목을 URL에 넣는 것은 장기적으로 문제가됩니다. 콘텐츠 시간이 지남에 따라 변경됩니다. 해당 블로그 게시물의 제목을 변경하는 경우 이전 URL을 유지하거나 새 제목과 일치하도록 URL을 변경해야합니다. URL을 변경하면 해당 페이지에 대한 이전 링크가 끊어집니다. 변경하지 않으면 페이지와 일치하지 않는 URL을 갖게됩니다. 둘 다 사용자에게 좋지 않습니다. www.myblog.com/posts/123으로 이동하는 것이 좋습니다.

  • 사용자는 종종 URL을 입력해야하지만 더 중요한 것은 사이트에서 다른 페이지를 찾기 위해 기존 URL을 편집하기도한다는 것입니다. 따라서 검색 가능한 URL이있는 것이 좋습니다 . 예를 들어 게시물 # 124를보고 싶다면 현재 URL을 쉽게보고보고 싶은 페이지의 URL이 www.myblog.com/posts/124임을 알 수 있습니다. 이는 사용자가 원하는 것을 찾으려고하는 사람들에게 큰 도움이 될 수있는 사용자 친화 성의 수준입니다. 게시물 제목과 같은 다른 정보를 포함하면이를 불가능하게 만들 수 있으므로 탐색 옵션이 줄어 듭니다.

  • SEO는 잊어 버리세요 . 검색 엔진 기술은 한동안 SEO 해킹의 효과를 줄여 왔습니다. 좋은 콘텐츠는 여전히 왕이며 장기적으로는 시스템 게임을 할 수 없습니다.


나에게 친숙한 URLURL에 의미 정보를 포함하여 사람의 소비에 더 적합하게 만들려는 시도가 있음을 의미합니다. 이것은 더 나은 인간-컴퓨터 인터페이스를 만들기 위해 컴퓨터-컴퓨터 인터페이스가 확장되고 구축되는 흥미로운 예입니다.

따라서 두 가지 예에서 :

  • www.myblog.com/posts/123/this-is-the-name-of-my-blog-postURL에 제목을 포함했기 때문에 친절 합니다. 페이지에 대한 정보를 알려줍니다 .
  • www.myblog.com/posts.aspx?id=123 은밀하고 모호하기 때문에 비우호적입니다. 데이터베이스에는 완벽하지만 당신이나 나에게는 전혀 의미가 없습니다.

친숙한 URL은 어떤 상황에서는 환상적이고 다른 상황에서는 쓸모가 없습니다. 기본적으로 사용자가 노출 될 경우 친근한 URL 생성을 우선 순위로 삼고 이는 미적인 문제가 아닙니다. 다양한 옵션이 무엇인지 빠르게보고 이해할 수 있다면 주소 표시 줄에서 URL로 돌아가는 것이 훨씬 쉬워지며, 웹에서 링크를 따라갈 때 어디로 가야하는지 더 명확하게 알 수 있습니다. 페이지.

이 모든 것을 Firefox 3+의 멋진 표시 줄과 결합하면 (확실히 다른 브라우저에서도 제공됨) 친숙한 URL을 처리 할 때 주소 표시 줄의 자동 완성 기능이 매우 강력 해집니다.


쿼리 문자열이 크롤러에 미치는 영향에 대한 정보가 상충되는 것처럼 보이지만, 긴 쿼리 문자열 변수가 동적 콘텐츠를 나타내므로 대부분의 검색 엔진이 많을 것이므로 매개 변수가 두 개 이상이면 SEO에 해를 끼칩니다. 덜 공격적인 페이지 색인 생성.

예에서 this-is-the-my-blog-post 와 같은 슬러그를 URL에 추가하면 간단한 ID 번호보다 링크가 서로 더 달라지고 더 중요한 단어가 url. 이것들은 검색 엔진이 찾는 모든 것입니다.

개인적으로 나는 구두점 문자가 더 적고 쿼리 문자열의 이름-값 쌍이 매우 장황하고 기억하기 어려울 수 있기 때문에 시각적으로 이러한 URL을 훨씬 쉽게 구문 분석합니다.


URL에 불필요한 정보를 넣는 방법에 대한 좋은 점입니다.

http://stackoverflow.com/questions/522466/what-makes-a-friendly-url

고유 ID 522466이 알려지면 나머지는 쓸모가 없으므로 순전히 URL을 "멋지게"보이게하고 사용자에게 페이지 링크에 대한 아이디어를 제공하는 역할을합니다. 그러나 이것은 또 다른 문제를 야기합니다. 대부분의 사이트는 URL의 해당 부분을 "확인"하지 않으므로 다음과 같이 입력 할 수 있습니다.

http://stackoverflow.com/questions/522466/omg-goatse-bought-by-bill-gates

그러나 여전히이 게시물에 링크됩니다. 악의적으로 사용될 수 있기 때문에 이것이 가치있는 것보다 더 많은 문제를 일으킬 수 있다는 것을 알 수 있습니다.

Digg가 이에 대해 올바른 접근 방식을 취했다고 생각합니다. URL에 ID를 사용하지 않습니다. 뒤에서 그들은 주어진 제목에서 순전히 데이터베이스에서 ID를 얻습니다.

http://digg.com/linux_unix/I_Like_Linux_so_my_aunt_sends_me_this_for_Christmas

이것은 나에게 완벽한 URL입니다. 링크를 클릭 할 때 안전하다고 느끼는 데 필요한 모든 정보를 제공합니다.

사실, 타이틀은 digg의 세계에서 사람들이 타이틀을 좋아하거나 관심이 있다는 사실을 기반으로 "블라인드 디그"하는 엄청난 역할을합니다. 귀하의 URL이 흥미로워 보인다면 귀하의 사이트에 더 많은 트래픽이 발생하고있을 수 있습니다. 동시에 더 사용자 친화적이고 예쁘게 만들 것이며 검색 엔진이 감사 할 것입니다. 내가 볼 수있는 한 친근한 URL은 모두에게 승리입니다.


세 가지 총알에 대한 내 생각 :

  • 최적의 URL이 아니라고 생각합니다. 게시물 식별자와 제목을 모두 표시하는 이유를 모르겠습니다. URL에 게시물 ID를 전혀 포함하지 않고 제목과 날짜 만 포함합니다.
  • 사용자에게는 짧을수록 좋습니다.
  • 검색 엔진은 URL을 확인합니다. 말이 되든 안 되든, 그렇습니다. URL에 키워드가 있으면 SEO 이점이 있습니다.

나는 당신과 동의하지만 아무에게도 말하지 마십시오.

제 겸손한 의견이지만

http://stackoverflow.com/questions/522466/

http://stackoverflow.com/questions/522466/what-makes-a-friendly-url

같은 페이지입니다. 내 말은, 하이픈으로 연결된 질문 제목이 URL에 약간의 컨텍스트를 제공한다는 것을 알 수 있지만 해당 부분이 선택 사항이라는 것을 알지 않는 한 URL이 불필요하게 길어집니다.


우선, 그들은 검색 엔진 크롤러에게 친숙합니다. Google 및 기타 업체는 페이지의 단어와 일치하는 URL의 단어에 높은 가치를 두므로 블로그 게시물의 제목이 URL에 있으면 검색 엔진에 도움이됩니다.

둘째, 그들은 그들이 무엇을 방문하는지 모르는 사람들에게 친절합니다. 비교를 위해 사용한 링크 중 트위터 / 이메일 / IM / 등에서 발견 될 경우 클릭 할 가능성이 더 높은 링크는 무엇입니까?


아 ... 트릭은 URL이 누구에게 친숙한가입니다. 검색 엔진은 첫 번째 URL이 URL에 콘텐츠 정보가 포함되어 있고 다른 매개 변수로 반복되는 동일한 페이지처럼 보이지 않기 때문에 더 친숙한 것으로 인식합니다.

예를 들어, 비교

www.aTvShowSite.com/show.aspx?id=123
www.aTvShowSite.com/show.aspx?id=124

로봇은 괜찮다고 말할 것입니다.이게 뭔지 모르겠지만 ... 나에게는 같은 페이지처럼 보입니다.

비교하는 반면

www.aTvShowSite.com/shows/AmericanIdol
www.aTvShowSite.com/shows/Lost

(동일한 aspx 페이지를 제공하더라도) 다른 페이지처럼 보이게 만들고 로봇은 더 높은 순위를 매기는 경향이 있습니다.

편집 : 또한 많은 로봇이 유용성을 결정하기 위해 URL의 텍스트를 확인하므로 페이지 콘텐츠가 동일하더라도 "Lost"를 검색하면 첫 번째 URL보다 두 번째 유형의 URL이 더 많이 검색 될 수 있습니다.


에 관해서 :

이것은 "자신을 되풀이하지 마십시오"만트라의 위반이 아닐까요?

That refers to the application CODE!!, not the application it self!!

It makes complete sense to have

  • Title in the <title> tag
  • In the URL
  • And as first line in the content.

And pretty much everywhere else the content need it.

What that "mantra" refers if the your code should look like this:

  <title><%=obj.getTitle()%></title>
  Reading:<h1><%=obj.getTitle()%></h1>
  Link to this:<a href="getHrefFor( object.getTitle() )">obj.getTitle()</a>
  Etc. etc.

Instead of having different methods with copy/pasted code all around your app.


The "unfriendly" URL you show exposes an implementation detail: what if, sometime in the future, you decide to drop ASP and to use something else? You would have to change all the URLs (baad!) or to employ a renaming scheme.

Having the title repeated in the URL is maybe not that necessary but it turns out handy when you do a lot of link pasting, to double check that you are linking to the correct place.


Our website uses so-called 'unfriendly' URLs, but we create special 'friendly' URLs for specific locations that members of the public use for specific functions, especially on printed material.

For example, our parking tickets have http://www.dnv.org/parking on them.

CP


Well, for a start, try to keep characters apart from (a-z,A-Z,0-9) and of course :/._- out of the url. Not everyone has all of those on their keyboards (for example, I don't have & on my keyboard, neither do I have ~)

When for example, doing some url parsing or something alike, also helps if the url syntax is "clean"


The 2nd URL looks more user friendly, whereas the first looks search-engine friendly.

Search engines give a higher relevance to words that appear in the URL. The domain name gets the highest (because it can't change), the rest of the URL gets a high priority because the length is limited, and then the body of the document is analysed.

My answer is quite subjective, because it depends on whether you are being human friendly (easy to type manually, or read to a friend) or whether you are being search engine friendly (boosting your ranking.)


In this situation, it doesn't really break the DRY principal, because as far as a search engine is concerned, '522466' is not the same thing as 'what-makes-a-friendly-url'

Generally for sites like StackOverflow, the token is the only piece of information that matters; usually you can put whatever you want after that point and it'll take you to the same place (ignored by the web server).

The page description is only there to help the search engines identify what the page is about (which is nice)


Another point: people sometimes manually edit URLs, in order to go up the directory tree. So they might try to load a page like http://site.com/a/b, get a "Not found" error, and then try http://site.com/a or http://site.com. Of course, if your URLs aren't based on an actual directory tree, this may not work. But you can still try to support it.

Some browsers even encourage this, like IE with its error messages, and Safari with a menu that appears when you right-click the page title.


Matt and @bigmattyh: SEO is not "hacks": it's understanding what "good content" means on the web. Page titles are part of the content. Good anchor text in links is "good content" (rather than using words like "click here" as the link text). Placing links in context rather than as a list is "good content".

Page titles are low-hanging fruit, but they remain one of the easiest ways to improve SERP. Yes, inbound links (and their quality) are critical, but titles can do wonders, particularly in the short-term. You don't have to use the page title (which may change from time to time) as the post title: summarize the content manually.

Don't guess on this stuff: (a) read sources like SEOmoz.org and (b) analyze your own site rigorously.


The term readable url is also used a lot. Using friendly/readable urls is a SEO born technique and that is about it. Otherwise the shorter the path the better. Doing rewrite rules usually slows the process of getting the page fast to the client so take that in consideration as well.


In my opinion, IDs and UUIDs should never be part of the URL, never.

1) Some NoSQL databases don't use IDs at all, they use UUIDs. UUIDs are long, portions are separated using dashes. Google will treat a dash like a words separator: that means your url will have 5 more useless keywords.

2) A human being does not understand IDs or UUIDs. A person understands words and talking URLs.

3) If the title changes you can simply make a redirect like WordPress does, like @TRiG pointed.

4) Finally, remember to use a date, so you can discern between two articles having the same title and posted in a different year, month or day. For example you can have two reviews (first edition and second edition) of the same book.

http://example.com/2013/02/11/data-mining-concepts-and-techniques

and

http://example.com/2011/05/23/data-mining-concepts-and-techniques

5) A date will also help any user to figure out if the content is recent or is not.

6) A date will add an important keyword to your URL: the year. Let's suppose I want see the most beautiful girls in the world, I will type in Google: "most beautiful girls in the world 2014". My url will be:

http://example.com/2014/07/10/the-most-beatiful-girls-in-the-world

7) Last but not least, Chrome caches the site you visited, so you can find the above site just typing in the address bar "girls".


The term readable url is also used a lot. Using friendly/readable urls is a SEO born technique and that is about it. Otherwise the shorter the path the better.

ReferenceURL : https://stackoverflow.com/questions/522466/what-makes-a-friendly-url

반응형