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-snapshot을 제공하여 검색 엔진이 요청 된 데이터를 찾을 수있는 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. (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로 실제로 설명되지 않고 기본적으로 이전 버전과 호환되지 않는다는 것입니다.

현재 이것은 해시 뱅이 의도 한 정확한 것입니다. 서버가 아닌 클라이언트에서 탐색되는 별개의 페이지 상태를 나타냅니다. 예를 들어 다시로드 하면 해시 된 값을 읽고, 구문 분석하고, 처리 할 수 있는 동일한 리소스 가로드됩니다 .

단지 그들이 것으로 될 일이 또한 사용 된 페이지 새로 고침없이 서버 측 위치에 역사를 변경 (특히 페이스 북과 트위터에 의해). 사람들이 pushState에 대한 hashbangs를 포기하도록 권장하는 것은 이러한 사용 사례입니다.

모든 콘텐츠를 클라이언트 측에서 렌더링하는 경우 pushState해시 뱅을 사용하는 방법이 아니라보다 편리한 히스토리 API의 일부로 생각해야합니다 .

pushState 및에 대한 모든 흥미로운 이야기가 #!있지만 원래 포스터에서 요청한 것처럼 pushState가 #!의 목적을 어떻게 대체하는지 여전히 알 수 없습니다.

99 % JavaScript 기반 Ajax 사이트 / 애플리케이션을 SEOable로 만드는 우리의 솔루션 #!은 물론 사용 하고 있습니다. 클라이언트 렌더링은 HTML, JavaScript 및 PHP를 통해 수행되기 때문에 페이지 랜딩에 의해 제어되는 로더에서 다음 로직을 사용합니다. HTML 파일은 (대부분의 경우) 둘 다에 동일한 HTML을 원하기 때문에 JavaScript 및 PHP와 완전히 분리됩니다. JavaScript와 PHP는 거의 동일한 작업을 수행하지만 JavaScript가 훨씬 더 풍부한 사용자 경험을 제공하므로 PHP 코드는 덜 복잡합니다.

JavaScript는 jQuery를 사용하여 원하는 콘텐츠를 HTML에 삽입합니다. PHP는 PHPQuery를 사용하여 원하는 콘텐츠를 HTML에 삽입합니다. '거의'동일한 논리를 사용하지만 PHP 버전은 SEOable 링크가있는 SEOable 버전을 표시하는 데만 사용되며 JavaScript 버전과는 상호 작용하지 않습니다.

모두 페이지를 구성하는 세 가지 구성 요소 인 page.htm, page.js 및 page.php는 JavaScript 버전 대신 PHP 버전을로드할지 여부를 알기 위해 이스케이프 된 조각을 사용하는 모든 항목에 존재합니다. SEO 불가능한 콘텐츠 (예 : 사용자 로그인 후에 만 ​​볼 수있는 페이지)에는 PHP 버전이 필요하지 않습니다. 모든 것이 간단합니다.

일부 프런트 엔드 개발자가 브라우저 기술과 함께 서버 측 기술을 사용하지 않고 훌륭한 사이트 (Google 문서 도구의 풍부함)를 개발하는 방법에 대해 여전히 의아해합니다 ... JavaScript가 활성화되지 않은 경우 99 % JavaScript 솔루션 물론 PHP 없이는 아무것도 할 수 없습니다.

JavaScript가 활성화 된 경우 PHP 제공 페이지에 방문하여 JavaScript 버전으로 리디렉션 할 수있는 멋진 URL을 가질 수 있지만, 사용자가 더 중요한 청중이기 때문에 사용자 관점에서는 좋지 않습니다.

참고로. 자바 스크립트없이 작동 할 수있는 간단한 웹 사이트를 만드는 경우, 간단한 정적으로 렌더링 된 콘텐츠에서 더 나은 콘텐츠로 사용자 경험을 점진적으로 향상시키려는 경우 pushState가 유용하다는 것을 알 수 있습니다. 그러나 사용자에게 이동 중 최고의 경험 ... JavaScript 또는 Google 문서와 같은 것으로 작성된 최신 게임을 가정 해 봅시다.이 솔루션에 대한 사용은 다소 제한적입니다. 사용자 경험이 비전에 비해 고통스러워지기 전에는 우아하게 폴백 할 수 있기 때문입니다. 사이트의.