[연재] × 사이트맵을 15배로 늘렸더니 노출이 0이 됐다

검색 결과에 하루 90번쯤 뜨던 게 0이 됐습니다

8월 9일 아침이었어요. 서치콘솔을 열었는데 그래프가 절벽이었습니다.

7월 26일부터 28일까지는 하루에 90번쯤 검색 결과에 떴어요. 클릭은 거의 없었지만 그래도 뜨긴 뜬 거죠. 도메인 붙인 지 며칠 만에 숫자가 올라가는 걸 보는 재미가 있었습니다.

그게 7월 29일에 꺾이고, 30일에 0이 됐습니다.

그리고 열흘이 지나도 안 돌아왔어요. 더 무서웠던 건 노출이 0이라는 사실보다 그 아래 있던 줄이었습니다. 구글이 제 사이트맵을 마지막으로 읽어간 날짜가 7월 31일로 멈춰 있었어요. 8월 1일부터 9일까지, 아홉 날 동안 아예 다시 안 온 겁니다. (뒤에 다시 재보니 8월 5일부터는 사실상 발길이 끊긴 상태였어요.)

노출이 0인 건 "결과에서 밀렸다"는 뜻이지만, 안 읽어가는 건 다른 얘기예요. 밀린 게 아니라 발길이 끊긴 겁니다.

이게 그때 제 사이트예요. 글이 몇백 편 있고 도구가 열몇 개 걸려 있고, 겉으로는 아무 문제가 없습니다. 서버도 멀쩡하고 페이지도 다 열려요. 그런데 검색엔진이 발길을 끊었습니다.

원인을 찾는 데 한나절이 걸렸는데요. 결론부터 적을게요.

범인은 저였습니다. 그것도 "좋은 일 했다" 고 뿌듯해하면서 저지른 일이었어요.

그 며칠 사이에 제가 한 일

시간표를 붙여놓고 보면 알리바이가 없습니다.

7월 29일에 뭘 했냐면요. 흩어져 있던 도구 여섯 개를 한 도메인 아래로 합치면서, 도구마다 낱개 페이지를 찍어 붙였습니다.

스위치 찾기가 대표적이에요. 축이 931개 있으니까 축마다 주소를 하나씩 주는 거죠.

이게 도구 첫 화면입니다. 여기까지는 제가 직접 쳐보고 소리를 재서 판정을 붙인 화면이에요. 그런데 여기서 축 하나를 누르면 이런 장이 나옵니다.

이름, 입력압, 가격, 하우징, 스템. 표 하나에 관련 축 목록. 그게 전부예요. 자료는 이미 데이터 파일에 다 있으니까 틀에 부어 찍어내면 되는 일이었습니다. 931장을 만드는 데 몇 분 안 걸렸어요.

그리고 저는 이게 좋은 일인 줄 알았습니다. 주소가 많아지면 검색에 걸릴 자리도 많아지는 거잖아요. 스위치 이름으로 검색하는 사람이 있을 테고, 그 사람한테는 이 장이 딱 맞는 답일 테니까요.

그래서 다음 날 사이트맵을 다시 냈습니다. 314장에서 4,760장. 하루 만에 열다섯 배요.

숫자가 커진 걸 보고 뿌듯했던 기억이 납니다. 이게 딱 사고 직전의 표정이에요.

아니었던 것부터 지웠습니다

여기서 이 편의 진짜 얘기가 시작됩니다. 원인을 어떻게 찾았느냐요.

솔직히 처음에는 제 잘못이라고 생각을 못 했어요. 사람이 원래 그렇잖아요. 내가 방금 한 일이 원인일 거라고는 잘 안 떠올립니다. 그래서 밖에서부터 뒤졌어요.

그런데 이 순서가 결과적으로 맞았습니다. 답을 찾는 게 아니라 답이 아닌 걸 하나씩 지워나갔거든요. 후보를 네 개 세우고 하나씩 확인했습니다.

하나, 주소 이전이 잘못 걸렸나. 며칠 전에 www 를 붙인 주소를 안 붙인 주소로 넘기는 규칙을 걸었거든요. 이게 꼬여서 무한 루프가 됐거나 엉뚱한 데로 보내고 있으면 검색엔진이 포기할 수 있어요. 직접 받아봤습니다. 정상이었습니다.

둘, 봇만 막고 있나. 이게 진짜 있는 사고예요. 보안 설정이 자동 접속을 걸러내면서 검색엔진 로봇까지 같이 막아버리는 경우요. 그러면 사람 브라우저로는 멀쩡히 열리는데 구글만 문 앞에서 돌아갑니다. 화면으로는 절대 안 보이는 고장이에요.

그래서 같은 주소를 두 번 받아봤습니다. 한 번은 사람인 척, 한 번은 구글봇인 척요.

응답 코드도 200으로 같고, 받아온 바이트 수까지 46,389로 똑같았어요. 같은 걸 주고 있었습니다. 차단이 아니었어요.

여기서 "열리네" 로 끝내지 않고 바이트 수까지 맞춰본 게 나중에 도움이 됐습니다. 열리기만 하고 내용이 다른 경우도 있거든요. 어차피 확인하는 김에 한 칸 더 본 거예요.

셋, robots.txt 가 이상한가. 이건 검색엔진한테 "여긴 봐도 돼요, 저긴 보지 마세요" 를 알려주는 파일인데요. 여기에 실수로 / 하나만 잘못 적어도 사이트 전체가 통째로 막힙니다. 열어보니 정상이었어요. 위 화면 맨 위에 그대로 나옵니다. 전부 허용에 사이트맵 주소 한 줄.

넷, 협찬 글을 내린 것 때문인가. 8월 3일에 협찬 글 53편을 사이트에서 내렸거든요. 원본이 네이버에 있어야 하는 글들이라서요. 이게 원인이면 얘기가 간단한데, 날짜가 안 맞습니다. 급락은 7월 29일이고 이건 8월 3일이에요. 나중에 일어난 일이 먼저 일어난 일의 원인일 수는 없죠. (회복을 늦추는 요인은 됐을 겁니다. 다만 무너뜨린 건 아니에요.)

네 개를 지우고 나니까 남은 게 제 손이었습니다.

읽는 쪽에도 예산이 있더라고요

그래서 다시 시간표를 봤어요. 급락이 시작된 날이 정확히 낱개 페이지를 쏟아부은 날이었습니다. 하루 차이도 안 나요.

이걸 이해하는 데 개념 하나가 필요했는데, 저는 그때까지 이걸 몰랐습니다.

검색엔진은 한 사이트를 무한정 읽지 않습니다. 사이트마다 "이 정도까지만 읽겠다" 하는 몫이 있어요. 그 몫은 사이트가 얼마나 오래됐는지, 지금까지 읽어본 게 쓸 만했는지로 정해집니다.

제 도메인은 그때 생후 여드레였어요. 신뢰라고 할 게 있을 리가 없죠. 그 갓난 주소에 얇은 장 4,400개를 하루에 쏟아부은 겁니다.

검색엔진 입장에서 보면 이런 상황이에요. 어제까지 300장짜리 집이었는데 오늘 와보니 4,700장이 됐고, 열어보는 족족 표 한 장에 항목 대여섯 개짜리입니다. 그럼 판단이 서죠. 여기는 더 읽어도 별거 없겠다.

숫자로도 그렇게 나왔습니다. 8월 9일 기준으로 구글이 읽어보고 안 올린 페이지가 1,329장, 올린 건 92장이었어요. 열넷 중 하나만 통과한 셈입니다.

만드는 데 드는 값이 거의 0이니까 저는 양을 늘리는 게 언제나 이득이라고 생각했어요. 그런데 읽는 쪽에는 예산이 있었습니다. 제가 늘린 건 제 자산이 아니라 남의 부담이었어요.

같은 주에 광고 심사도 같은 것을 봤습니다

이 얘기는 앞의 광고 편에서 이미 한 번 나왔는데, 여기서 한 번 더 짚고 갈 자리가 있습니다.

8월 2일에 애드센스 거절 메일이 왔어요. 사유가 "사이트의 86%가 얇은 자동생성 콘텐츠" 였습니다.

검색과 광고는 완전히 다른 심사예요. 보는 사람도 다르고 기준도 다르고 통보 방식도 다릅니다. 그런데 둘이 같은 걸 보고 같은 결론을 냈어요. 한쪽은 노출을 0으로 만들었고, 한쪽은 거절 도장을 찍었습니다. 같은 주에요.

저는 이걸 두 개의 사고로 세고 있었어요. "검색이 안 되네" 와 "광고가 떨어졌네" 로요. 둘을 한 줄에 놓고 보기 전까지는 원인이 하나라는 게 안 보였습니다.

증상이 두 개면 사고도 두 개라고 세는 습관이 있더라고요. 그게 진단을 늦췄습니다.

자를 어디에 놓을 것인가

원인을 알았으니 고쳐야 하는데, 여기서 정해야 할 게 하나 있었어요.

"얇다" 를 몇 자로 볼 것인가.

이게 생각보다 어려운 질문입니다. 800자로 하면 스위치 장 대부분이 살아남고, 3,000자로 하면 멀쩡한 장까지 쓸려 나가요. 그리고 이건 코드가 못 정합니다. 데이터를 아무리 들여다봐도 "그래서 몇 자?" 는 안 나와요.

그래서 새 값을 만드는 대신 이미 쓰고 있던 값을 가져왔습니다.

카드 도구가 낱개 페이지를 만들 때 이미 1,500자짜리 자를 쓰고 있었거든요. 거기서 통했으니까 여기서도 같은 값을 쓴 겁니다.

주석에 굳이 "카드 도구와 같은 자" 라고 적어둔 이유가 있어요. 도구마다 다른 자를 쓰면 나중에 "어느 층이 왜 빠졌는지" 를 설명할 수가 없게 됩니다. 스위치는 1,200자, 카드는 1,500자, 성경은 900자… 이렇게 되면 반년 뒤에 이 파일을 여는 사람은(그게 저겠죠) 각 숫자가 왜 그 값인지 절대 못 알아냅니다.

값이 최적이냐보다 하나로 설명되느냐가 중요했어요.

무엇을 재느냐가 자보다 중요했습니다

그런데 자보다 더 중요한 게 있었습니다. 뭘 재느냐요.

처음에 저는 데이터를 셀 뻔했어요. 스위치 하나에 붙은 항목이 몇 개인지, 값이 몇 바이트인지요. 그런데 그건 틀린 기준입니다.

데이터가 아무리 많아도 화면에 안 나오면 구글도 못 읽어요.

카드 도구가 좋은 예입니다. 카드 한 장에 딸린 약관 원문은 어마어마하게 길어요. 그런데 화면에는 접혀 있죠. 반대로 스위치 장은 데이터 항목이 여섯 개인데 그게 전부 화면에 펼쳐져 있습니다.

그래서 화면에 실제로 실리는 글자수를 재기로 했어요. 스크립트와 스타일을 통째로 걷어내고, 남은 태그를 다 지우고, 그러고도 남는 글자만 셉니다. 위 화면의 visible_len 이 그 여섯 줄이에요.

이걸로 재보니 층이 뚜렷하게 갈렸습니다.

같은 "자료로 찍어낸 낱개 페이지" 인데 890자와 5,125자가 같이 있었어요. 눈으로는 절대 못 가르는 차이입니다. 둘 다 똑같이 "표가 있는 장" 으로 보이거든요.

자가 실수해도 글은 안 잘리게

여기서 제가 제일 무서웠던 건 자가 헛나가는 거였어요.

생각해보세요. 이 스크립트는 배포 때마다 자동으로 돕니다. 어느 날 제가 짧은 글 한 편을 올렸는데 자가 그걸 얇다고 판정해서 검색에서 빼버리면요? 저는 몇 주 뒤에나 알게 될 겁니다.

그래서 자를 대기 전에 걸러내는 조건을 하나 더 뒀어요. 주소가 몇 칸짜리냐로요.

/switch/s/무엇 은 세 칸이고, 도구 첫 화면인 /switch/ 는 한 칸, 글인 /posts/무엇 은 두 칸이에요. 세 칸부터만 본다고 못을 박으면 글과 도구 첫 화면은 자가 아예 닿지를 못합니다.

이게 왜 중요하냐면요. 그 두 층이 실제로 사람을 데려오는 층이거든요. 그때 노출 1등이 카드 도구 첫 화면이었어요.

그리고 이 둘은 자동으로 찍어낸 게 아닙니다. 손으로 쓴 글이고, 직접 설명을 붙인 화면이에요. 성격이 다른 걸 같은 자로 재면 안 되는 거죠.

글자수로 걸러도 결과는 아마 비슷했을 거예요. 그런데 "아마 비슷할 것" 과 "구조적으로 불가능한 것" 은 다릅니다. 자동으로 매일 도는 스크립트라면 뒤쪽이어야 해요.

지우는 게 아니라 안 내미는 겁니다

이제 얇은 장을 어떻게 할 거냐인데요. 여기서 갈림길이 있었습니다.

지울 것이냐, 안 내밀 것이냐.

지우면 간단해요. 파일을 없애면 되니까요. 그런데 그러면 잃는 게 있습니다. 스위치 도구를 쓰던 사람이 축 하나를 눌렀을 때 그 장이 없으면 도구가 반쪽이 되잖아요. 검색으로 안 들어올 뿐이지 링크로 들어가는 사람한테는 필요한 장이거든요.

그래서 그 장에 표시 한 줄을 박기로 했습니다.

<meta name="robots" content="noindex,follow">

"색인에 넣지 마세요, 다만 링크는 계속 타세요" 라는 뜻이에요. follow 를 남긴 게 포인트입니다. 색인에는 안 들어가도 이 장에 걸린 링크는 계속 따라가게 두는 거예요. 그래야 도구 첫 화면으로 가는 길과 장끼리 연결된 관계가 그대로 삽니다.

사람은 링크로 그대로 닿고, 검색엔진한테만 "여긴 안 봐도 됩니다" 라고 말하는 것. 이게 이때 고른 답이었어요.

그리고 표시를 박을 때 규칙 하나를 더 뒀습니다. robots 표시를 두 개 만들지 않는다는 거요. 이미 있으면 갈아끼우고 없으면 새로 넣습니다. 두 개가 있어도 검색엔진은 엄한 쪽을 따르니까 동작은 같은데, 나중에 이 파일을 여는 사람이 어느 쪽이 사는 건지 헷갈립니다. 동작이 같아도 읽는 사람이 헷갈리면 그건 고장이에요.

사이트맵에서도 뺐습니다

표시만 박고 사이트맵에는 그대로 두면 어떻게 될까요.

이게 좀 웃긴 상황이 됩니다. 사이트맵은 "이거 좀 봐주세요" 하고 내미는 목록이거든요. 거기에 넣어놓고 페이지에는 "보지 마세요" 라고 써 붙이는 거예요. 직접 부르고 직접 문 닫는 셈이죠.

그러면 서치콘솔에 "제출됐으나 색인 생성되지 않음" 만 쌓입니다. 고장은 아닌데 계속 빨간 줄이 뜨는 상태예요. 그런 게 쌓이면 진짜 문제가 생겼을 때 눈에 안 들어옵니다.

그래서 표시를 박으면서 사이트맵에서도 같이 뺐어요. 위 코드 화면에 그 이유를 주석으로 적어뒀습니다.

넣는 자리도 정해야 했어요. 이 스크립트는 도구별 사이트맵을 뿌리 한 벌로 합치는 단계 바로 앞에 둡니다. 합치고 나서 빼면 이미 뿌리 목록에 들어간 다음이라 늦거든요. 각자 사이트맵이 아직 살아 있을 때 거기서 빼야 합쳐진 목록에 애초에 안 들어갑니다.

덤도 하나 있었어요. 광고 코드를 붙이는 스크립트가 원래부터 noindex 가 박힌 장은 건너뛰게 돼 있었습니다. 그래서 표시를 박는 것만으로 광고도 자동으로 안 붙었어요. 그날 3,285개가 빠졌습니다. 손댈 게 없었습니다.

기술사 325장은 남겼습니다

여기가 이 편에서 사람이 붙잡은 자리예요.

내릴 목록을 짤 때 저는 기술사 주제 325장을 당연히 같이 내릴 거라고 생각했습니다. 이유가 명확했어요. 자료를 틀에 부어 찍어낸 장이거든요. 스위치 931장, 카드 1,180장, 기술사 325장. 만든 방식이 똑같습니다.

그런데 자를 정해놨으니 재보긴 해야죠. 재봤습니다.

5,125자였어요. 기준의 세 배가 넘습니다.

이게 그중 한 장이에요. 개념과 유래가 있고, 대금 흐름 구조도가 있고, 그 아래로 핵심 기준과 원리가 이어집니다. 틀은 자동인데 안에 든 게 두꺼웠어요.

여기서 두 가지를 할 수 있었습니다.

하나는 "그래도 자동 생성물이니까" 하고 내리는 거예요. 제 첫 직관이 그거였고요.

다른 하나는 자를 정했으면 자를 따르는 것입니다. 저는 이쪽을 골랐어요.

이유가 있습니다. 자를 정하고 나서 결과가 마음에 안 든다고 손으로 되돌리기 시작하면, 그 자는 더 이상 자가 아니에요. 제 기분을 숫자로 포장한 것뿐이죠. 그러면 다음에 또 이런 일이 생겼을 때 기준이 없습니다.

그리고 자가 옳았습니다. 스위치 장 890자와 기술사 장 5,125자는 만든 방식만 같지 읽는 사람 입장에서는 완전히 다른 물건이에요. 하나는 표 하나 보고 나가는 장이고, 하나는 앉아서 읽는 장입니다. 자가 그걸 갈라줬어요.

제 직관은 "어떻게 만들었나" 를 보고 있었고, 자는 "뭐가 들어 있나" 를 보고 있었습니다. 이 경우엔 자가 맞았어요.

기술사 도구 첫 화면입니다. 실제 기출 620문항을 회차별로 매핑한 히트맵이에요. 이 아래에 달린 325장을 그날 감으로 내렸으면, 지금 검색으로 들어오는 사람의 상당수를 그때 잘라냈을 겁니다.

자를 재는 시험을 붙였습니다

이 스크립트는 배포 때마다 자동으로 돕니다. 그래서 자가 제대로 재는지를 확인하는 시험을 같은 파일에 넣었어요.

가짜 페이지 네 장을 만들어놓고 돌려보는 겁니다. 얇은 낱개 하나, 두꺼운 낱개 하나, 도구 첫 화면 하나, 글 하나요. 얇은 낱개 한 장만 내려가고 나머지 셋은 그대로 있어야 통과입니다.

밑에 두 줄이 특히 중요해요. 표시가 제대로 박혔는지, 그리고 표시가 두 개가 되지 않았는지를 봅니다. 아까 말한 "동작은 같은데 읽는 사람이 헷갈리는" 상태를 시험으로 막아둔 거예요.

이런 시험을 붙이는 이유는 자동으로 도는 것일수록 조용히 틀리기 때문입니다. 손으로 돌리면 결과를 눈으로 보는데, 크론이 돌리면 아무도 안 봐요. 아무도 안 보는 자리에 자를 놓을 거면 그 자를 재는 자를 같이 놔야 합니다.

결과

8월 9일 배포에서 자가 처음 돌았습니다.

1,341장을 내렸어요. 스위치 931, 집값 310, 성경 91, 시장 지표 5, 육아휴직 4. 그날 기준 사이트맵이 3,552장이었는데 2,211장이 됐습니다.

남긴 층은 이랬어요. 카드 낱개 1,116장(2,377자), 기술사 325장(5,125자), 글 262편, 폰 기종 22장(3,412자), 성경 사건 10장(5,665자).

카드 낱개는 이렇게 생겼습니다. 표에 약관 원문까지 붙어 있어서 2,377자가 나와요. 스위치 장과 만든 방식은 같은데 안에 든 게 다릅니다.

그리고 사이트맵을 다시 냈습니다.

2,222장으로 줄여서 냈습니다. 4,787장에서 절반 아래로 내린 거예요.

그런데 여기서 솔직하게 적어야 할 게 있습니다. 줄였다고 바로 돌아오지 않았어요. 8월 16일에 서치콘솔과 서버 접속 기록을 나란히 놓고 다시 재봤는데, 최근 7일 구글봇 방문이 219건인데 그중 105건이 robots.txt, 59건이 홈이었습니다. 실제 글을 읽어간 건 20건이에요. 색인은 7월 28일 448장에서 90장으로 내려앉아 있었고요.

목록을 줄인 게 잘못이라는 뜻이 아닙니다. 한 번 회수된 예산은 목록을 고쳤다고 그날로 돌아오지 않는다는 뜻이에요. 제가 그 뒤로도 사이트맵을 4,787 → 1,677 → 2,795 → 3,552 → 2,214 로 흔들었는데, 그게 회복을 더 늦췄습니다. 한 방향으로 천천히 움직였어야 했어요.

그리고 이걸로 다 끝난 건 아니었습니다

여기서 끝났으면 깔끔한 얘기인데, 그게 아니었어요. 앞의 광고 편에서 이미 나온 대목이라 짧게만 짚고 갈게요.

이 처방은 검색에는 통했고 광고 심사에는 안 통했습니다.

이유가 간단해요. noindex 는 검색엔진한테 하는 말이지 심사원한테 하는 말이 아니거든요. 파일이 서버에 그대로 있고 주소를 치면 열리는 한, 사이트를 직접 돌아다니는 쪽에는 그 장이 그대로 보입니다. 문에 "이 방은 안 봐도 됩니다" 라고 써 붙인다고 손님이 못 여는 게 아니잖아요.

그래서 8월 11일에 또 떨어졌고, 그때는 파일을 아예 안 올리는 쪽으로 갔습니다. 그 얘기는 이미 했으니 여기서는 접을게요.

다만 이 편의 자리에서 남길 건 이겁니다. 처방이 절반만 맞았다는 걸 알려준 게 코드가 아니라 두 번째 거절 메일이었어요. 스크립트는 시키는 대로 정확히 돌았습니다. 1,341장을 정확히 재서 정확히 내렸어요. 틀린 건 "이걸 하면 해결되는가" 라는 질문 쪽이었고, 그건 코드가 답할 수 있는 게 아니었습니다.

이 편에서 사람이 붙잡은 자리

정리하면 네 군데예요.

하나, 원인을 지워나간 순서. 주소 이전 → 봇 차단 → robots.txt → 협찬 글 내림. 넷을 지우고 남은 게 제 손이었습니다. 여기서 한 일 중에 코드가 대신할 수 있는 건 확인 작업뿐이에요. "무엇을 의심할 것인가" 를 세우는 건 사람 몫이었습니다. 그리고 이 순서에서 제일 중요한 건 마지막 후보를 자기 자신으로 놓는 거였어요. 그게 잘 안 됩니다.

둘, 자의 값. 1,500자를 새로 정한 게 아니라 이미 쓰던 값을 가져왔어요. 이건 최적화가 아니라 설명 가능성을 고른 겁니다. 그게 왜 나은지는 데이터에 안 나옵니다.

셋, 자가 닿지 못할 곳을 미리 못 박은 것. 깊이 세 칸이요. "아마 안 잘릴 것" 을 "구조적으로 못 자름" 으로 바꾼 건데요, 이건 자동화를 만들 때가 아니라 자동화를 무서워할 때 나오는 발상이에요.

넷, 기술사 325장. 자를 정해놓고 그 결과가 직관과 어긋났을 때 자를 따랐습니다. 그리고 자가 맞았어요. 이건 반대로 사람이 자기 직관을 안 따른 게 사람의 개입이었던 경우입니다.

그러니까 사람이 남는 자리가 늘 "기계가 틀렸을 때 바로잡는 자리" 인 건 아니더라고요. 자를 놓고, 그 자가 닿을 범위를 정하고, 결과가 마음에 안 들 때도 자를 따르기로 하는 것. 그게 다 사람이 하는 일이었습니다.

그리고 배운 것 하나

이 사고의 진짜 원인은 사실 스크립트가 아니라 계산이었어요.

만드는 데 드는 값이 0에 가까워지면 양을 늘리는 게 언제나 이득처럼 보입니다. 931장 만드는 데 몇 분이면 되는데 안 만들 이유가 없잖아요. 저는 그 계산까지만 했습니다.

그런데 읽는 쪽에는 예산이 있었어요. 그 예산은 제 것이 아니고, 제가 늘릴 수도 없고, 제가 뭘 얼마나 냈는지에 따라 줄어듭니다.

제가 늘린 건 제 자산이 아니라 남의 부담이었어요.

이건 검색만의 얘기가 아니더라고요. 뭘 만들든 값이 싸지면 같은 함정이 생깁니다. 만드는 쪽 비용만 보고 받는 쪽 비용을 안 세는 것요. 그리고 받는 쪽은 대개 말을 안 해줍니다. 그냥 발길을 끊어요.

다음 편

다음 편은 네이버냐 홈페이지냐 하는 얘기입니다.

여기까지 오고 나니 질문이 하나 남았어요. 같은 글을 두 군데 두면 어떻게 되나요. 중복이라 벌점을 먹는 걸까요?

그게 아니었습니다. 진짜 문제는 다른 데 있었어요. 같은 글이 둘이면 검색엔진이 어느 쪽을 원본으로 볼지 고릅니다. 그리고 고르는 쪽이 제가 아니에요.

#사이트맵 #sitemap #검색노출 #구글서치콘솔 #서치콘솔 #크롤예산 #크롤링됨미색인 #색인생성 #noindex #robotstxt #얇은콘텐츠 #자동생성페이지 #SEO #검색엔진최적화 #구글SEO #네이버서치어드바이저 #301리디렉트 #애드센스거절 #CloudflarePages #클라우드플레어 #정적사이트 #배포자동화 #파이썬스크립트 #개인홈페이지 #홈페이지만들기 #키보드스위치찾기 #카드혜택 #기술사스터디 #AI코딩 #휴먼인더루프