웹사이트 HTTPS 마이그레이션에서 가장 중요한 3단계

지난 5년 동안 웹 사이트 작업을 수행했다면 HTTPS에 대해 들어본 적이 있을 것입니다. HTTPS는 모든 사용자가 웹을 보다 안전하게 사용할 수 있도록 하는 새로운 유망한 인터넷 프로토콜입니다. 또한 2016년 에 HTTPS 사이트 수가 두 배로 증가하면서 가장 빠르게 성장하는 인터넷 트렌드 중 하나입니다 .

우리는 여러 클라이언트와 협력하여 사이트에서 HTTPS를 구현했으며 그 과정에서 HTTPS 마이그레이션으로 인해 발생할 수 있는 많은 문제를 해결하는 방법을 배웠습니다. 원활한 HTTPS 마이그레이션에 대한 가이드가 아래에 나와 있지만 먼저 개요가 있습니다.

HTTPS 란 무엇입니까?

HTTPS에 익숙하지 않은 사람을 위해 다음은 프로세스에 대한 기본 개요입니다. 웹을 탐색할 때 콘텐츠는 "하이퍼텍스트 전송 프로토콜"을 통해 전달됩니다. 이것은 URL( http://www.example.com ) 의 시작 부분에 표시되는 "HTTP" 접두사이며 서버와 클라이언트가 통신하고 인터넷 콘텐츠를 표시할 수 있도록 합니다.

HTTPS는 HTTP 프로토콜의 보다 안전한 버전입니다. SSL 보안 인증서를 서버/클라이언트 통신에 추가하여 서버와 사용자 컴퓨터 사이를 이동하는 동안 암호 및 신용 카드 정보와 같은 민감한 정보가 악의적인 lurker에 의해 도난당하지 않도록 합니다. 가장 중요한 것은 사이트가 안전하고 안전하다는 명확한 지표를 사용자에게 추가한다는 것입니다.

원칙적으로 HTTPS로 마이그레이션하는 것은 웹사이트에 SSL 인증서를 추가하는 것만큼 간단합니다. 실제로는 지루하고 피곤한 과정이 될 수 있습니다. Washington Post는 2015년 10개월 간의 이주 에 대해 설명하면서 그들이 직면한 다양한 문제와 장애물을 각각 설명했습니다.

사이트에 SSL 인증서를 추가하려면 먼저 인증서를 얻은 다음 전체 사이트에 적용한 다음 향후 만료되거나 만료되지 않도록 유지 관리해야 합니다. 더 큰 사이트, 특히 전자상거래 플랫폼이나 로그인 포털이 있는 사이트의 경우 이는 매우 힘든 과정일 수 있습니다. 또한 Moz의 3개월 이상 유기적 하락 과 같이 일시적 또는 영구적인 트래픽 및 키워드 순위 하락의 위험이 있습니다.

HTTPS에 관심을 갖는 이유는 무엇입니까?

Google은 이미 2014년 부터 HTTPS를 채택하는 웹사이트에 대한 가장 강력한 지지자 중 하나였으며 그럴만한 이유가 있습니다. 보다 안전한 웹을 사용하면 대다수의 인터넷 사용자가 일상 생활을 훨씬 더 쉽게 사용할 수 있습니다. 누군가 귀하의 신용 카드 정보를 도용할 수 있다는 사실을 안다면 아마존에서 쇼핑하기를 주저할 사람이 얼마나 될까요? 당신이 보내는 것을 누군가가 엿볼 수 있다는 것을 안다면 당신 중 얼마나 많은 사람들이 이메일을 사용하겠습니까? 웹 보안은 이 시대에 매우 중요하지만 구현하기 쉽게 만드는 생각으로 자신을 현혹하지 마십시오.

인터넷 사용자에게는 다행스럽게도(웹마스터와 SEO에게는 불행히도) HTTPS는 계속 남아 있습니다. Google의 John Mueller는 이것이 웹마스터가 해야 할 조치라고 주장합니다.

보다 최근에 Google의 웹마스터 트렌드 분석가인 Gary Ilyes는 이러한 전환을 용이하게 하기 위해 Google에서 301 리디렉션에 대한 PageRank를 측정하는 방법에 대한 주요 변경 사항을 발표했습니다.

30x 리디렉션은 더 이상 PageRank를 잃지 않습니다.

— Gary Illyes ᕕ( ᐛ )ᕗ (@methode) 2016년 7월 26일

리디렉션이 PageRank의 80-90% 대신 100%를 통과하도록 허용함으로써 Google은 더 많은 사이트가 HTTPS를 채택할 수 있는 유기적 손실에 대해 크게 걱정할 필요 없이 HTTPS를 채택하도록 장려하고자 합니다.
마지막으로 Google은 2017년 1월부터 HTTPS를 사용하지 않는 신용 카드 정보 또는 비밀번호를 수집하는 모든 사이트가 Chrome에서 "안전하지 않음"으로 표시될 것이라고 발표했습니다.

여러 클라이언트와 협력하여 HTTPS를 구현한 후 HTTPS 마이그레이션의 3가지 주요 단계와 관련된 목록을 작성했습니다.

1. 사전 마이그레이션
2. 이주
3. 마이그레이션 후

사전 마이그레이션

백업, 백업, 백업. 나는 이것을 충분히 반복할 수 없다. HTTPS 마이그레이션을 시작하기 전에 사이트를 백업하십시오.

HTTPS 마이그레이션 중에 잘못될 수 있다고 생각하지 못했던 일을 포함하여 수천 가지가 잘못될 수 있습니다. 미디어 라이브러리의 백업을 다운로드합니다. CSS 및 JS 파일의 백업을 저장합니다. 전체 사이트 구성을 백업하는 경우 SSL을 활성화한 후 문제가 발생하면 SSL 인증서를 쉽게 비활성화할 수 있습니다.

다시 말하지만, 나는 당신이 백만 년 안에 예상하지 못할 일이 얼마나 많은 일이 잘못될 수 있는지 반복할 수 없습니다. 사이트를 백업하십시오.

이주

성배, 실제 이주 그 자체. 여기에서 모든 고통과 고통의 준비가 결실을 맺습니다.

웹마스터에게는 다행스럽게도 기존 SSL 구현보다 HTTPS로 마이그레이션하는 몇 가지 더 쉬운 방법이 있습니다. CloudFlare 와 Let's Encrypt 는 우리가 HTTPS 마이그레이션에 적극 권장하는 소규모 사이트에서 사용한 두 가지 서비스입니다.
**참고: Cloudflare는 최근 주요 보안 취약점이 노출 되었으므로 Cloudflare SSL을 즉시 채택하는 데 주의하십시오. 그러나 문제가 완전히 해결되면 다시 한 번 실행 가능한 서비스가 될 것입니다.

이들 각각은 완전 무료 서비스입니다. 그들은 완전한 SSL 구현과 관련된 많은 번거로움 없이 동일한 수준의 SSL 암호화 및 보안을 제공합니다. 위의 링크에서 각 서비스에 대한 자세한 내용을 읽을 수 있지만 Cloudflare의 기본 원칙은 SSL 인증서를 무료로 제공한 다음 완전히 안전한 검색자에게 사이트의 캐시된 버전을 제공한다는 것입니다. 서버와 클라이언트 간의 통신은 안전하지 않지만 사이트 방문자는 여전히 안전한 사이트에 도착합니다.

반면 Let's Encrypt는 WPEngine과 같은 웹 서버를 통해 자동으로 구성할 수 있는 무료 SSL 인증서를 제공합니다. 인증 기관이 도메인의 유효성을 검사하면 Let's Encrypt가 전체 사이트에 SSL 인증서를 제공합니다.

이 옵션을 사용하지 않기로 선택한 경우 가장 좋은 권장 사항은 사이트에 라이브로 푸시하기 전에 모든 것을 테스트하는 것입니다. 준비 사이트가 있는 경우 라이브 사이트를 마이그레이션하기 전에 모든 페이지에서 SSL 구현을 테스트하십시오. 사이트맵 및 robots.txt 파일의 링크, 사이트 전반의 링크, 이미지, 제출 양식 등 모든 것을 검토하세요.

마지막으로, 사이트의 HTTP 버전을 가리키는 링크를 잡기 위해 전역 리디렉션이 있는지 확인하십시오. CloudFlare 및 Let's Encrypt(및 대부분의 다른 환경)는 이 리디렉션을 자동으로 설정하지만 전환에 포함되어 있는지 확인합니다. 마지막으로 원하는 것은 백링크에서 자산을 잃는 것입니다.

동시에 사이트 링크에 ​​사용하는 URL 구조를 검토하십시오. 링크 가 상대 URL 경로(/stuff/) 대신 전체 URL 경로( http://www.example.com/stuff/ )를 사용하는 경우 마이그레이션 후에 해당 링크가 업데이트되지 않을 수 있습니다. 귀하의 링크 프로필을 더 이상 사용하지 않는 이유를 Google에 제공하지 마십시오. 이 두 기능을 모두 다시 확인하십시오.

마이그레이션 후

마이그레이션이 완료되었다고 해서 작업이 아직 끝난 것은 아닙니다. 때로는 그 여파가 실제 마이그레이션 자체만큼이나 어려울 수 있습니다.

가장 먼저 해야 할 일은 사이트에서 타사 스크립트를 검토하는 것입니다. HTTPS 마이그레이션을 완료한 한 클라이언트가 사이트 전체에서 전체 글꼴이 사라진 것을 발견했습니다. 그들의 사용자 정의 글꼴은 WordPress의 기본 블록 문자로 대체되어 사이트가 투박하고 다루기 어려워 보입니다. 문제는 글꼴 라이브러리를 HTTPS 파일로 제공하지 않는 타사 서비스에서 글꼴을 가져왔다는 것입니다. 파일을 HTTPS 프로토콜로 업데이트할 수 있게 되자 글꼴이 정상으로 돌아갔습니다.

마이그레이션 작업을 하는 다른 클라이언트는 Pardot.com에서 가져온 사이트 전체에 여러 제출 양식을 가지고 있었습니다. 사이트에 있는 대부분의 다른 리소스가 올바르게 마이그레이션되었음에도 불구하고 이러한 제출 양식은 마이그레이션되지 않아 이전에 전체 구독 양식이 있었던 일련의 빈 입력 상자를 남겼습니다. 이전과 마찬가지로 구독 양식은 기본적으로 HTTPS로 마이그레이션되지 않는 것으로 나타났습니다. 링크를 업데이트하고 나면 양식을 사용할 수 있습니다.

우리가 겪었던 가장 일반적인 문제는 안전하지 않은 이미지입니다. 가장 먼저 보게 될 경고 중 하나는 아래와 같은 오류 메시지일 것입니다.

사이트 마이그레이션 중에 사이트에 포함된 이미지에 안전하지 않은 URL 주소가 있는 경우가 많습니다. 사이트를 이전한 후에도 외부 사이트에서 가져온 이미지에 여전히 안전하지 않은 URL이 있는 경우가 많아 Chrome에서 사이트의 콘텐츠가 손상되었을 수 있음을 사용자에게 경고합니다.

지금 귀하 중 일부는 "하지만 내 사이트의 모든 이미지를 확인하여 어떤 이미지가 안전하고 어떤 것이 안전하지 않은지 확인하려면 어떻게 해야 합니까?"라고 말하고 있습니다. 다행히 솔루션이 있습니다. Screaming Frog 내에서 사이트를 크롤링하는 동안 HTTP 주소가 있는 이미지를 검색하도록 사용자 지정 추출을 설정할 수 있습니다.

사용자 정의 추출은 XPath 유형으로 설정하고 HTML 요소를 추출하도록 설정해야 합니다. 그런 다음 다음 스니펫을 추출 코드로 사용합니다.

 //img[contains(@src,'http://')] 

크롤링이 완료되면 "추출" 탭에 안전하지 않은 이미지와 해당 이미지의 소스 코드가 있는 전체 페이지 목록이 표시됩니다. 여기에서 URL을 HTTPS 주소로 업데이트할 수 있습니다.

두 번째로 해야 할 일은 사이트의 HTTPS 버전을 Google Search Console에 추가하는 것입니다. Google이 귀하의 사이트가 이제 안전하다는 것을 인식하고 사이트가 표시하는 순위 결과를 사용자에게 전환하는 데 시간이 걸립니다. Search Console에서 사이트의 HTTPS 버전을 빨리 확인할수록 Google은 보안 사이트의 색인을 생성하고 검색결과에서 사용자에게 이를 제공할 수 있습니다.

셋째, HTTPS 외에도 서버가 일반 인터넷 프로토콜의 최신 버전인 HTTP/2.0을 사용하고 있는지 확인해야 합니다. 위에서 CloudFlare 또는 Let's Encrypt를 사용하는 경우 서버는 기본적으로 HTTP/2.0과 호환되어야 합니다. 그러나 만일을 대비하여 https://tools.keycdn.com/http2-test 에서 빠른 확인을 실행하는 것은 결코 문제가 되지 않습니다 .

마이그레이션 후 취해야 할 마지막 단계는 다음 주 및 몇 달 동안 유기적 트래픽을 지속적으로 모니터링하는 것입니다. Rand Fishkin이 위 링크에서 언급했듯이 Moz는 마이그레이션 후 3개월 동안 검색 트래픽의 11%를 잃었고 다른 많은 사이트에서도 비슷한 손실을 보고했습니다.

해당 트래픽을 즉시 복구할 수 있는 옵션이 거의 없을 수 있지만 순위에서 하락한 검색어 또는 자연 트래픽이 감소한 페이지에 주의를 기울여야 합니다. 이러한 페이지가 빠르게 복구되지 않는다고 가정하면 사이트에 더 심각한 문제가 있다는 신호일 수 있습니다. 더 심각한 문제인 경우 자연 트래픽이 감소했을 때 취해야 할 조치에 대한 단계를 따르세요 .

다시 말하지만 HTTPS로 마이그레이션하는 것은 수행해야 하는 단계입니다. Google은 이에 대해 점점 더 강력해지고 있으며 이는 사이트 방문자에게 긍정적인 사용자 경험을 제공하는 데 필수적인 부분이기도 합니다. 불행히도 이것이 중요하다고 해서 그것이 빠르고 쉽다는 의미는 아닙니다. 위의 가이드를 따르면 HTTPS 마이그레이션의 가장 일반적인 함정과 함정을 피할 수 있습니다. 그만한 가치가 있습니다.