어느 날 내 블로그의 링크 29개가 죽어 있었습니다
이 블로그를 정리하다가 문득 불안한 생각이 들었습니다. 몇 달 전에 중복되는 글 몇 편을 비공개로 돌렸는데, 그 글들을 가리키던 링크는 어떻게 됐을까?
결과부터 말씀드리면, 발행 중인 글 32편 중 7편에서 죽은 링크 29개가 나왔습니다. 사이트의 22%가 존재하지 않는 페이지로 연결되고 있었던 겁니다. 몇 달 동안 저는 전혀 몰랐습니다.
저는 개발자가 아닙니다. 10년 넘게 커머스 쪽에서 상품과 매출을 다뤄온 사람이고, 코드는 못 짭니다. 그래도 이 점검과 수정을 클로드 코드에게 시켜서 30분 만에 끝냈습니다. 이 글은 그 과정을 그대로 옮긴 기록입니다. 같은 상황에 놓인 분이 그대로 따라 할 수 있도록, 제가 실제로 보낸 요청 문장까지 함께 적었습니다.
원인: “비공개로 돌리기”가 남긴 것
발단은 몇 달 전의 정리 작업이었습니다. 비슷한 주제의 글이 겹쳐서, 중복되는 8편을 삭제하지 않고 비공개(초안)로만 전환했습니다. 되돌릴 수 있게 하려는 의도였고, 그 판단 자체는 나쁘지 않았습니다.
문제는 그다음이었습니다. 워드프레스에서 글을 비공개로 바꾸면 그 글은 안 보이게 되지만, 다른 글에 박혀 있는 링크는 그대로 남습니다. 글 하단의 “함께 읽으면 좋은 글” 목록이 특히 그랬습니다.
비공개로 돌린 글 = 사라진 목적지
그 글을 가리키던 링크 = 그대로 남은 표지판
표지판은 멀쩡히 서 있는데 그 끝에 아무것도 없는 상태. 방문자에게도, 검색엔진 크롤러에게도 마찬가지입니다.
1단계 — 정말 죽은 게 맞는지부터 확인했습니다
바로 고치지 않았습니다. “죽었을 것 같다”와 “죽었다”는 다르기 때문입니다. 혹시 워드프레스가 알아서 다른 곳으로 넘겨줄 수도 있으니까요.
그래서 이렇게 요청했습니다.
비공개로 돌린 글이 방문자에게 어떻게 보이는지 확인해줘.
지금 발행 중인 글 하나와 비교해서 같이 보여줘.
여기서 중요한 건 “발행 중인 글 하나와 비교해서” 입니다. 비교 대상이 없으면 “안 열린다”는 결과가 나와도 그게 글 때문인지 접속 문제인지 알 수 없습니다. 실제로 돌아온 결과입니다.
발행 중인 글만 정상으로 열리고, 비공개 글들은 전부 응답 자체가 끊겼습니다. 확인 끝. 이제 고쳐도 되는 상태가 됐습니다.
2단계 — 사이트 전체를 한 번에 훑기
한 편을 발견했다고 한 편만 고치면 안 됩니다. 같은 정리 작업을 했다면 다른 글에도 똑같이 남아 있을 가능성이 높기 때문입니다.
그래서 범위를 사이트 전체로 넓혀 요청했습니다.
이 블로그 발행글 전체에서 죽은 내부링크를 찾아줘.
찾기만 하지 말고 어떤 글이 어떤 대상을 가리키는지 표로 보여줘.
결과는 이랬습니다.
| 글 | 총 내부링크 | 죽은 링크 |
|---|---|---|
| A | 5 | 5 |
| B ~ G (6편) | 각 5 | 각 4 |
| 합계 | 29개 | |
한 편은 링크 5개가 전부 죽어 있었습니다. 한 편만 고치고 끝냈다면 나머지 24개는 그대로 남았을 겁니다.
3단계 — 고치기 전에 반드시 한 두 가지
라이브로 돌아가는 사이트를 한 번에 7편이나 수정하는 작업입니다. 잘못되면 되돌리기 어렵습니다. 그래서 두 가지를 먼저 시켰습니다.
① 백업
수정하기 전에 대상 글 전부를 파일로 백업해줘.
백업이 끝난 다음에 진행해줘.
“백업해줘”만 쓰면 백업과 수정이 한꺼번에 진행될 수 있습니다. “백업이 끝난 다음에”라는 순서를 명시하는 게 핵심입니다.
② 예행연습
바로 고치지 말고, 몇 건이 어떻게 바뀌는지 먼저 보여줘.
고치고 나면 남는 문제가 몇 개인지도 같이.
이 요청 덕분에 “29건이 바뀌고, 바꾸고 나면 남는 죽은 링크는 0개”라는 걸 실제 수정 전에 확인할 수 있었습니다. 숫자가 예상과 맞는 걸 보고 나서야 진행 신호를 줬습니다.
되돌리기 어려운 작업일수록 이 두 줄이 보험이 됩니다.
4단계 — 어디로 연결할지는 사람이 정합니다
죽은 링크를 찾는 것까지는 기계가 합니다. 하지만 “그래서 어디로 연결할 것인가”는 사람이 정해야 합니다.
제 경우엔 비공개로 돌린 글마다 주제가 겹치는 대체 글이 이미 있었습니다. 그래서 “이 글 대신 저 글”이라는 대응표를 직접 만들어 넘겼습니다.
다만 한 건은 대응 글이 이미 다른 링크에 쓰여서 중복이 되는 상황이었습니다. 이건 기계가 판단할 수 없는 영역이라, 주제가 가장 가까운 다른 글로 제가 직접 배정했습니다. 이런 판단이 필요한 지점에서는 AI에게 맡기지 말고 직접 정하는 편이 낫습니다.
결과: 29개 → 0개
수정 후 확인한 내용입니다.
- 발행글 32편 재검사 → 죽은 내부링크 0개
- 수정한 글의 공개 페이지 정상 응답 확인
- 옛 링크가 본문에 하나도 남지 않은 것 확인
- 한글 링크 텍스트 깨짐 없음
여기서도 요청에 완료 기준을 넣어뒀습니다. “고친 뒤엔 반드시 다시 조회해서 0개인지 확인해줘”라고 미리 말해두면, 수정이 끝난 다음 스스로 다시 확인한 결과를 근거로 가져옵니다. 이 부분은 프롬프트 쓰는 법을 정리한 글에서 더 자세히 다뤘습니다.
이 일에서 배운 것 3가지
1. 글을 비공개로 돌릴 땐 그 글을 가리키는 링크도 같이 정리해야 합니다
이게 이번 사건의 한 줄 요약입니다. 삭제든 비공개든, 목적지를 없앨 때는 표지판도 같이 봐야 합니다. 워드프레스는 이걸 알아서 해주지 않습니다.
2. “관리되지 않는 사이트”로 보이는 건 생각보다 치명적입니다
본문을 아무리 다듬어도, 사이트의 22%가 깨진 링크를 달고 있으면 그 인상이 먼저 갑니다. 저는 그동안 글 품질만 손보고 있었는데, 정작 더 눈에 띄는 문제를 몇 달간 방치하고 있었던 셈입니다.
3. 점검은 감이 아니라 전수로 해야 합니다
처음 발견한 건 글 한 편이었습니다. 거기서 멈췄다면 29개 중 4개만 고쳤을 겁니다. “하나 찾았으면 전체를 훑는다”가 이런 작업의 기본입니다. 그리고 전수 조사야말로 사람이 손으로 하기 가장 싫은 일이고, AI에게 시키기 가장 좋은 일입니다.
그대로 쓰실 수 있는 요청 문장 5개
제가 실제로 보낸 순서 그대로입니다. 블로그 주소만 본인 것으로 바꿔서 위에서부터 하나씩 보내시면 됩니다.
① 확인
비공개로 돌린 글이 방문자에게 어떻게 보이는지 확인해줘.
지금 발행 중인 글 하나와 비교해서 같이 보여줘.
② 전수 점검
내 블로그 발행글 전체에서 죽은 내부링크를 찾아줘.
찾기만 하지 말고 어떤 글이 어떤 대상을 가리키는지 표로 보여줘.
③ 백업
수정하기 전에 대상 글 전부를 파일로 백업해줘.
백업이 끝난 다음에 진행해줘.
④ 예행연습
바로 고치지 말고, 몇 건이 어떻게 바뀌는지 먼저 보여줘.
고치고 나면 남는 문제가 몇 개인지도 같이.
⑤ 수정 + 검증
이제 반영해줘. 고친 뒤엔 반드시 다시 조회해서
죽은 링크가 0개인지 확인하고 결과를 보여줘.
다섯 문장의 공통점이 하나 있습니다. 전부 “어디까지”와 “어떻게 되면 끝인지”를 담고 있다는 것입니다. “링크 좀 고쳐줘”라고만 했다면 이 중 어느 것도 나오지 않았을 겁니다.
자주 묻는 질문 (FAQ)
Q. 개발자가 아니어도 할 수 있나요?
A. 네. 저도 코드를 못 짭니다. 이 글에 적은 요청 문장들이 제가 실제로 보낸 전부입니다. 중요한 건 코드 실력이 아니라 범위(어디까지)와 완료 기준(어떻게 되면 끝인지)을 문장으로 정확히 말하는 것입니다.
Q. 링크가 깨진 걸 미리 알 수는 없나요?
A. 구글 서치콘솔에서도 일부 확인되지만 반영이 늦습니다. 저처럼 글을 비공개·삭제한 직후에 한 번 전수 점검을 돌리는 것이 가장 확실합니다. 정리 작업과 링크 점검을 한 세트로 묶어두면 좋습니다.
Q. 수정하다가 잘못되면 어떻게 하나요?
A. 그래서 백업을 먼저 시킵니다. 저는 수정 대상 7편 전부를 파일로 저장한 뒤에 진행했고, 언제든 되돌릴 수 있는 상태였습니다. 되돌릴 수 있다는 걸 알면 훨씬 과감하게 시킬 수 있습니다.
한 줄 요약: 글을 비공개로 돌리면 그 글을 가리키던 링크는 그대로 남아 죽은 링크가 됩니다. 감으로 한두 개 고치지 말고, 범위를 사이트 전체로 잡고 백업 → 예행연습 → 수정 → 재확인 순서로 한 번에 끝내는 게 낫습니다.