SEO for Software Engineers

2020-02-20

소프트웨어 엔지니어를 위한 SEO

원문은 Ben Hoyt님이 2020-02-20에 게재했습니다. 이 블로그 구독하기

Compass 기술 블로그 원문

몇 달 전 저는 사내 소프트웨어 개발자들을 대상으로 “엔지니어를 위한 SEO”라는 주제로 기술 세션을 진행했습니다. 저희 SEO 팀은 많은 엔지니어들이 검색 엔진 최적화에 대해 잘 모르고, 때로는 소비자용 페이지를 SEO에 그다지 유리하지 않은 방식으로 설계한다는 사실을 알게 되었습니다.

그래서 팀 전체를 대상으로 좋은 SEO 기법의 기초를 한번 짚어보는 것이 유용하겠다고 생각했고, 이제 그 내용을 여러분과 공유하려 합니다. SEO에 대해서는 이미 많은 자료가 나와 있지만, 대부분 SEO 에이전시에서 작성한 것입니다. 이 글은 엔지니어가 엔지니어를 위해 쓴 글입니다.

과거와 현재

지금의 구글 검색 결과 페이지를 몇 년 전과 비교해 보는 것도 의미가 있습니다:

2019년과 2012년의 구글 검색 결과 페이지 비교

2012년에는 화면이 더 작았음에도 스크롤 없이 3개의 일반(광고가 아닌) 결과가 보입니다. 2019년에는 광고 네 개와 구글 지식 그래프 항목, “관련 질문” 답변 등이 나오고, 그 다음에 진짜 검색 결과가 단 하나만 보입니다!

스크롤 없이 결과 페이지에 노출되는 것 자체가 점점 더 어려워지고 있으며, 이는 좋은 SEO가 그만큼 더 중요해지고 있음을 보여줍니다.

SEO란 무엇인가?

SEO는 “search engine optimization”, 즉 검색 엔진 최적화의 약자입니다. 검색에서 페이지 순위를 높여 검색 엔진으로부터 더 많고 더 질 좋은 트래픽을 얻기 위해 하는 일들을 일컫는 근사한 용어입니다.

구글이 주요 검색 제공자이기 때문에, 이는 결국 구글 검색에서 더 높은 순위를 차지한다는 의미이기도 합니다. 하지만 구글을 위해 해야 할 일들은 대부분 다른 모든 검색 엔진에도 도움이 됩니다.

SEO와 SEM, 즉 “search engine marketing(검색 엔진 마케팅)”은 다르다는 점에 유의하세요. SEM은 키워드 기반 광고에 비용을 지불하는 것을 말합니다. ‘O’는 organic, 즉 비유료 검색을, ‘M’은 money, 즉 유료 검색을 뜻한다고 생각하면 됩니다. 이 글에서는 SEM은 다루지 않고, 특히 크롤링되고 순위가 잘 매겨지는 방법에 초점을 맞춰 SEO를 다룰 것입니다.

SEO의 어떤 측면들은 엔지니어에게는 꽤 단순합니다(대부분 기술적인 부분), 하지만 다른 측면들은 훨씬 더 어렵습니다(실제로 좋은 콘텐츠를 만들고 발행하는 일). 여기서는 주로 엔지니어가 직접 할 수 있는 단순하고 기술적인 최적화에 초점을 맞추겠습니다.

크롤링과 색인 생성

여러분의 페이지가 갖춰야 할 최소한의 조건은 Googlebot이 크롤링하고 색인할 수 있는 상태여야 한다는 것이며, 이는 의외로 쉽게 놓치기 쉽습니다. 순위를 올리고 싶은 각 페이지 또는 페이지 유형은 다음 조건을 충족해야 합니다:

robots.txt에서 허용될 것
안정적이고 정규(canonical)인 URL을 가질 것
404나 500이 아닌 HTTP 200으로 응답할 것
서버 사이드 렌더링된 HTML을 사용할 것
사이트 내부에서 링크될 것
XML 사이트맵에 포함될 것

각각에 대해 조금 더 자세히 살펴보겠습니다.

Robots.txt

중대형 사이트 대부분은 /robots.txt에 위치한 텍스트 파일을 가지고 있으며, 이 파일은 구글 웹 크롤러와 같은 “착한 봇”에게 어떤 페이지를 크롤링해야 하고 하지 말아야 하는지를 알려줍니다. 파일 형식은 매우 단순하며, robotstxt.org와 구글 문서에 자세히 문서화되어 있습니다. 간단한 robots.txt 파일은 다음과 같이 생겼을 수 있습니다:

Sitemap: https://www.example.com/sitemap.xml
User-Agent: *  
Disallow: /api/  
Disallow: /staff/

이는 Googlebot(과 다른 크롤러)에게 두 가지를 알려줍니다:

이 사이트의 XML 사이트맵이 어디에 있는지.
모든 사용자 에이전트(즉, 모든 크롤러)에 대해 /api/ 또는 /staff/로 시작하는 URL은 크롤링하지 말 것.

하지만 조금 조심해야 합니다. 예를 들어, SEO를 잘 모르거나 이 글을 읽지 않은 선의의 엔지니어가 “성가신 봇들을 모두 차단”하기로 하고 파일에 “Disallow: /”를 추가하면 어떻게 될까요?

혹은 CEO가 개발자에게 “나에 대한 페이지를 만들어 달라”고 요청했는데, 개발자가 robots.txt 규칙을 모른 채 페이지를 /staff/billg에 만들면 어떻게 될까요? 그 페이지는 색인될 가능성이 전혀 없다는 사실을 모를 것입니다.

이런 일은 생각보다 자주 일어납니다. 일부 기업은 robots.txt 파싱 라이브러리를 이용해 중요한 페이지가 항상 크롤링 가능하도록 보장하는 자동화된 검사를 추가합니다. 최소한 robots.txt는 소스 컨트롤에 넣고 모든 변경에 대해 철저히 리뷰해야 합니다.

당연히 크롤링되기를 원하는 페이지는 robots.txt에서 허용되어야 합니다. 하지만 크롤링할 필요가 없는 URL은 적극적으로 차단해야 합니다. 예를 들어 JSON API 응답은 크롤링될 필요가 없습니다. 구글은 여러분 사이트에 대해 일정량의 크롤 예산만 할당하므로, 크롤링할 필요가 없는 것에 예산을 낭비하고 싶지 않을 것입니다.

robots.txt에서 페이지를 차단하는 것이 보안 조치가 아니라는 점에 유의하세요. 악성 봇이나 해커는 여전히 해당 페이지를 크롤링할 수 있습니다. 따라서 예를 들어 robots.txt에서 차단된 /api/ 요청이라도, 그 뒤에 있는 정보가 공개 정보가 아니라면 여전히 안전한 인증이 필요합니다.

안정적이고 정규인 URL

기존 웹 앱을 다루고 있다면 URL 구조가 이미 정해져 있을 수 있습니다. 하지만 새로운 URL을 설계한다면 염두에 둘 점은 다음과 같습니다:

하나의 페이지, 하나의 URL: 항상 단일 페이지를 단일하고 정규인 URL에서 제공하세요. 여기서 정규(canonical)란 rel=canonical 링크를 의미하는 것이 아니라, 단일하고 정규화된 URL을 의미합니다. 예를 들어 /staff/billg에서 페이지를 제공하고 있다면, 같은 콘텐츠를 /staff/gates/bill에서도 제공하지 마세요. 여러 URL을 허용하고 싶다면 다른 주소들을 정규 주소로 301 리다이렉트하세요.

뒤 슬래시 처리: 위와 관련된 내용으로, /staff/billg와 /staff/billg/ 모두에서 HTTP 200을 반환하지 마세요. 대신 그 중 하나를 정규 URL로 선택하고 다른 버전을 그곳으로 301 리다이렉트하세요.

어느 정도 읽기 쉬운 URL: URL에 설명적인 키워드를 포함하라는 문헌이 꽤 많으며, 이는 “모던 웹”의 모범 사례가 되었습니다. 예를 들어 /articles/1234보다 /articles/1234/seo-for-engineers를 선호하세요.

리소스 ID 포함: 위 예시처럼 URL에 1234와 같은 리소스 ID를 포함하면 기술적으로 더 단순해집니다. ID를 이용해 실제로 리소스를 조회하고, “seo-for-engineers” 슬러그가 해당 글의 현재 슬러그와 일치하지 않으면 정규 URL로 301 리다이렉트하세요. StackOverflow, TripAdvisor 등 많은 사이트가 이 기법을 사용합니다. 과거 URL 변경 내역이나 리다이렉트 데이터베이스를 유지할 필요가 없어집니다.

웹 앱의 URL 구조가 너무 엉망이어서 재설계가 필요하다면, 안전하게 달성하는 것은 가능합니다. 기존 URL을 HTTP 301 Moved Permanently를 이용해 새 URL로 리다이렉트해야 합니다. 다만 이런 작업은 너무 자주 하지 마세요!

301을 반드시 사용해야 하는 곳 중 하나는 http:// 사이트를 https:// 사이트로, 그리고 www가 없는 도메인을 www 도메인으로(혹은 그 반대로) 리다이렉트하는 경우입니다.

깔끔한 HTTP 응답

여러분의 페이지가 Googlebot에게는 가능한 한 깔끔하게 보이도록 하고 싶을 것입니다. 즉, 리다이렉트 없이 HTTP 200을 반환하는 것입니다. 이렇게 하면 구글이 재시도에 크롤 예산을 낭비하거나, 최악의 경우 깨진 링크나 간헐적인 500 오류로 인해 페이지 순위에 불이익을 주는 것을 피할 수 있습니다. 피해야 할 것들은 다음과 같습니다:

HTTP 404: URL이 잘못해서 404 Page Not Found를 반환한다면, 링크가 깨졌거나 페이지 핸들러가 고장 난 것입니다. 둘 다 피해야 합니다. 물론 해당 위치에 페이지가 없어야 한다면 404가 올바른 코드입니다.
HTTP 301: 301 Moved Permanently는 유용하고 중요한 목적을 수행하지만(이전 섹션 참조), 내부 페이지들이 리다이렉트된 URL을 많이 링크하고 있다면 해당 링크들을 업데이트해야 합니다.
HTTP 500: Internal Server Error는 구글이 완전히 깨진 페이지를 보고 있다는 의미입니다. 어쨌든 엔지니어들이 500 오류를 면밀히 모니터링하고 있기를 바라지만, 그렇지 않다면 지금이 시작할 때입니다!

Moz의 HTTP 상태 코드 가이드에서 더 자세한 정보를 읽어보세요.

서버 사이드 렌더링

검색 노출이 중요한 페이지에 대해서는 항상 서버에서 렌더링된 HTML을 제공해야 합니다. 이는 사용자(더 빠른 로딩, JavaScript 실행으로 인한 배터리 소모 감소)에게도 좋을 뿐만 아니라 Googlebot에게도 좋습니다.

“하지만,” 누군가 말할 것입니다, “구글은 이제 JavaScript를 실행하지 않나요?” 이는 적어도 2014년부터 사실입니다. 구글은 여러분의 JavaScript를 실행해 페이지를 더 잘 이해하려고 시도합니다. 하지만 단순히 HTML을 파싱하는 것보다 JavaScript를 실행하는 것이 아마도 한 차원 더 어려울 것입니다. 서버에서 렌더링된 HTML에서 텍스트를 파싱하는 것과 비교해 V8을 띄워 JavaScript를 실행하는 데 얼마나 더 많은 CPU 파워가 필요한지 생각해 보세요.

JavaScript 실행을 구글에 의존하는 것에는 많은 주의사항이 있습니다(위에서 링크한 2014년 글 참조). 또한 구글은 HTML은 즉시 파싱하는 것으로 보이지만, JavaScript 실행은 2단계 프로세스로 상당히 지연될 수 있습니다. 따라서 최상의 결과를 위해서는 항상 서버에서 생성된 HTML로 콘텐츠를 제공하세요.

React와 같은 클라이언트 기술을 사용해 페이지를 인터랙티브하게 만드는 것은 여전히 가능하며, 단지 조금 더 노력해서 서버 사이드 렌더링을 활성화하면 됩니다. Compass에서는 몇 년 전 클라이언트 사이드 React에서 서버 사이드 렌더링으로 전환했을 때 상당한 순위 상승을 경험했습니다.

ReactDOMServer.renderToString(element)
React 엘리먼트를 초기 HTML로 렌더링합니다. React는 HTML 문자열을 반환합니다. 이 메서드를 사용해 서버에서 HTML을 생성하고 초기 요청 시 마크업을 내려보내 페이지 로드를 더 빠르게 하고 검색 엔진이 SEO를 위해 페이지를 크롤링할 수 있도록 할 수 있습니다.

내부 링크

“내부 링크”는 같은 사이트 내에서 한 페이지에서 다른 페이지로 연결되는 링크를 의미하는 SEO 유행어입니다. 이러한 링크는 사용자가 사이트를 탐색하는 데 도움이 될 뿐만 아니라, 구글이 사이트를 크롤링하고 사이트 전반에 “랭킹 파워”를 퍼뜨릴 수 있게 해줍니다. 내부 링크에 대한 Moz 글에서 더 자세히 읽어보세요.

내부 링크는 보통 비교적 간단하게 구현할 수 있으며, (합리적인 범위 내에서) 중요한 페이지에서 다른 중요한 페이지로 가능한 한 많이 링크하는 것이 좋습니다. 내부 링크의 예시는 다음과 같습니다:

이동 경로(breadcrumb)
헤더나 푸터의 내비게이션 링크
사용자 탐색을 돕고 Googlebot이 추가 페이지를 찾는 데 도움이 되는 링크 블록, 예를 들어 Compass 매물에서 유사한 주택으로 연결되는 링크:

Compass 매물 페이지의 ‘유사 매물’ 위젯

대부분의 대형 사이트는 사이트의 모든 중요 페이지로 연결되는 HTML 사이트맵도 가지고 있습니다. 예전에는 사용자에게 더 유용했지만, 이제는 곳곳에 검색 기능이 있어 논쟁의 여지는 있지만 SEO 도구로서의 성격이 더 강합니다. 그럼에도 HTML 사이트맵을 갖추는 것은 여전히 모범 사례로 간주됩니다.

Compass와 다른 부동산 사이트들은 주, 카운티, 우편번호의 계층 구조를 가진 HTML 사이트맵을 가지고 있으며, 말단 페이지는 현재 활성화된 Compass 독점 매물 전체로 연결됩니다. 이는 저희가 매물 페이지를 구글에 노출하는 또 다른 방법입니다.

XML 사이트맵

Compass와 같은 대형 웹사이트에서는 XML 사이트맵이 아마도 더 중요할 것입니다. 이는 Google Search Console에 업로드하거나 robots.txt에서 참조하는 단순한 XML 파일로, 사이트의 모든 URL을 단순히 나열합니다. 이를 통해 Googlebot은 수천 개의 링크를 따라갈 필요 없이 체계적으로 모든 상품 페이지를 찾을 수 있습니다.

Compass는 여러 개의 XML 사이트맵을 가지고 있습니다(여러 개를 가질 수 있습니다):

Sitemap: https://www.compass.com/sitemaps/exclusives/sales-sf/index.xml
Sitemap: https://www.compass.com/sitemaps/exclusives/sales-la/index.xml
Sitemap: https://www.compass.com/sitemaps/exclusives/sales-nyc/index.xml
Sitemap: https://www.compass.com/sitemaps/exclusives/sales-dc/index.xml
Sitemap: https://www.compass.com/sitemaps/exclusives/sales-other/index.xml
Sitemap: https://www.compass.com/sitemaps/exclusives/rentals/index.xml
...

각 sitemap index.xml은 실제 sitemap.xml 파일들로 연결되는 파일이며, 실제 파일은 다음과 같이 생겼습니다:

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
 <url>
  <loc>
   https://www.compass.com/listing/101-old-mamaroneck-road-unit-1b4-white-plains-ny-10605/409187998570262817/
  </loc>
  <lastmod>2020-02-22T01:25:55.877000+00:00</lastmod>
 </url>
 <url>
  <loc>
   https://www.compass.com/listing/4641-south-lincoln-street-englewood-co-80113/414572085652655249/
  </loc>
  <lastmod>2020-02-22T01:25:16.710000+00:00</lastmod>
 </url>
 ...

“lastmod” 필드는 선택 사항이며, 구글이 해당 페이지의 정보가 마지막으로 수정된 시점을 알 수 있게 하여 다시 크롤링해야 할지 판단하도록 합니다.

구글 문서에서 XML 사이트맵에 대해 더 읽어볼 수 있습니다.

더 나은 성능과 랭킹

페이지 내 기본 요소

개별 페이지를 발견 가능하게 만들기 위해 해야 할 다양한 기본 사항들이 있습니다:

페이지는 모바일 친화적이어야 합니다. 구글은 모바일 우선 색인 생성을 사용하므로, 모바일 기기에서 정말 잘 동작하도록 페이지를 최적화해야 합니다. 또한 모바일 기기와 데스크톱에서 서로 다른 콘텐츠를 제공하지 마세요. 이러한 것들은 Googlebot뿐만 아니라 사용자에게도 도움이 됩니다.
각 페이지는 간결하고 구체적인 <title> 태그를 가져야 합니다. 이는 구글이 페이지의 요지를 이해하는 데 도움이 되며, 일반적으로 검색 결과 페이지에 눈에 띄게 표시됩니다.
각 페이지는 meta description에 간략하지만 정확한 요약을 담아야 합니다. meta description에 대한 Moz 문서를 읽어보세요.
각 페이지는 좋은 구조를 가져야 합니다: 의미 있는 <h1> 및 <h2> 제목, 의미 있는 링크 텍스트, 적절한 alt 텍스트를 가진 이미지 등.
상품 페이지 등에 대해서는 구글에 더 자세한 정보를 제공하기 위해 JSON-LD와 같은 구조화된 데이터를 사용하세요. 이는 구글이 콘텐츠를 더 자세히 이해하는 데 도움이 될 뿐만 아니라, 예를 들어 검색 결과 페이지의 정보 상자에도 활용됩니다:

구글 검색 결과 페이지의 레시피 ‘정보 상자’

페이지 속도

2018년에 구글은 이제 페이지 속도를 모바일 페이지 순위를 결정하는 요소로 사용한다고 밝혔습니다. 따라서 페이지를 빠르게 만드는 것이 유리합니다.

당연히 가장 먼저 해야 할 일은 백엔드 HTML이 적시에 반환되도록 하는 것입니다. 이는 측정하기 쉽지만, 첫 단계에 불과합니다. 클라이언트 측 성능도 고려됩니다. 페이지 속도를 측정하고 개선하는 방법에 대한 구글의 많은 정보가 있으니 읽어보시길 권장합니다.

크롬에 바로 내장된 훌륭한 도구들을 이용해 구글이 보는 것처럼 페이지 속도를 로컬에서 측정할 수도 있습니다. 페이지에서 마우스 오른쪽 버튼을 클릭하고 검사를 클릭한 뒤, “Audits” 탭으로 이동해 모바일에 대해 “Performance” 감사를 실행해 보세요. (때로는 도움이 되는) 제안이 담긴 보기 좋은 리포트를 얻을 수 있습니다:

Lighthouse 성능 감사 스크린샷

속도에 대한 구글의 글은 자사의 속도 테스트에서 90/100점을 받았습니다. 나쁘지 않네요(아니면 조작된 걸까요? :-).

페이지 속도에는 많은 요소가 관여합니다:

첫 바이트까지의 시간: 서버가 첫 바이트를 반환하는 데 걸리는 네트워크 시간. 이후에는 사용자의 대역폭과 HTML 크기에 따라 달라지는 HTML 다운로드 시간이 있습니다. 크기를 작게 유지하세요!
첫 콘텐츠풀 페인트: DOM의 실제 콘텐츠로 첫 렌더링이 이루어지기까지의 시간. 이는 사용자에게 무언가 진행 중임을 보여주며, 구글은 이를 페이지 속도 신호 중 하나로 사용합니다.
상호작용까지의 시간: 사용자가 실제로 페이지와 상호작용할 수 있게 되기까지의 시간. 보통 페이지가 상호작용 가능해지려면 일부 JavaScript가 실행되어야 하므로, JavaScript 번들 크기, 시작 시간 등에 주의하세요.
정적 에셋: CSS와 JavaScript는 긴 만료 시간으로 캐시되어야 하며, 이상적으로는 CDN 뒤에 있어야 합니다. 또한 합리적인 범위 내에서 가능한 한 작아야 합니다. Moment.js와 같은 큰 JavaScript 패키지를 주의하세요!
이미지 로드 시간: 적절한 캐싱 헤더와 함께 적절한 크기의 이미지를 제공해야 하며, 이상적으로는 캐싱 CDN 뒤에 두어야 합니다. 페이지에서 많은 큰 이미지를 참조한다면 일부를 지연 로딩하는 것을 고려하세요.

주의하세요! 대부분의 회사와 마찬가지로 여러분도 페이지를 지속적으로 반복 개발하고 있으므로, 페이지가 점점 느려지고 있을 가능성이 큽니다. 페이지 속도에 대해 지속적으로 경계해야 합니다. 새로운 기능을 추가하거나 백엔드 서비스에 대한 추가 호출을 도입할 때 측정하세요.

링크와 도메인 권위

구글은 PageRank 알고리즘에서 탄생했습니다(재미있게도 PageRank는 웹 페이지가 아니라 래리 페이지의 이름에서 따온 것입니다).

PageRank는 페이지의 중요도를 대략적으로 추정하기 위해 해당 페이지로 연결되는 링크의 수와 품질을 세는 방식으로 동작합니다.

다시 말해, 다른 많은 페이지가 여러분의 페이지로 링크하면 순위가 더 잘 올라갑니다. 그리고 그 링크가 PageRank가 높은 페이지로부터 온 것이라면 더욱 좋습니다. 따라서 가능한 한 권위 있는 웹사이트들이 여러분의 페이지로 링크하도록 하는 것이 좋습니다.

이에 대한 예외는 rel=nofollow 링크입니다. “nofollow”는 사이트가 <a> 링크 태그에 추가하여 구글에게 이 링크를 따라가거나 순위 계산에 포함하지 말라는 신호를 보내는 속성입니다. 이는 일반적으로 블로그나 유튜브 댓글과 같은 사용자 생성 콘텐츠에 사용되며, 이러한 콘텐츠는 품질이 낮고 스팸성일 수 있습니다.

만약 이런 사이트들이 rel=nofollow를 사용하지 않는다면, 스패머들은 순위를 인위적으로 높이기 위해 자신의 페이지로 연결되는 수백 개의 링크를 제출할 것입니다. 그리고 “nofollow”가 도입되기 전에는 정확히 그런 일이 일어났습니다.

도메인 권위라는 SEO 개념도 있으며, 이는 특정 도메인이 전반적으로 얼마나 권위 있는지를 나타내는 Moz의 측정치입니다(예: nytimes.com은 100점 만점에 95점, stackoverflow.com은 93점, 제 작은 개인 웹사이트는 37점). 이는 구글의 측정치는 아니지만, 구글이 특정 도메인을 얼마나 중요하게 여기는지에 대한 합리적인 대리 지표로 보입니다.

더 읽어보기

이 글은 주로 엔지니어가 직접 통제할 수 있는 기술적인 SEO 개선에 대해 논의했습니다. 하지만 이는 이야기의 절반에 불과합니다.

이러한 기술적인 SEO 조치를 모두 수행하더라도 좋은 콘텐츠가 없다면 구글은 여러분을 상위에 노출시키지 않을 것이며 아무도 여러분 사이트를 사용하지 않을 것입니다. 훌륭한 SEO지만 형편없는 콘텐츠는 나쁜 SEO입니다. 반면에 좋은 콘텐츠가 있다면 이러한 기법을 따를 때 훨씬 더 잘 랭크될 기회를 얻을 수 있습니다.

구글의 SEO 초보자 가이드는 이러한 주제에 대해 원천에서 직접 들을 수 있는 훌륭한 자료이며, Moz 초보자 가이드 역시 마찬가지입니다.

연락을 원하시면 저희 robots.txt 상단의 배너를 확인해 보세요!