메타데이터, SEO 및 소셜

두 명의 방문자가 페이지에 도착하는데, 둘 다 인간이 보는 방식으로 페이지를 본 적이 없습니다. 하나는 페이지를 나열할지 여부와 어떻게 설명할지 결정하는 검색 엔진입니다. 다른 하나는 누군가 링크를 공유할 때 나타나는 작은 미리보기 카드를 만드는 소셜 플랫폼입니다. 둘 다 화면의 보이는 콘텐츠가 아니라 <head>의 작은 태그 블록을 읽습니다. 이 장은 검색 결과, 브라우저 탭, 공유 링크에서 페이지가 올바르게 표시되도록 그 블록을 작성하는 것에 관한 것입니다.
제목과 설명
모든 페이지에는 <title>이 필요합니다. 이것은 브라우저 탭, 북마크, 검색 결과 목록에서 페이지가 나타날 때 클릭 가능한 제목으로 표시되는 텍스트입니다. head에 있으며, 한 줄입니다:
<title>초보자를 위한 천연 발효 빵: 첫 번째 식빵, 단계별 가이드</title>검색 결과의 제목 아래에는 보통 페이지를 설명하는 문장이 있습니다. 이것은 **메타 설명**에서 나오며, head에 넣는 또 다른 태그입니다:
<meta name="description" content="천연 발효 빵 레시피, 첫 번째 반죽 섞기부터 바삭한 황금 빵 껍질까지, 각 단계별 타이밍 포함." />책장 위의 책을 상상해보세요. 제목은 책등에 인쇄되어 있어서 찾을 수 있고, 설명은 뒷표지의 설명으로 책을 열지 여부를 결정하는 데 도움이 됩니다.
<title> 요소는 필수이며, 문서당 정확히 하나입니다. 세 가지 역할을 합니다: 브라우저 탭에 레이블을 붙이고, 누군가 페이지를 북마크할 때 기본 이름이고, 검색 엔진이 결과에 표시하는 제목입니다. 목록을 훑어보는 사람을 위해 작성하고, 구별되는 단어를 먼저 놓고, 말줄임표로 잘리지 않도록 대략 60자로 유지하세요.
<meta name="description"> 태그는 제목 아래에 표시되는 문장입니다. 순위 요소는 아니지만, 클릭할지 여부를 결정하는 사람에 대한 당신의 제안이므로, 구체적으로 작성하고 모든 페이지에 대해 다른 설명을 작성하세요. 약 150~160자를 목표로 하세요. 생략하면 검색 엔진은 페이지 텍스트에서 일부를 가져와 자체 요약을 작성하며, 그 추측은 거의 당신의 문장만큼 좋지 않습니다.
<title>초보자를 위한 천연 발효 빵: 첫 번째 식빵</title>
<meta name="description" content="단계별 첫 번째 천연 발효 빵, 타이밍과 모든 흔한 실수를 고치는 방법 포함." /><title>은 SERP(검색 엔진 결과 페이지, 쿼리가 반환하는 결과 목록)에서 결과가 무엇이라고 말할지에 대해 완전히 제어하는 가장 강력한 페이지 내 텍스트입니다. 레이블이 아닌 카피로 취급할 가치가 있습니다: 구별되는 단어가 먼저 오는데, 끝이 잘리기 때문입니다. 모두가 말하는 문자 수는 실제로는 약 600픽셀의 픽셀 너비 제한이므로, 넓은 문자의 제목은 수가 제안하는 것보다 더 빨리 잘립니다. 검색 엔진은 또한 도움이 안 되는 제목을 다시 작성합니다. 예를 들어 효과를 위해 단어를 반복하거나 쿼리와 일치하지 않는 제목입니다. 따라서 명확하고 정확한 제목은 채운 제목보다 더 자주 유지됩니다.
설명은 순위 지정의 입력이 아닙니다. 그 전체 역할은 클릭률이며, 결과를 보고 클릭하는 사람의 비율이고, 더 날카로운 설명이 그 비율을 올립니다. 길이보다 더 중요한 두 가지 프로덕션 규칙이 있습니다. 첫째, 모든 페이지는 자체 제목과 설명을 가집니다; 전체 템플릿 사이트에서 하나의 전역 쌍을 배포하는 것은 서로 경쟁하고 보일러플레이트로 읽히는 거의 동일한 결과를 의미합니다. 둘째, 데이터에서 페이지를 만드는 사이트에서는 고정 문자열이 아닌 페이지 자체 필드에서 둘을 생성하여 제품 페이지가 제품의 이름을 지정하고 레시피 페이지가 레시피의 이름을 지정합니다.
<title>은 당신의 탭 레이블이고 사람들이 검색 결과에서 클릭하는 제목이므로, 명확하게 만드세요. <meta name="description">은 아래의 설명입니다. 둘 다 head에 있고, 각 페이지에 고유한 쌍을 제공하는 것은 예상했던 것보다 훨씬 적게 노력하면서 얼마나 도움이 되는지에 놀랐습니다. <title>, 구별되는 단어가 먼저, 약 60자. 설명은 순위에 영향을 주지 않으며, 클릭만 이기므로, 하나의 전역 줄 대신 페이지당 특정한 것을 작성하세요. 생략하면 엔진이 당신이 선택하지 않은 스니펫을 발명합니다. 문자 집합과 뷰포트, 다시 보기
처음 HTML 페이지의 스켈레톤은 두 개의 메타 태그로 시작했는데, 이들은 빠르게 붙여 넣고 잊기 쉽습니다. 두 개 모두 콘텐츠가 나타나기 전에 페이지를 읽고 렌더링하는 방법을 변경하기 때문에 다시 보기 가치가 있습니다.
첫 번째 태그는 문자 인코딩입니다:
<meta charset="UTF-8" />브라우저에 문자가 어떤 알파벳으로 작성되었는지 알려주므로, 악센트가 있는 문자, 곡선 따옴표, 이모지가 이상한 기호로 바뀌는 대신 올바르게 표시됩니다. 항상 UTF-8을 사용하세요; 모든 언어와 모든 이모지를 포함합니다.
두 번째 태그는 **뷰포트**이며, 페이지를 휴대폰 화면에 맞춥니다:
<meta name="viewport" content="width=device-width, initial-scale=1" />없으면, 휴대폰은 페이지가 넓은 데스크톱을 위해 만들어졌다고 가정하고 전체를 축소하여 텍스트가 너무 작아서 읽을 수 없을 때까지. 있으면, 페이지가 장치의 너비와 일치합니다. 이것을 인쇄하는 실제 종이의 크기를 브라우저에 알려주는 것으로 생각하세요.
<meta charset="UTF-8">는 문자 인코딩을 설정하며, 이는 파일의 원시 바이트에서 그들이 나타내는 문자로의 매핑입니다. head의 처음 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을 추가하지 마세요; 사람들이 텍스트를 확대하기 위해 꼬집는 것을 막으며, 많은 독자가 이에 의존합니다.
문자 집합 선언은 구문 분석이 두 단계 문제이기 때문에 존재합니다: 브라우저는 바이트 스트림을 가지고 있고 인코딩이 필요해서 그들을 문자로 바꿉니다. 인코딩이 늦게 선언되거나 파서가 처음 바이트에서 추측한 것과 충돌하면, 브라우저는 그 작업을 버리고 정확한 인코딩으로 맨 위부터 다시 구문 분석할 수 있으며, 이는 <meta charset="UTF-8">를 먼저 배치하여 피할 수 있는 작은 비용입니다. 응답이 HTTP Content-Type 헤더에서 charset도 수행하면, 헤더가 이기지만, 파일이 해당 헤더 없이 저장되거나 서빙될 때 올바르도록 메타 태그를 포함시킵니다. UTF-8은 웹의 정착된 기본값입니다; 다른 것은 마이그레이션할 레거시 상황입니다.
뷰포트 태그는 두 렌더링 모드 간의 스위치입니다. 없으면 모바일 브라우저는 넓은 가상 캔버스로 렌더링합니다 (역사적으로 약 980 CSS 픽셀). 결과를 축소합니다, 이것이 태그가 없는 페이지가 축소된 데스크톱처럼 보이는 이유입니다. width=device-width는 레이아웃 뷰포트를 장치에 바인딩하며, 이는 모든 반응형 CSS가 작동하기 위한 전제 조건입니다. 줌을 user-scalable=no 또는 낮은 maximum-scale로 억제하는 것은 접근성 실패입니다: WCAG(접근성에서 다루어진 웹 콘텐츠 접근성 지침, 접근 가능한 웹 콘텐츠에 대한 표준 참조)에서 불린다. 왜냐하면 사람들이 그들이 달리 읽을 수 없는 텍스트를 확대하는 것을 차단하기 때문입니다.
<meta charset="UTF-8">은 악센트가 있는 문자와 이모지가 깨진 텍스트로 바뀌는 것을 막으므로, 항상 포함시키세요. 뷰포트 줄은 페이지가 휴대폰에 맞게 만들어지고 축소되지 않게 합니다. 두 개의 태그를 한 번 복사하고 거의 다시 건드리지 않지만, 생략하는 것은 빠르게 나타납니다. UTF-8을 사용하고, 다른 것은 사용하지 마세요. width=device-width를 포함한 뷰포트 태그는 휴대폰에서 반응형 CSS를 작동하는 것이고, 절대로 줌을 비활성화하지 마세요, 사람들이 이에 의존합니다. user-scalable=no로 줌을 잠금하는 것은 WCAG에 실패하므로, 생략하세요. Open Graph 및 소셜 카드
링크를 채팅이나 소셜 게시물에 붙여 넣으면, 종종 그림, 제목, 텍스트 한 줄이 있는 작은 미리보기 카드가 나타납니다. 그 카드는 플랫폼이 추측하는 것이 아닙니다. 페이지는 head에서 **Open Graph**라고 불리는 태그 세트를 사용하여 플랫폼에 표시할 그림과 단어를 전달합니다:
<meta property="og:title" content="초보자를 위한 천연 발효 빵" />
<meta property="og:description" content="첫 번째 식빵, 단계별로." />
<meta property="og:image" content="https://breadschool.example/loaf.jpg" />이들은 앞의 설명 태그가 name을 사용한 곳에서 property를 사용합니다. 그것이 Open Graph 태그가 취하는 형태입니다; 패턴을 복사하고 단어와 이미지 주소를 변경하세요. 누군가 그것을 공유할 때마다 준비가 되어 있는 페이지에 작은 미리보기를 패킹하는 것으로 생각하세요.
Open Graph는 페이지를 공유 가능한 객체로 설명하는 메타 태그의 공유 어휘입니다. Facebook에서 시작되었으며 이제는 링크 미리보기를 표시하는 거의 모든 플랫폼에서 읽힙니다. 태그는 property="og:..."를 사용하고 필수는 5개입니다:
<meta property="og:title" content="초보자를 위한 천연 발효 빵" />
<meta property="og:description" content="첫 번째 식빵, 단계별, 타이밍 포함." />
<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" />Twitter, 이제 X, 자체 twitter: 태그를 읽지만 Open Graph 태그로 폴백하므로, 레이아웃을 변경하는 부분만 추가하면 됩니다:
<meta name="twitter:card" content="summary_large_image" />이것은 작은 썸네일이 아닌 큰 이미지 카드를 제공합니다. og:image를 약 1200 x 630픽셀로 만들어서 카드를 깔끔하게 채우고, 그것에 의존하기 전에 플랫폼의 자체 링크 미리보기 디버거에서 결과를 확인하세요.
이 태그의 대상은 소셜 스크레이퍼입니다: 링크가 게시될 때 플랫폼이 실행하는 봇으로, 페이지를 가져오고 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로 설정한 것을 추가하고, 이미지의 크기를 약 1200 x 630으로 합니다. 신뢰하기 전에 항상 플랫폼 디버거에서 카드를 확인하세요. og:image는 조용히 실패합니다. 플랫폼은 카드를 캐시하므로, 변경은 디버거에서 강제 재스크래핑이 필요합니다. 그리고 클라이언트 렌더링 태그는 종종 전혀 보이지 않으므로, JavaScript 앱이 서버에서 head를 렌더링해야 하는 이유입니다. Favicon 및 기타 링크 태그
브라우저 탭의 페이지 제목 옆에 있는 작은 아이콘은 **favicon**입니다. 그것은 누군가가 다른 탭들 사이에서 당신의 탭을 발견하는 방법입니다. head에서 <link> 태그로 하나를 추가합니다:
<link rel="icon" href="/favicon.png" />rel="icon" 부분은 브라우저에 이 파일이 페이지의 아이콘임을 알려주고, href는 이미지를 가리킵니다. 약 32 x 32픽셀의 작은 정사각형 이미지로 충분합니다. 작은 터치이지만, 사이트가 완성된 것처럼 느껴집니다.
<link> 요소는 페이지를 관련 파일에 연결하고, rel 속성은 그 파일이 무엇인지 말합니다. favicon은 rel="icon"을 사용하며, 현대적인 PNG나 SVG는 오래된 .ico 형식보다 더 나은 선택입니다. 누군가 당신의 사이트를 홈 화면에 저장할 때 iOS가 사용하는 이미지인 Apple 터치 아이콘도 추가하세요:
<link rel="icon" href="/favicon.svg" />
<link rel="apple-touch-icon" href="/apple-touch-icon.png" />하나 이상의 <link>가 여기서 자리를 얻습니다: 정규 URL. 동일한 페이지가 둘 이상의 주소(예: 후행 슬래시 있음/없음 또는 끝에 추적 매개변수)에서 접근 가능할 때, rel="canonical"은 실제 것으로 취급하고 싶은 하나의 주소의 이름을 지정합니다:
<link rel="canonical" href="https://breadschool.example/sourdough" />이것은 검색 엔진에 모든 중복을 그 URL에 분산하지 않고 그 단일 URL로 적립하도록 알려줍니다.
rel 속성은 관계 키워드입니다: 링크된 리소스가 이 문서에 무엇인지 나타내므로, 하나의 요소가 아이콘, 정규, 스타일시트, 및 사전로드를 다룹니다. 아이콘의 경우, 브라우저는 여러 개를 받아들이고 크기 및 형식으로 선택합니다; SVG 아이콘은 크기별 별도 파일이 없어도 모든 디스플레이로 확장되며, 오래된 브라우저를 위한 PNG 폴백이 있습니다. 레거시 favicon.ico는 호환성을 위해 유지되는 다중 해상도 형식이며 더 이상 먼저 도달하는 형식이 아닙니다.
정규 링크는 실제 순위 결과가 있는 것이므로, 정확하게 얻을 가치가 있습니다. 이것은 링크 에퀴티를 통합합니다, 페이지에 가리키는 링크로 전달되는 순위 값은 당신이 지명한 URL에 있습니다. 대신 중복 주소에 분산하는 것 대신. 좋은 관행은 모든 페이지에서 자가 참조 정규이므로 (각 페이지가 자체의 깔끔한 URL을 이름 지정합니다), 매개변수나 대체 경로가 나타날 때 모호함을 제거합니다. 실패 모드는 정규을 잘못된 페이지를 가리키는 것입니다: 전체 섹션에서 일반적인 하나의 정규을 하드코딩하는 템플릿은 검색 엔진에 그 안의 모든 페이지가 하나의 복사본이라고 알려주며, 나머지는 인덱스에서 떨어집니다. preload 및 preconnect와 같은 다른 rel 값은 리소스를 일찍 가져오거나 연결을 워밍업하는 성능 힌트입니다; 이들은 여기가 아닌 페이지 속도 토론에 속하므로, 작업이 아닌 포인터로 취급합니다.
<link rel="icon">과 작은 정사각형 이미지로 추가됩니다. 그것은 완성된 느낌의 작은 것입니다. head의 <link> 태그는 페이지가 이것과 같은 추가 파일을 가리키는 방법입니다. .ico 대신 PNG 또는 SVG와 함께 rel="icon"을 사용하고, 저장된 홈 화면에 대한 apple-touch-icon을 추가하세요. 정규 링크, rel="canonical"은 페이지가 여러 개에서 접근 가능할 때 실제 주소의 이름을 지정하므로, 검색 엔진은 그것을 분산하지 않고 하나의 URL을 신뢰합니다. rel은 관계 키워드이므로, 하나의 요소는 아이콘, 정규, 및 사전로드를 처리합니다. SVG 아이콘은 크기별 파일 없이 확장됩니다. 정규은 높은 위험이 있는 것입니다: 모든 페이지에서 자가 참조 정규은 안전하지만, 템플릿이 모든 페이지를 하나의 URL로 가리키는 것은 나머지를 인덱스에서 떨어집니다. 크롤링 기본 사항
검색 엔진은 웹 페이지를 방문하고, 읽고, 큰 목록에 추가하는 프로그램을 보냅니다. 그래서 사람들이 나중에 그것들을 찾을 수 있습니다. 그 프로그램은 **크롤러**이고, 대부분의 경우 당신이 그것을 하도록 하고 싶고 특별한 일을 하지 않습니다. 페이지가 검색에서 제외되기를 원한다면, 드래프트나 비공개 감사 페이지, 로봇 메타 태그로 말하세요:
<meta name="robots" content="noindex" />noindex는 "이 페이지를 검색 결과에 나열하지 마세요"를 의미합니다. 크롤러를 책장을 걸어 다니고 각 책을 카탈로그하는 사서로 생각해보세요; 이 태그는 이 하나를 건너뛰도록 요청하는 메모입니다.
크롤러는 당신의 HTML을 읽고, 그것이 발견하는 링크를 따라 더 많은 페이지에 도달하고, 결과에 제공할 수 있도록 콘텐츠를 인덱싱합니다. 로봇 메타 태그로 그것을 조종합니다. noindex는 페이지를 결과에서 제외하고, nofollow는 크롤러가 페이지의 링크를 통해 순위 신용을 전달하지 않도록 알려줍니다:
<meta name="robots" content="noindex, nofollow" />이것을 robots.txt와 혼동하지 마세요. 사이트의 루트에 있는 별도 파일로, 크롤러가 모든 것에 접근할 수 있습니다. 메타 태그는 크롤러가 이미 도달한 페이지의 인덱싱을 제어합니다; 파일은 접근을 제어합니다.
오래된 <meta name="keywords"> 태그를 완전히 건너뛰세요. 한때 페이지가 자신의 키워드를 나열할 수 있게 했고, 검색 엔진은 오래전부터 그것을 신뢰하는 것을 멈췄으며, 오늘날 아무것도 하지 않습니다. 실제로 페이지 순위를 올리는 것은 일상적인 좋은 건설입니다: 명확한 제목, 실제 제목, 의미론적 HTML 페이지의 각 부분 이름 지정, 설명 링크 텍스트, 및 빠르게 로드되는 페이지.
검색 엔진이 취하는 세 단계를 구분하는 것이 도움이 됩니다. 태그가 다른 것들에 작용하기 때문입니다. 크롤은 페이지를 가져오는 것입니다. 인덱스는 나중에 저장하고 이해하는 것입니다. 순위는 주어진 쿼리에 대해 다른 페이지에 대해 주문하는 것입니다. noindex를 가진 로봇 메타 태그는 인덱싱에 작용합니다; robots.txt는 크롤링에 작용합니다; X-Robots-Tag HTTP 헤더는 PDF와 같은 비-HTML 파일에 동일한 인덱싱 규칙을 적용할 수 있습니다. 고전적인 실수는 robots.txt에서 페이지를 차단하고 또한 noindex를 추가하는 것입니다: 크롤러가 페이지를 가져올 수 없으므로, 그것은 noindex를 절대 보지 않으며, URL은 설명이 없는 결과에서 맴돌 수 있습니다. 페이지를 인덱스에서 제거하고 싶다면, 그것을 크롤되게 놔두고 noindex를 읽게 하세요.
현대 크롤러는 JavaScript를 렌더링하지만, 지연 및 제한된 예산 내에서, 클라이언트 측 가져오기 후에만 나타나는 콘텐츠는 느리게 또는 전혀 인덱싱되지 않습니다; 신뢰할 수 있는 답은 발견되어야 할 것을 서버에서 렌더링하는 것입니다. 검색 엔진이 직접 사용할 수 있는 형태로 페이지를 설명하려면, 구조화된 데이터를 추가하세요, 페이지에 대한 기계 판독 가능한 사실. 표준 방법은 JSON-LD 블록입니다, JSON을 사용하여 Schema.org 어휘로 작성된 구조화된 데이터, head 또는 body 내에 <script type="application/ld+json"> 태그 내에 배치됩니다:
{
"@context": "https://schema.org",
"@type": "Recipe",
"name": "초보자 천연 발효 빵",
"totalTime": "PT24H",
"recipeYield": "1 loaf"
}이것 자체로는 순위를 올리지 않습니다; 그것은 페이지가 풍부한 결과에 적합하게 만듭니다, SERP에서 두드러지는 별, 가격 또는 레시피 세부 정보가 있는 향상된 목록입니다. 순위 자체에 관해서는, 대부분의 사람들이 조정하는 것은 신화입니다. keywords 메타 태그는 2009년 경부터 무시되었습니다. 더 관련성이 있어 보이도록 키워드를 반복하는 것은 감지되고 당신에게 대항합니다. 설명은 순위 입력이 아닙니다. 지속적으로 이기는 것은 쿼리를 답변하는 콘텐츠, 구조를 읽을 수 있게 만드는 의미론적 마크업, 다른 사이트의 링크, 및 빠르고 안정적으로 로드되는 페이지입니다. 이 장의 태그는 페이지를 표시 가능하고 올바르게 이해되게 만듭니다; 순위할 가치가 있는 페이지가 되는 것을 대체하지 않습니다.
<meta name="robots" content="noindex">를 추가하세요. 이것이 이 단계에서 당신이 도달할 주요 손잡이이므로, 나머지를 과하게 생각할 필요가 없습니다. noindex, nofollow); 별도 robots.txt 파일은 크롤링을 제어합니다. 오래된 keywords 메타 태그는 죽었으므로, 무시하세요. 실제 순위는 명확한 제목, 의미론적 HTML, 좋은 링크, 및 빠른 페이지에서 나오며, 마법 태그에서 나오지 않습니다. robots.txt에서 페이지를 차단하고 noindex를 추가하는 것입니다. 크롤러가 페이지를 가져오지 않기 때문에 태그를 읽지 않습니다. JSON-LD는 순위 부스트가 아닌 풍부한 결과를 얻습니다. Keywords 메타는 죽었고; 콘텐츠와 의미론이 실제로 이깁니다. 
