메타데이터, SEO, 그리고 소셜


두 종류의 방문자가 여러분의 페이지를 사람처럼 눈으로 보지 않고 찾아옵니다. 하나는 이 페이지를 목록에 올릴지, 어떻게 소개할지 결정하는 검색 엔진입니다. 다른 하나는 누군가 링크를 공유했을 때 나타나는 작은 미리보기 카드를 만드는 소셜 플랫폼입니다. 둘 다 화면에 보이는 내용이 아니라 <head> 안의 작은 태그 블록을 읽습니다. 이 장에서는 페이지가 검색 결과, 브라우저 탭, 공유된 링크에서 제대로 나타나도록 이 태그 블록을 작성하는 방법을 다룹니다.
title과 description
모든 페이지에는 <title>이 필요합니다. 이것은 브라우저 탭과 북마크에 표시되는 텍스트이며, 페이지가 검색 결과 목록에 나타날 때 클릭할 수 있는 제목이기도 합니다. head 안에 있으며, 한 줄로 짧게 씁니다.
<title>Sourdough for beginners: your first loaf, step by step</title>검색 결과에서 이 제목 아래에는 보통 페이지를 설명하는 문장이 함께 표시됩니다. 이는 head에 넣는 또 다른 태그인 **meta description**에서 나옵니다.
<meta name="description" content="Simple sourdough recipes, from mixing your first dough to a crisp golden crust, with timings for each step." />책장에 놓인 책을 떠올려 보세요. title은 책등에 인쇄되어 있어서 그것으로 책을 찾아낼 수 있고, description은 책 표지 뒤쪽에 적힌 소개 문구로, 책을 펼쳐볼지 결정하는 데 도움을 줍니다.
<title> 요소는 필수이며, 문서마다 정확히 하나만 있어야 합니다. 이 요소는 세 가지 역할을 합니다. 브라우저 탭에 이름을 붙이고, 누군가 이 페이지를 북마크할 때 기본 이름이 되며, 검색 엔진이 검색 결과에 보여주는 제목이 됩니다. 목록을 훑어보는 사람을 위해 쓰되, 눈에 띄는 단어를 앞에 두고, 말줄임표로 잘리지 않도록 대략 60자 정도로 유지하세요.
<meta name="description"> 태그는 그 제목 아래에 표시되는 문장입니다. 순위에 영향을 주는 요소는 아니지만, 클릭할지 결정하는 사람에게 던지는 여러분의 홍보 문구이므로 구체적으로 쓰고 페이지마다 다르게 작성하세요. 대략 150~160자를 목표로 하세요. 이를 생략하면 검색 엔진이 페이지 본문에서 문장을 뽑아 스스로 요약을 만드는데, 이 요약은 여러분이 직접 쓴 문장만큼 좋은 경우가 거의 없습니다.
<title>Sourdough for beginners: your first loaf</title>
<meta name="description" content="A step-by-step first sourdough, with timings and a fix for every common mistake." /><title>은 SERP(검색 엔진 결과 페이지, 검색어를 입력했을 때 반환되는 결과 목록)에서 결과가 어떻게 표시되는지를 여러분이 온전히 통제할 수 있는, 페이지 내 텍스트 중 가장 강력한 요소입니다. 이것은 단순한 라벨이 아니라 카피로 다뤄야 합니다. 끝부분이 잘리기 때문에 눈에 띄는 단어를 앞에 두어야 합니다. 흔히 말하는 글자 수 제한은 사실 대략 600픽셀 정도의 픽셀 너비 제한이기 때문에, 넓은 문자로 이루어진 제목은 글자 수만으로 예상하는 것보다 더 일찍 잘립니다. 검색 엔진은 도움이 되지 않는다고 판단한 제목을 자체적으로 다시 쓰기도 합니다. 예를 들어 어떤 단어를 강조하려고 반복하거나 검색어와 맞지 않는 제목이 그런 경우이며, 명확하고 정확한 제목일수록 그런 재작성을 덜 겪습니다.
description은 순위 산정에 들어가는 입력값이 아닙니다. description의 유일한 역할은 클릭률(결과를 본 사람 중 실제로 클릭한 비율)을 높이는 것이며, 더 예리하게 쓴 description은 그 비율을 끌어올립니다. 길이보다 중요한 두 가지 운영 원칙이 있습니다. 첫째, 페이지마다 각자의 title과 description을 가져야 합니다. 템플릿으로 찍어낸 사이트 전체에 하나의 전역 문구를 쓰면 거의 똑같은 결과들이 서로 경쟁하게 되고 획일적으로 보입니다. 둘째, 데이터로 페이지를 생성하는 사이트라면 고정된 문자열이 아니라 페이지 자체의 필드값에서 title과 description을 생성해서, 상품 페이지는 그 상품의 이름을, 레시피 페이지는 그 레시피의 이름을 담도록 하세요.
<title>은 탭 라벨이자 사람들이 검색 결과에서 클릭하는 제목이니 명확하게 작성하세요. <meta name="description">은 그 아래에 붙는 소개 문구입니다. 둘 다 head 안에 있고, 페이지마다 각자의 title과 description을 주는 일은 그 효과에 비해 생각보다 훨씬 덜 힘들었습니다. <title>은 하나, 눈에 띄는 단어는 앞에, 대략 60자로 씁니다. description은 순위에 영향을 주지 않고 클릭을 얻어낼 뿐이니, 전역으로 하나 쓰지 말고 페이지마다 구체적으로 작성하세요. 생략하면 엔진이 여러분이 고르지 않은 스니펫을 알아서 만들어냅니다. charset과 viewport, 다시 살펴보기
Your first HTML page의 골격에서는 붙여넣고 나면 금방 잊어버리기 쉬운 두 개의 meta 태그로 시작했습니다. 이 둘은 다시 살펴볼 만한데, 둘 다 어떤 콘텐츠가 나타나기도 전에 페이지가 읽히고 렌더링되는 방식을 바꾸기 때문입니다.
첫 번째 태그는 문자 인코딩입니다.
<meta charset="UTF-8" />이 태그는 글자들이 어떤 문자 체계로 쓰여 있는지를 브라우저에 알려주어, 발음 구별 기호가 붙은 문자나 곡선 인용부호, 이모지가 이상한 기호로 바뀌지 않고 제대로 표시되게 합니다. 항상 UTF-8을 사용하세요. 모든 언어와 모든 이모지를 포함합니다.
두 번째 태그는 **viewport**로, 페이지를 휴대폰 화면에 맞춰줍니다.
<meta name="viewport" content="width=device-width, initial-scale=1" />이 태그가 없으면 휴대폰은 페이지가 넓은 데스크톱 화면용으로 만들어졌다고 가정하고 텍스트를 읽기 힘들 정도로 작아질 때까지 전체를 축소해 버립니다. 이 태그가 있으면 페이지가 기기의 너비에 맞춰집니다. 인쇄할 종이의 실제 크기를 브라우저에 알려주는 것이라고 생각하면 됩니다.
<meta charset="UTF-8">은 문자 인코딩, 즉 파일의 원시 바이트를 그것이 나타내는 문자로 매핑하는 방식을 설정합니다. 이 태그는 문서의 처음 1024바이트 이내, 그리고 head 안에서 가장 먼저 나타나야 합니다. 파서가 뒤이어 나오는 텍스트를 해석하기 전에 인코딩을 알아야 하기 때문입니다. UTF-8은 여러분이 써야 할 유일한 선택지입니다. 모든 언어의 모든 문자를 인코딩할 수 있습니다.
<meta name="viewport" content="width=device-width, initial-scale=1">은 페이지를 휴대폰에서 반응형으로 만드는 태그입니다. width=device-width는 페이지의 레이아웃 너비를 기기 자체의 너비에 맞추고, initial-scale=1은 축소된 상태가 아니라 정상 배율로 페이지를 열게 합니다. 이 태그를 빼면 모바일 브라우저는 대략 980픽셀짜리 데스크톱 레이아웃이라고 가정한 뒤 그것을 축소해서 맞춥니다. 확대를 막기 위해 user-scalable=no나 maximum-scale을 추가하지 마세요. 많은 독자가 의지하는 손가락으로 확대하는 동작을 막아버리기 때문입니다.
charset 선언이 존재하는 이유는 파싱이 두 단계로 이루어지는 문제이기 때문입니다. 브라우저는 바이트 스트림을 가지고 있고, 이를 문자로 바꾸려면 인코딩이 필요합니다. 인코딩 선언이 늦게 나오거나 파서가 앞선 바이트에서 추측한 인코딩과 충돌하면, 브라우저는 이미 한 작업을 버리고 올바른 인코딩으로 맨 처음부터 다시 파싱해야 할 수 있습니다. <meta charset="UTF-8">을 맨 앞에 두면 이 작은 비용을 피할 수 있습니다. 응답의 HTTP Content-Type 헤더에도 charset이 실려 있다면 헤더가 우선하지만, 그 헤더 없이 파일이 저장되거나 서빙될 때를 대비해 여전히 meta 태그를 넣어두어야 합니다. UTF-8은 웹의 확고한 기본값이며, 그 외의 인코딩은 벗어나야 할 낡은 상황일 뿐입니다.
viewport 태그는 두 렌더링 모드 사이의 스위치입니다. 이 태그가 없으면 모바일 브라우저는 넓은 가상 캔버스(역사적으로 약 980 CSS 픽셀)에 렌더링한 다음 그 결과를 축소하는데, 태그가 없는 페이지가 축소된 데스크톱처럼 보이는 이유가 바로 이것입니다. width=device-width는 레이아웃 뷰포트를 기기에 맞춰 결합시키며, 이는 어떤 반응형 CSS든 제대로 동작하기 위한 전제 조건입니다. user-scalable=no나 낮은 maximum-scale로 확대를 막는 것은 접근성 실패입니다. WCAG(웹 콘텐츠 접근성 가이드라인, 접근 가능한 웹 콘텐츠를 위한 표준 참조 문서로 접근성에서 다룹니다)에서도 이 점을 명시적으로 지적합니다. 다른 방법으로는 글자를 읽을 수 없는 사람들이 확대할 수 있는 방법을 막아버리기 때문입니다.
<meta charset="UTF-8">은 발음 구별 기호나 이모지가 알아볼 수 없는 문자로 바뀌는 것을 막아주니 항상 넣어두세요. viewport 줄은 페이지가 작은 데스크톱처럼 축소되지 않고 휴대폰에 맞게 표시되도록 합니다. 한 번 복사해두면 다시 손댈 일이 거의 없는 두 태그지만, 빼먹으면 바로 눈에 띕니다. UTF-8 외에는 쓰지 마세요. width=device-width가 들어간 viewport 태그가 있어야 휴대폰에서 반응형 CSS가 동작하며, 확대 기능은 절대 막지 마세요, 많은 사람이 의지합니다. user-scalable=no로 확대를 막는 것은 WCAG를 위반하니 넣지 마세요. Open Graph와 소셜 카드
채팅이나 소셜 게시물에 링크를 붙여넣으면 사진, 제목, 한 줄짜리 설명이 담긴 작은 미리보기 카드가 종종 나타납니다. 이 카드는 플랫폼이 그냥 추측해서 만드는 것이 아닙니다. 페이지가 head에 있는 **Open Graph**라는 태그 모음을 통해 어떤 사진과 문구를 보여줄지 직접 건네줍니다.
<meta property="og:title" content="Sourdough for beginners" />
<meta property="og:description" content="Your first loaf, step by step." />
<meta property="og:image" content="https://breadschool.example/loaf.jpg" />앞서 description 태그는 name을 썼는데, 여기서는 property를 쓴다는 점을 눈여겨보세요. 이것이 Open Graph 태그의 형식이니, 이 패턴을 그대로 복사해서 문구와 이미지 주소만 바꾸면 됩니다. 누군가 공유할 순간을 위해 페이지 안에 작은 미리보기를 미리 담아두는 것이라고 생각하면 됩니다.
Open Graph는 페이지를 공유 가능한 객체로 설명하기 위한, 여러 플랫폼이 함께 쓰는 meta 태그 어휘 체계입니다. 페이스북에서 시작되었고, 지금은 링크 미리보기를 보여주는 거의 모든 플랫폼이 이를 읽습니다. 태그는 property="og:..." 형식을 쓰고, 핵심은 다섯 가지입니다.
<meta property="og:title" content="Sourdough for beginners" />
<meta property="og:description" content="Your first loaf, step by step, with timings." />
<meta property="og:image" content="https://breadschool.example/loaf.jpg" />
<meta property="og:url" content="https://breadschool.example/sourdough" />
<meta property="og:type" content="article" />트위터, 지금의 X는 자체 twitter: 태그를 읽지만 그것이 없으면 Open Graph 태그로 대체하므로, 레이아웃을 바꾸는 부분만 추가하면 됩니다.
<meta name="twitter:card" content="summary_large_image" />이렇게 하면 작은 썸네일 대신 큰 이미지가 들어간 카드가 나타납니다. og:image는 카드를 깔끔하게 채우도록 대략 1200x630픽셀로 만들고, 이를 믿고 쓰기 전에 플랫폼 자체의 링크 미리보기 디버거로 결과를 확인해 보세요.
이 태그들이 대상으로 삼는 독자는 소셜 스크레이퍼, 즉 링크가 게시될 때 플랫폼이 실행하는 봇입니다. 이 봇은 페이지를 가져와서 head만 읽고, 스크롤이나 클릭을 하지 않으며 보통 JavaScript도 실행하지 않습니다. Open Graph를 작성하는 방식은 전부 이 사실에서 나옵니다. og:image는 https://와 도메인을 포함한 절대 URL이어야 합니다. /loaf.jpg 같은 상대 경로는 원격 스크레이퍼가 페이지를 읽을 때 이를 해석할 페이지 컨텍스트가 없기 때문입니다. 이 태그들이 name 대신 property 속성을 쓰는 이유는 Open Graph가 마크업 안에 구조화된 데이터를 넣는 오래된 표준인 RDFa로 정의되어 있기 때문입니다. 실용적으로 기억할 것은 og: 태그는 property를 쓴다는 것과, 이를 name으로 "고쳐서는" 안 된다는 것뿐입니다.
실무에서 마주치는 두 가지 현실이 사람들을 곤란하게 합니다. 첫째, 플랫폼은 스크레이핑한 카드를 캐시하므로, 태그를 수정해도 플랫폼의 디버거를 통해 강제로 재스크레이핑하지 않으면 이미 공유된 링크는 업데이트되지 않습니다. 둘째, 대부분의 스크레이퍼는 JavaScript를 실행하지 않으므로, 싱글 페이지 앱이 클라이언트에서 주입한 Open Graph 태그는 아예 보이지 않는 경우가 많습니다. 이때 카드는 밋밋한 제목만 나오거나 아무것도 나오지 않는 상태로 대체됩니다. 페이지가 JavaScript로 만들어진다면, 해결책은 서버에서 head를 렌더링해서 스크레이퍼가 읽는 첫 응답에 태그가 실려 있도록 하는 것입니다. 이는 다음 절에서 다룰 크롤링을 형성하는 것과 같은 제약입니다.
og:title, og:description, og:image에서 나옵니다. 이들은 name 대신 property를 쓰는데, 처음엔 어색해 보이지만 원래 그렇게 쓰는 것입니다. 이 태그들을 넣으면 링크가 더 이상 밋밋하게 보이지 않습니다. og:title, og:description, og:image, og:url, og:type. 큰 이미지를 원하면 twitter:card를 summary_large_image로 설정하고, 이미지는 대략 1200x630 크기로 만드세요. 신뢰하기 전에 항상 플랫폼 디버거로 카드를 확인하세요. og:image는 조용히 실패합니다. 플랫폼은 카드를 캐시하니, 변경 사항은 디버거에서 강제로 재스크레이핑해야 합니다. 그리고 클라이언트에서 렌더링된 태그는 아예 보이지 않는 경우가 많아서, JavaScript 앱은 head를 서버에서 렌더링해야 합니다. Favicon과 그 밖의 link 태그
페이지 제목 옆, 브라우저 탭에 있는 작은 아이콘이 **favicon**입니다. 여러분의 탭을 여러 개의 다른 탭 사이에서 알아볼 수 있게 해주는 역할을 합니다. head에 <link> 태그를 넣어서 추가합니다.
<link rel="icon" href="/favicon.png" />rel="icon" 부분은 이 파일이 페이지의 아이콘이라고 브라우저에 알려주고, href는 그 이미지를 가리킵니다. 대략 32x32픽셀 정도의 작은 정사각형 이미지면 충분합니다. 작은 요소지만 사이트가 완성된 느낌을 줍니다.
<link> 요소는 페이지를 관련 파일에 연결하고, rel 속성은 그 파일이 무엇인지를 나타냅니다. favicon은 rel="icon"을 쓰며, 오래된 .ico 형식보다는 현대적인 PNG나 SVG가 더 나은 선택입니다. Apple touch icon도 추가하세요. 누군가 여러분의 사이트를 홈 화면에 저장할 때 iOS가 사용하는 이미지입니다.
<link rel="icon" href="/favicon.svg" />
<link rel="apple-touch-icon" href="/apple-touch-icon.png" />여기서 언급할 만한 <link>가 하나 더 있습니다. **canonical URL**입니다. 같은 페이지가 여러 주소로 접근 가능한 경우, 예를 들어 끝에 슬래시가 붙거나 없는 경우, 또는 끝에 추적 파라미터가 붙는 경우, rel="canonical"은 진짜라고 취급해야 할 하나의 주소를 지정합니다.
<link rel="canonical" href="https://breadschool.example/sourdough" />이렇게 하면 검색 엔진이 모든 중복 주소를 나눠서 평가하지 않고, 그 하나의 URL로 몰아서 평가하게 됩니다.
rel 속성은 관계를 나타내는 키워드입니다. 즉 링크된 리소스가 이 문서에 대해 무엇인지를 나타내며, 그래서 아이콘, canonical, 스타일시트, preload가 모두 하나의 요소로 처리됩니다. 아이콘의 경우 브라우저는 여러 개를 받아들여 크기와 형식에 따라 선택합니다. SVG 아이콘은 크기별로 파일을 따로 만들지 않고도 어떤 화면에나 맞춰 확장되며, 오래된 브라우저를 위한 대체용으로 PNG를 함께 둡니다. 오래된 favicon.ico는 호환성을 위해 남겨둔 다중 해상도 형식으로, 지금은 먼저 손이 가야 할 형식이 아닙니다.
canonical 링크는 실제 순위에 영향을 미치는 요소이므로 정확히 맞춰두어야 할 가치가 있습니다. 이는 링크 지분, 즉 페이지를 향한 링크들이 전달하는 순위 가치를 여러 중복 주소로 흩어놓지 않고 여러분이 지정한 URL로 모아줍니다. 좋은 방법은 모든 페이지에 자기 자신을 가리키는 canonical을 두는 것입니다(각 페이지가 자신의 깔끔한 URL을 스스로 지정). 이렇게 하면 파라미터나 대체 경로가 나타나도 모호함이 없어집니다. 실패하는 경우는 canonical이 잘못된 페이지를 가리킬 때입니다. 한 섹션 전체에 하나의 canonical을 하드코딩한 템플릿은 그 섹션 안의 모든 페이지가 하나의 복사본이라고 검색 엔진에게 말하는 셈이 되고, 나머지는 색인에서 빠져나갑니다. preload나 preconnect 같은 다른 rel 값은 리소스를 미리 가져오거나 연결을 미리 준비하는 성능 힌트입니다. 이는 이 글이 아니라 페이지 속도를 다루는 논의에 속하니, 여기서는 할 일이 아니라 참고할 방향으로만 알아두세요.
<link rel="icon">과 작은 정사각형 이미지로 추가합니다. 작은 요소지만 사이트가 완성된 느낌을 줍니다. head 안의 <link> 태그는 이런 추가 파일을 페이지에 연결하는 방법입니다. .ico 대신 PNG나 SVG로 rel="icon"을 쓰고, 홈 화면에 저장할 때를 위해 apple-touch-icon도 추가하세요. canonical 링크, 즉 rel="canonical"은 한 페이지가 여러 주소로 접근 가능할 때 진짜 주소를 지정해서, 검색 엔진이 하나의 URL로 평가를 몰아주도록 합니다. rel은 관계를 나타내는 키워드이며, 그래서 아이콘, canonical, preload가 모두 하나의 요소로 처리됩니다. SVG 아이콘은 크기별 파일 없이도 확장됩니다. canonical은 위험도가 높은 요소입니다. 페이지마다 자기 자신을 가리키는 canonical은 안전하지만, 모든 페이지를 하나의 URL로 가리키는 템플릿은 나머지를 색인에서 빠지게 합니다. 크롤링 가능성의 기본
검색 엔진은 웹 페이지를 방문해서 읽고, 나중에 사람들이 찾을 수 있도록 큰 목록에 추가하는 프로그램을 내보냅니다. 이 프로그램이 **크롤러**이며, 대부분의 경우 크롤러가 제 할 일을 하도록 두고 여러분은 특별히 아무것도 하지 않아도 됩니다. 검색에서 빼두고 싶은 페이지, 예를 들어 초안이나 비공개 감사 페이지가 있다면 robots meta 태그로 그렇게 표시합니다.
<meta name="robots" content="noindex" />noindex는 "이 페이지를 검색 결과에 올리지 말아주세요"라는 뜻입니다. 크롤러를 서가를 돌며 책을 하나씩 목록에 정리하는 사서라고 생각해 보세요. 이 태그는 이 책만은 건너뛰어 달라고 사서에게 남기는 메모 같은 것입니다.
크롤러는 여러분의 HTML을 읽고, 그 안에서 발견한 링크를 따라가 더 많은 페이지에 도달하며, 콘텐츠를 색인화해서 검색 결과로 제공할 수 있게 합니다. 이를 제어하는 것이 robots meta 태그입니다. noindex는 페이지를 검색 결과에서 제외하고, nofollow는 페이지 안의 링크를 통해 순위 가치를 전달하지 말라고 크롤러에게 알려줍니다.
<meta name="robots" content="noindex, nofollow" />이를 robots.txt와 혼동하지 마세요. robots.txt는 사이트 루트에 있는 별도의 파일로, 크롤러가 아예 가져올 수 있는 페이지가 어떤 것인지를 제어합니다. meta 태그는 크롤러가 이미 도달한 페이지의 색인 여부를 제어하고, 파일은 접근 자체를 제어합니다.
오래된 <meta name="keywords"> 태그는 완전히 무시하세요. 예전에는 페이지가 자신만의 키워드를 나열할 수 있게 해주었지만, 검색 엔진이 이를 신뢰하지 않게 된 지 이미 여러 해가 지났고, 오늘날에는 아무 효과도 없습니다. 실제로 페이지 순위에 도움이 되는 것은 평범하지만 제대로 된 기본기입니다. 명확한 제목, 실질적인 헤딩, 페이지의 각 부분을 명명하는 시맨틱 HTML, 설명이 담긴 링크 텍스트, 그리고 빠르게 로드되는 페이지입니다.
검색 엔진이 거치는 단계를 세 가지로 구분해 보면 도움이 됩니다. 태그마다 작용하는 단계가 다르기 때문입니다. **크롤(crawl)**은 페이지를 가져오는 것입니다. **색인(index)**은 나중을 위해 이를 저장하고 이해하는 것입니다. **순위(rank)**는 특정 검색어에 대해 다른 페이지들과 비교해 순서를 정하는 것입니다. noindex가 붙은 robots meta 태그는 색인화에 작용하고, robots.txt는 크롤링에 작용하며, X-Robots-Tag HTTP 헤더는 PDF 같은 비HTML 파일에 같은 색인 규칙을 적용할 수 있습니다. 전형적인 실수는 robots.txt에서 어떤 페이지를 막아두고 동시에 그 페이지에 noindex도 추가하는 것입니다. 크롤러는 그 페이지를 가져올 수 없으므로 noindex를 아예 보지 못하고, 그러면 설명 없이 그 URL이 결과에 계속 남아있을 수 있습니다. 페이지를 색인에서 빼고 싶다면 크롤은 허용하고 noindex가 읽히도록 두세요.
현대 크롤러는 JavaScript를 렌더링하긴 하지만, 지연이 있고 제한된 예산 안에서만 처리합니다. 그래서 클라이언트 측 요청 이후에야 나타나는 콘텐츠는 색인이 느리거나 아예 이루어지지 않습니다. 확실한 해답은 반드시 발견되어야 하는 콘텐츠를 서버에서 렌더링하는 것입니다. 검색 엔진이 직접 활용할 수 있는 형태로 페이지를 설명하려면, 구조화된 데이터, 즉 페이지에 관한 기계가 읽을 수 있는 사실 정보를 추가하세요. 표준적인 방법은 JSON-LD 블록, 즉 Schema.org 어휘를 사용해 JSON으로 작성한 구조화된 데이터로, head나 body 안의 <script type="application/ld+json"> 태그 안에 넣습니다.
{
"@context": "https://schema.org",
"@type": "Recipe",
"name": "Beginner sourdough",
"totalTime": "PT24H",
"recipeYield": "1 loaf"
}이것만으로는 순위가 오르지 않습니다. 대신 리치 결과, 즉 별점이나 가격, 레시피 상세 정보 등으로 SERP에서 눈에 띄는 강화된 결과에 노출될 자격을 얻게 해줍니다. 순위 자체에 관해서는, 사람들이 손보려고 하는 것들 대부분이 근거 없는 믿음입니다. keywords meta 태그는 2009년 무렵부터 이미 무시되고 있습니다. 관련성을 높이려고 키워드를 반복하는 것은 감지되며 오히려 불리하게 작용합니다. description은 순위 산정에 들어가는 입력값이 아닙니다. 꾸준히 통하는 것은 검색어에 답을 주는 콘텐츠, 구조를 알아보기 쉽게 만드는 시맨틱 마크업, 다른 사이트에서 오는 링크, 그리고 빠르고 안정적으로 로드되는 페이지입니다. 이 장에서 다룬 태그들은 페이지를 보기 좋고 정확히 이해되게 만들어줄 뿐, 페이지가 순위에 오를 만한 가치를 가지고 있는 것을 대신해주지는 않습니다.
<meta name="robots" content="noindex">를 추가하세요. 지금 단계에서는 이것이 가장 자주 손댈 다이얼이니, 나머지는 아직 너무 깊이 고민하지 않아도 됩니다. noindex, nofollow), 별도의 robots.txt 파일은 크롤링을 제어합니다. 오래된 keywords meta 태그는 죽은 태그이니 무시하세요. 실제 순위는 명확한 제목, 시맨틱 HTML, 좋은 링크, 빠른 페이지에서 나오는 것이지 마법 같은 태그에서 나오지 않습니다. robots.txt에서 페이지를 막아두고 noindex도 추가하는 것인데, 크롤러가 그 페이지를 가져오지 않으니 태그를 읽을 일도 없습니다. JSON-LD는 리치 결과를 얻게 해줄 뿐 순위를 올려주지는 않습니다. keywords meta는 죽었고, 콘텐츠와 시맨틱이 실제로 승부를 가릅니다. 
