AI 에이전트 내부 링크 점검 6단계와 단계별 완료 기준
AI 에이전트로 내부 링크를 점검할 때는 6단계로 진행합니다. 순서는 URL 목록 확보, 링크 수집, 문제 분류, 수정안 작성, 승인 후 반영, 재확인입니다.
에이전트에게는 페이지 읽기, 분류, 수정안 작성을 맡깁니다. 사이트를 실제로 바꾸는 일은 사람이 승인한 뒤에 합니다. 단계마다 완료 조건을 정하면 다음 단계로 넘어갈지 바로 판단할 수 있습니다.
내부 링크 점검에서 무엇을 기준으로 판정하나요?
점검 기준은 Google Search Central 문서에서 가져옵니다. 에이전트가 기준을 임의로 해석하지 않도록 항목마다 판정 방법을 함께 정합니다.
| 점검 항목 | Google 문서의 설명 | 에이전트 판정 방법 |
|---|---|---|
| 링크 형식 | 링크 모범 사례 문서는 주소 속성이 있는 링크 태그여야 Google이 링크를 크롤링할 수 있다고 설명합니다. 주소 속성이 없는 링크 태그나 스크립트 주소로 이동하는 링크는 권하지 않는 예로 듭니다. | 주소 속성이 없는 링크 태그와 스크립트로만 이동하는 링크를 표시합니다. |
| 앵커 텍스트(링크에 걸린 문구) | 같은 문서는 설명이 담기고 적당히 간결하며 맥락과 관련 있는 문구를 권합니다. '여기를 클릭' 같은 일반 문구와 키워드 나열은 피하라고 합니다. 이미지 링크는 대체 텍스트(alt)를 앵커 텍스트로 사용한다고 설명합니다. | 일반 문구, 빈 앵커, 대체 텍스트가 비어 있는 이미지 링크, 같은 검색어를 반복하는 앵커를 표시합니다. |
| 연결 여부 | 같은 문서는 중요한 페이지마다 사이트 안의 다른 페이지 한 곳 이상에서 링크를 받아야 한다고 설명합니다. | 들어오는 내부 링크가 0개인 페이지를 고아 페이지로 표시합니다. |
| 정규 URL(canonical, 검색엔진이 대표로 삼는 주소) | 정규 URL 문서는 사이트 안에서 링크할 때 중복 URL이 아니라 정규 URL로 연결하라고 안내합니다. | 링크 주소와 도착 페이지의 정규 URL 값이 다르면 표시합니다. |
| 리디렉션(옛 주소에서 새 주소로 자동으로 넘기는 처리) | 사이트 이전 문서는 URL을 옮기면 내부 링크를 새 URL로 바꾸라고 안내합니다. 같은 문서는 리디렉션을 최종 목적지로 바로 보내라고 권합니다. | 3xx(다른 주소로 넘기는 응답)를 한 번 이상 거치는 링크를 표시합니다. 실무에서는 두 번 이상 거치는 링크를 먼저 처리합니다. |
참고한 Google 문서에는 한 페이지에 둘 링크의 적정 개수가 나오지 않습니다. 그래서 링크 개수만으로 문제를 판정하지 않습니다. 위 다섯 항목에 해당하는 링크만 문제로 분류합니다.
1단계: 점검할 URL 목록은 어떻게 마련하나요?
기준 목록은 세 가지 자료를 합쳐 만듭니다. 사이트맵, 콘텐츠 관리 시스템(CMS)의 발행 글 목록, Search Console 링크 보고서입니다.
정규 URL 문서는 페이지마다 정규 URL을 하나 정해 사이트맵으로 제출하라고 안내합니다. 따라서 사이트맵을 정규 URL 목록의 기준으로 삼습니다. CMS 목록은 사이트맵에서 빠진 글이 있는지 확인하는 데 씁니다.
Search Console 링크 보고서의 내부 링크 표에서는 사이트 안에서 가장 많이 링크된 페이지를 볼 수 있습니다. URL을 고르면 그 페이지로 링크하는 다른 페이지도 나옵니다. 다만 도움말이 밝힌 한계가 있어 보조 자료로만 씁니다.
- 표는 1,000행까지만 보여 주므로 큰 사이트에서는 잘릴 수 있습니다.
- Google이 시간이 지나며 찾은 링크를 담고 있어, 이미 지운 링크나 없어진 페이지가 남아 있을 수 있습니다.
- 링크에 nofollow(검색엔진이 따라가지 않도록 표시한 링크) 표시가 있는지 알려 주지 않습니다.
- 사이트의 모든 링크가 아니라 표본을 보여 주며, 색인되지 않은 페이지 등은 빠질 수 있습니다.
완료 조건: URL마다 출처 열(사이트맵·CMS·Search Console)이 붙은 기준 목록 한 장이 있어야 합니다. 세 자료 중 한 곳에만 나오는 URL은 따로 표시합니다.
2~3단계: 에이전트에게 링크 수집과 분류를 어떻게 지시하나요?
수집은 에이전트가 기준 목록의 페이지를 직접 열어 본문 링크를 뽑는 방식으로 합니다. 링크 상태는 에이전트가 직접 수집한 결과로만 판정합니다.
아래 문안을 지시에 넣고 사이트 사정에 맞게 고쳐 씁니다.
지시 문안 예시: 「첨부한 기준 목록의 각 페이지를 열어 같은 도메인으로 가는 링크를 모두 추출합니다. 링크마다 출발 페이지, 링크 주소, 앵커 텍스트, 응답 코드, 최종 도착 URL, 도착 페이지의 정규 URL 값을 기록합니다. 아래 분류표의 유형 중 하나를 붙입니다. 값을 확인하지 못하면 추정하지 않고 '보류'로 두고 이유를 적습니다. 로그인이 필요한 관리 화면은 열지 않습니다. 사이트의 어떤 내용도 수정하지 않습니다.」
실무에서는 운영 서버에 부담이 가지 않도록 요청 사이에 간격을 두는 방식을 권합니다. 메뉴와 푸터처럼 모든 페이지에 반복되는 링크는 따로 묶어 한 번만 판정합니다.
| 유형 | 판정 조건 | 기본 조치 | 결정 주체 |
|---|---|---|---|
| 끊긴 링크 | 도착 응답이 4xx·5xx(페이지 없음·서버 오류) | 대체 페이지로 교체하거나 링크 삭제 | 사람 |
| 리디렉션 경유 | 3xx를 거쳐 200(정상 응답)에 도착 | 최종 도착 URL로 교체 | 사람이 일괄 승인 |
| 정규 URL 불일치 | 링크 주소와 도착 페이지의 정규 URL이 다름 | 정규 URL로 교체 | 사람이 일괄 승인 |
| 크롤링 불가 형식 | 주소 속성 없음, 스크립트로만 이동 | 주소 속성을 갖춘 링크 태그로 바꾸도록 개발 담당에 전달 | 개발 담당 |
| 모호한 앵커 | 일반 문구, 빈 앵커, 빈 대체 텍스트 | 도착 페이지 내용을 담은 문구로 교체 | 사람 |
| 고아 페이지 | 들어오는 내부 링크 0개 | 관련 글 본문에 링크 추가 또는 페이지 유지 여부 결정 | 사람 |
에이전트는 응답 코드나 정규 URL 값을 잘못 적거나 지어낼 수 있습니다. 그래서 결과를 받으면 담당자가 표본을 직접 대조합니다. 유형마다 몇 행씩 골라 브라우저나 응답 확인 도구로 응답 코드와 정규 URL 값을 엽니다. 한 행이라도 다르면 그 유형 전체를 다시 수집하게 합니다.
완료 조건: 모든 링크 행에 응답 코드와 유형이 하나씩 붙어 있어야 합니다. 보류 행에는 이유가 적혀 있어야 합니다. 유형별 표본 대조에서 불일치가 0건이어야 합니다.
4~5단계: 수정안은 어떻게 만들고 누가 승인하나요?
에이전트는 분류 결과로 수정안 표를 만듭니다. 열은 출발 페이지, 현재 링크, 바꿀 링크, 현재 앵커, 바꿀 앵커, 근거로 구성합니다. 근거 열에는 해당 유형과 응답 코드를 적습니다.
실무에서는 독자에게 미치는 영향이 큰 것부터 처리 순서를 정하는 방법을 권합니다.
- 끊긴 링크: 독자가 오류 화면을 보게 되므로 먼저 처리합니다.
- 중요한 고아 페이지: 서비스 소개나 문의처럼 핵심 페이지가 연결되어 있지 않으면 바로 처리합니다.
- 리디렉션 경유와 정규 URL 불일치: 주소만 바꾸는 작업이라 묶어서 처리합니다.
- 모호한 앵커: 문구를 바꾸는 작업이라 본문 담당자와 함께 검토합니다.
Google의 사이트 이전 문서는 옛 URL 여러 개를 새 사이트 홈페이지처럼 관련 없는 한 페이지로 리디렉션하지 말라고 안내합니다. 사용자를 혼란스럽게 하고 소프트 404로 처리될 수 있다는 이유입니다. 실무에서는 이 원칙을 내부 링크에도 적용하는 방법을 권합니다. 끊긴 링크를 홈으로 일괄 교체하지 않고, 내용이 이어지는 페이지가 없으면 링크를 삭제합니다.
앵커 수정안에는 도착 페이지의 제목이나 핵심 내용을 담습니다. 예를 들어 가상의 B2B 기업 블로그라면 「자세히 보기」를 「도입 전 확인할 계약 조건」처럼 바꿉니다. 같은 검색어를 여러 링크에 반복해 넣지 않습니다.
승인자는 수정안 표에서 행마다 승인·반려를 표시합니다. 반영은 승인된 행만 합니다. CMS 수정 권한이 있는 사람이 반영하거나, 승인된 행을 반영하는 동안에만 에이전트에게 쓰기 권한을 줍니다. 반영이 끝나면 권한을 회수합니다.
완료 조건: 모든 수정안 행에 근거가 있어야 합니다. 승인자와 승인일이 기록되어야 하고, 반영한 행과 승인된 행이 일치해야 합니다.
6단계: 반영한 뒤에는 무엇을 다시 확인하나요?
먼저 에이전트가 수정한 페이지를 모두 다시 수집합니다. 바꾼 링크가 리디렉션 없이 200으로 도착하는지, 앵커가 수정안대로 바뀌었는지 대조합니다.
다음으로 핵심 페이지 몇 개를 골라 Search Console의 URL 검사 도구로 봅니다. 도움말에 따르면 이 도구는 Google이 그 URL을 발견하는 데 사용했을 수 있는 참조 페이지를 보여 줍니다. Google이 선택한 정규 URL과 사용자가 선언한 정규 URL도 따로 보여 줍니다.
도움말은 실시간 테스트가 사이트맵 포함 여부와 참조 페이지를 확인하지 않는다고 설명합니다. 그러므로 링크를 추가한 결과는 실시간 테스트가 아니라 이후 크롤링 결과로 봅니다. 색인 생성 요청에는 하루 한도가 있고, 요청해도 색인에 포함된다는 보장은 없다고 도움말은 밝힙니다. 바뀐 페이지가 많으면 사이트맵을 쓰는 방법을 권합니다.
완료 조건: 재수집 결과 수정한 링크에 오류와 리디렉션이 없어야 합니다. URL 검사 결과는 확인 날짜와 함께 기록합니다.
정기 점검은 언제 하고 무엇을 기록하나요?
정기 점검과 별도로, 사이트에 변경이 생기면 그때마다 점검합니다. URL 변경, 메뉴 개편, 글 삭제, 새 글 묶음 발행이 그런 변경입니다. 특히 URL을 바꾼 직후에는 사이트 이전 문서의 안내대로 내부 링크가 새 URL을 가리키는지 확인합니다.
회차마다 같은 양식으로 기록해야 지난 회차와 비교할 수 있습니다.
| 기록 항목 | 기록 예시(가상) |
|---|---|
| 점검일과 계기 | 정기 점검 또는 메뉴 개편 직후 |
| 대상 범위 | 기준 목록 전체 또는 블로그 디렉터리만 |
| 유형별 건수 | 끊긴 링크, 리디렉션 경유, 고아 페이지 등 유형마다 건수 |
| 표본 대조 | 유형별 대조 행 수와 불일치 건수, 재수집 여부 |
| 승인과 반영 | 승인자, 승인 행 수, 반영일, 권한 회수일 |
| 재확인 결과 | 재수집 오류 건수, URL 검사 확인 페이지 |
| 다음 회차 주의점 | 보류 행과 개발 담당에 넘긴 건 |
정리
- 사이트맵, CMS 목록, Search Console 링크 보고서를 합쳐 출처 열이 붙은 기준 목록을 만듭니다.
- 지시 문안 예시를 고쳐 에이전트에게 링크 수집과 여섯 유형 분류를 맡깁니다. 수집·분류 단계에서는 수정 권한을 주지 않습니다.
- 유형별 표본을 직접 대조한 뒤, 수정안 표를 끊긴 링크부터 검토해 행마다 승인합니다. 쓰기 권한은 승인된 행을 반영할 때만 한시적으로 줍니다.
- 수정한 페이지를 다시 수집하고 핵심 페이지는 URL 검사 도구로 확인한 뒤, 결과를 기록 양식에 남깁니다.
참고 자료
- Link best practices for Google (Google Search Central, 확인일 2026-10-20)
- How to specify a canonical URL and other methods (Google Search Central, 확인일 2026-10-20)
- Site moves with URL changes (Google Search Central, 확인일 2026-10-20)
- Links report (Search Console 고객센터, 확인일 2026-10-20)
- URL Inspection tool (Search Console 고객센터, 확인일 2026-10-20)