pushState 및 SEO

pushState 및 SEO

---

많은 사람들이 hashbang보다는 pushState를 사용한다고 말하고 있습니다.

내가 이해하지 못하는 것은 해쉬 뱅을 사용하지 않고 어떻게 검색 엔진에 친숙 해지겠습니까?

아마도 pushState 콘텐츠는 클라이언트 측 JavaScript 코드에 의해 생성됩니다.

따라서 시나리오는 다음과 같습니다.

에 example.com있습니다. 내 사용자가 링크를 클릭합니다.href="example.com/blog"

pushState는 클릭을 캡처하고 URL을 업데이트하며 어딘가에서 JSON 파일을 가져와 콘텐츠 영역에 블로그 게시물 목록을 만듭니다.

hashbangs를 사용하면 Google은 정적 콘텐츠를 얻기 위해 escaped_fragment URL로 이동하는 것을 알고 있습니다.

pushState를 사용하면 Google은 JavaScript 코드를 사용하여 JSON을로드 한 다음 템플릿을 만들 수 없기 때문에 아무것도 보지 못합니다.

내가 볼 수있는 유일한 방법은 서버 측에서 템플릿을 렌더링하는 것이지만, 이는 애플리케이션 계층을 클라이언트로 푸시하는 이점을 완전히 무효화합니다.

그래서 이것이 맞습니다. pushState는 클라이언트 측 응용 프로그램에 대해 SEO 친화적이지 않습니까?

---

URL에서 해시 뱅을 원하지 않는 사용자에게 Google이 제안하는 메타 태그를 사용하는 것은 어떻습니까? <meta name="fragment" content="!">

자세한 내용은 https://developers.google.com/webmasters/ajax-crawling/docs/getting-started 를 참조하십시오.

불행히도 나는 Nicole이 OP가 가지고 있다고 생각하는 문제를 명확히하지 않았다고 생각합니다. 문제는 단순히 해시 뱅을 사용하지 않으면 콘텐츠를 제공하는 대상을 알 수 없다는 것입니다. Pushstate는 우리를 위해 이것을 해결하지 않습니다. 우리는 검색 엔진이 최종 사용자에게 형식이 지정되지 않은 JSON을 뱉어내는 URL로 이동하도록 알리는 것을 원하지 않습니다. 대신 AJAX를 통해 데이터를 검색하고 선호하는 방식으로 사용자에게 제공하는 URL (더 많은 URL에 대한 다른 호출을 트리거 함)을 만듭니다. 사용자가 사람이 아닌 경우 대안으로 html 스냅 샷을 제공하여 검색 엔진이 요청 된 데이터를 찾을 수있는 URL로 사람을 적절하게 안내 할 수 있습니다. 하지만 궁극적 인 문제는 사용자 유형을 어떻게 결정 하는가입니다. 예, 우리는. htaccess 또는 우리가 감지 한 검색 엔진 봇의 URL을 다시 작성하는 것이지만 이것이 얼마나 완전하고 미래를 보장하는지 잘 모르겠습니다. 구글이 이런 일을 한 사람들에게 불이익을 줄 수도 있지만 완전히 조사하지는 않았습니다. 따라서 (pushstate + google의 메타 태그) 콤보는 가능한 해결책 인 것 같습니다.

---

pushState콘텐츠를 읽기 위해 검색 엔진이 필요한 경우 나쁜 가요 ?

아니요, pushState해시 뱅에 대해 동일한 일반 프로세스를 수행하지만 더보기 좋은 URL을 사용하여 설명합니다. hashbangs를 사용할 때 실제로 어떤 일이 발생하는지 생각해보십시오.

당신은 말한다 :

hashbangs를 사용하면 Google은 정적 콘텐츠를 얻기 위해 escaped_fragment URL로 이동하는 것을 알고 있습니다.

즉,

1. 구글은 링크를 본다 example.com/#!/blog
2. Google 요청 example.com/?_escaped_fragment_=/blog
3. 당신은 사용자가 볼 수 콘텐츠의 스냅 샷을 반환

보시다시피 이미 서버에 의존하고 있습니다. 서버에서 콘텐츠의 스냅 샷을 제공하지 않는 경우 사이트가 제대로 인덱싱되지 않은 것입니다.

그렇다면 Google은 pushState에 대해 어떻게 볼까요?

pushState를 사용하면 javascript를 사용하여 json을로드 한 다음 템플릿을 만들 수 없으므로 Google은 아무것도 보지 못합니다.

실제로 Google은에서 요청할 수있는 모든 것을 볼 수 있습니다 site.com/blog. URL은 여전히 ​​서버의 리소스를 가리키고 클라이언트는 여전히이 계약을 따릅니다. 물론 현대 클라이언트의 경우 Javascript는 페이지를 새로 고치지 않고도 콘텐츠를 검색하고 상호 작용할 수있는 새로운 가능성을 열었 지만 계약은 동일합니다.

따라서의 의도 된 우아함은 pushState기존 및 신규, JS 가능 여부에 관계없이 모든 사용자에게 동일한 콘텐츠를 제공하지만 새로운 사용자 는 향상된 경험을 제공한다는 것 입니다.

Google이 귀하의 콘텐츠를 보게하려면 어떻게해야합니까?

1. Facebook 접근 방식- 상태로 site.com/blog푸시 할 때 클라이언트 앱이 변환 할 URL에서 동일한 콘텐츠를 제공합니다 /blog. (페이스 북은 pushState아직 내가 아는 것을 사용하지 않지만 해쉬 뱅으로 이것을합니다)

2. Twitter 접근 방식 — 들어오는 모든 URL을 해당하는 hashbang으로 리디렉션합니다. 즉, "/ blog"에 대한 링크가 /blog상태로 푸시 됩니다. 그러나 직접 요청하면 브라우저는 #!/blog. (Googlebot의 경우 _escaped_fragment_원하는대로 라우팅됩니다 . 다른 클라이언트의 pushState경우 예쁜 URL로 돌아갈 수 있습니다.)

그래서 당신은 _escaped_fragment_능력 을 상실 pushState합니까?

몇 가지 다른 의견에서

이스케이프 된 조각은 완전히 다릅니다. 순수한 테마가없는 콘텐츠, 캐시 된 콘텐츠를 제공 할 수 있으며 일반 페이지와 같은 부하를받지 않습니다.

이상적인 솔루션은 Google이 JavaScript 사이트를 수행하거나 pushstate 사이트 (robots.txt?)에 대해서도 이스케이프 된 조각 URL이 있음을 알 수있는 방법을 구현하는 것입니다.

귀하가 언급 한 이점은 _escaped_fragment_. 당신을 위해 재 작성하고 특별히 명명 된 GET매개 변수를 사용한다는 것은 실제로 구현 세부 사항입니다. 다른 말로 다시 - 당신은 표준 URL을 할 수 없다는 것이 정말 특별한 것은 없습니다 /blog에 /?content=/blog자신의 사용에 mod_rewrite를 또는 서버의 상당.

서버 측 콘텐츠를 전혀 제공하지 않으면 어떻게됩니까?

URL을 다시 작성하고 어떤 종류의 콘텐츠 를 제공 할 수없는 경우 /blog(또는 브라우저에 푸시 한 상태) 서버는 실제로 더 이상 HTTP 계약을 따르지 않습니다.

어떤 이유로 든 페이지를 새로 고침하면이 URL에서 콘텐츠를 가져 오므로 이는 중요합니다. ( https://wiki.mozilla.org/Firefox_3.6/PushState_Security_Review 참조 — "푸시 된 경우 소스보기 및 다시로드는 모두 새 URI에서 콘텐츠를 가져옵니다.")

클라이언트 측에서 사용자 인터페이스를 한 번 그리고 JS API를 통해 콘텐츠를로드하는 것이 나쁜 목표가 아니라 HTTP 및 URL로 실제로 설명되지 않고 기본적으로 이전 버전과 호환되지 않는다는 것입니다.

At the moment, this is the exact thing that hashbangs are intended for — to represent distinct page states that are navigated on the client and not on the server. A reload, for example, will load the same resource which can then read, parse, and process the hashed value.

It just happens to be that they have also been used (notably by Facebook and Twitter) to change the history to a server-side location without a page refresh. It is in those use cases that people are recommending abandoning hashbangs for pushState.

If you render all content client-side, you should think of pushState as part of a more convenient history API, and not a way out of using hashbangs.

---

All interesting talk about pushState and #!, and I still cannot see how pushState replaces #!'s purpose as the original poster asks.

Our solution to make our 99% JavaScript-based Ajax site/application SEOable is using #! of course. Since client rendering is done via HTML, JavaScript and PHP we use the following logic in a loader controlled by our page landing. The HTML files are totally separated from the JavaScript and PHP because we want the same HTML in both (for most part). The JavaScript and PHP do mostly the same thing, but the PHP code is less complicated as the JavaScript is a much richer user experience.

The JavaScript uses jQuery to inject into HTML the content it wants. PHP uses PHPQuery to inject into the HTML the content it wants - using 'almost' the same logic, but much simpler as the PHP version will only be used to display an SEOable version with SEOable links and not be interacted with like the JavaScript version.

All are the three components that make up a page, page.htm, page.js and page.php exist for anything that uses the escaped fragment to know whether to load the PHP version in place of the JavaScript version. The PHP version doesn't need to exist for non-SEOable content (such as pages that can only be seen after user login). All is straightforward.

I'm still puzzled how some front end developers get away developing great sites (with the richness of Google Docs) without using server-side technologies in conjunction with browser ones... If JavaScript is not even enabled, then our 99% JavaScript solution will of course not do anything without the PHP in place.

It is possible to have a nice URL to land on a PHP served page and redirect to a JavaScript version if JavaScript is enabled, but that is not nice from a user perspective since users are the more important audience.

On a side note. If you are making just a simple website that can function without any JavaScript, then I can see pushState being useful if your want to progressively enhance your user experience from a simple statically rendered content into something better, but if you want to give your user the best experience from the go get... let's say your latest game written in JavaScript or something like Google Docs then it's use for this solution is somewhat limiting as gracefully falling back can only go so far before the user experience is painful compared to the vision of the site.

참고URL : https://stackoverflow.com/questions/6193858/pushstate-and-seo