수정 이력(8건, 최종 수정 2026년 08월 26일)
이 글에 적용한 변경 사항의 기록입니다. 보관해 둔 수정 전 버전은 DOI가 부여된 고정 URL에서 읽을 수 있습니다.
- 8.2절 본문에 남아 있던 「기둥」을, 절 제목과 같은 용어 「필러 페이지」로 맞췄습니다. 글의 주장은 바꾸지 않았습니다. 수정 전 버전 보기 (DOI: 10.5281/zenodo.22093778)
- 어색한 구어·비유를 의미를 바꾸지 않고 기술 문서로 자연스러운 일본어로 고쳤고, Mermaid 그림의 노드 라벨과 캡션에서 쓰던 「기둥」을 본문 용어 「필러 페이지」로 맞췄습니다. 글의 주장은 바꾸지 않았습니다. 수정 전 버전 보기 (DOI: 10.5281/zenodo.22064729)
- 내부 링크의 왕복 구조, 앵커 텍스트 판정, 적용 절차를 그림으로도 따라갈 수 있도록 Mermaid 그림 8개를 추가했습니다(본문 500~750자당 그림 1개 규약에 맞춘 것입니다). 기존 전체 구조 그림에도 캡션을 달고, 그림 번호를 일련번호로 다시 매겼습니다. 본문 문장은 바꾸지 않았습니다.
- 글 맨 앞에 「이 글의 지식 맵」절을 추가했습니다. 본문에서 다루는 개념과 그 관계를 요약·그림·상세 페이지 링크로 정리한 것입니다. 본문의 주장은 바꾸지 않았습니다.
- 외부 리뷰(1283건) 대응으로 본문을 갱신했습니다. 개별 변경 내용은 아래 이력을 참고하십시오.
- 필러 페이지·글 허브·서비스 페이지의 역할 차이를 용어표로 정의하고, 왕복 구조 그림을 추가했습니다. 구현에서 주의할 점(a 태그와 href, JavaScript, rel 속성), 사이트 구조와 breadcrumb, Search Console에서 효과를 보는 방법, 자기 사이트에 적용하는 절차를 새로 만들고, 앵커 텍스트 예를 4개 업종으로 늘렸습니다.
- 본문 중 관련 글 링크 문구를, 링크 대상의 현재 제목에 맞췄습니다.
- 출처가 본문 어디에서도 참조되지 않아 「참고 자료」에 표시되지 않던 문제를 수정했습니다. 더불어, 고립된 페이지와 sitemap의 관계에 대한 설명을 한 문장 더했습니다.
- 최초 공개
이 글을 인용하기(DOI: 10.5281/zenodo.21635224)
이 글은 Zenodo에 보관되어 있습니다. 항상 최신 버전으로 연결되는 DOI와 지금 보고 있는 버전에 고정된 DOI를 아래에 함께 제시합니다.
Go Komura (2026). 「글과 서비스 페이지를 어떻게 잇는가 - 내부 링크 설계의 기본」. 합동회사 코무라소프트. https://doi.org/10.5281/zenodo.21635224 https://comcomponent.com/ko/blog/internal-linking-between-articles-and-service-pages/
- DOI(최신 버전)
- 10.5281/zenodo.21635224
- DOI(이 버전)
- 10.5281/zenodo.21635225
글을 늘렸는데도 문의로 이어지지 않는다. 그 원인은 글의 내용보다, 글에서 서비스 페이지로 돌아가는 길이 약한 데 있는 경우가 많습니다.
내부 링크의 역할은 사이트 내 이동 동선에 그치지 않습니다. 독자에게는 「다음에 읽어야 할 곳」이며, Google에게는 페이지 사이 관계를 이해하는 단서입니다. Google도 크롤 가능한 링크와 문맥이 있는 앵커 텍스트를 중요하게 봅니다.1
KomuraSoft의 웹 제작·SEO 토픽 같은 글 허브는, 글과 서비스 페이지를 오가기 쉽게 하려고 있습니다. 이 전제가 있으면 웹사이트 제작으로의 동선도 만들기 쉬워집니다.
이 글에서 쓰는 말
「필러 페이지(주제의 중심이 되는 허브 페이지)」「글 허브」는 쓰는 사람에 따라 이름이 흔들리는 말입니다. 이 글에서는 다음 의미로 씁니다.
| 이 글에서의 이름 | 자주 쓰는 다른 이름 | 의미 |
|---|---|---|
| 필러 페이지 | 주제의 중심이 되는 허브 페이지 | 한 주제 전체를 담당하는, 가장 굵은 페이지. 그 주제에서 먼저 읽히게 할 설명이 있고, 세부 내용은 하위 페이지로 넘깁니다 |
| 글 허브 | 허브 페이지, 토픽 목록 | 같은 주제의 글을 모아 나열한 페이지. 글끼리 직접 잇지 않고, 한 번 여기로 모아 정리합니다 |
| 서비스 페이지 | — | 무엇을 맡길 수 있는지를 적은, 상담의 입구가 되는 페이지. 필러 페이지가 「주제 설명」인 반면, 이쪽은 「의뢰를 받는 창구」입니다 |
필러 페이지와 글 허브는 역할이 다릅니다. 필러 페이지는 읽게 하는 페이지, 글 허브는 선택하게 하는 페이지입니다. 사이트 규모가 작을 때는 필러 페이지가 글 허브를 겸해도 됩니다.
전체 구조
세 가지 관계를 그림으로 그리면 이렇게 됩니다.
flowchart LR
H["글 허브<br/>주제별 글 목록"]
A["글<br/>개별 질문에 답한다"]
S["서비스 페이지<br/>무엇을 맡길 수 있는지"]
P["필러 페이지<br/>주제 전체의 창구"]
Q["문의 페이지"]
H --> A
A --> H
A --> S
S --> A
S --> P
P --> S
S --> Q
그림 1: 글 허브·글·서비스 페이지·필러 페이지·문의를 잇는 전체 구조. 대부분의 화살표가 양방향이다.
중요한 것은 화살표의 수가 아니라, 대부분의 화살표가 양방향인 것입니다. 한쪽만 있는 곳이, 나중에 「막다른 길」이 됩니다.
1. 내부 링크의 목적은 사이트 내 이동이 아니라 이해입니다
내부 링크라고 하면, 관련 글을 늘어놓아 페이지 이동 횟수를 늘리는 이야기로 보이기 쉽습니다. 하지만 본질은 이 페이지 묶음이 어떤 주제를 다루는지를 전하는 것입니다.
예를 들어,
- 글에서 서비스 페이지로 돌아간다
- 서비스 페이지에서 필러 페이지로 돌아간다
- 회사 정보나 문의에서 상담 동선으로 나아간다
이 왕복이 되면, 페이지는 단발이 아니라 주제의 덩어리로 보입니다.
flowchart TB
accTitle: 내부 링크의 목적은 이해
accDescr: 내부 링크의 본질은 관련 글을 늘어놓아 페이지 이동 횟수를 늘리는 것이 아니라, 이 페이지 묶음이 어떤 주제를 다루는지를 전하는 것이며, 글에서 서비스 페이지로, 서비스 페이지에서 필러 페이지로 왕복할 수 있으면 페이지가 단발이 아니라 주제의 덩어리로 보인다는 것을 나타내는 그림.
a0["내부 링크의 목적"] -.->|"본질이 아니다"| a1["페이지 이동 횟수를 늘린다"]
a0 -->|"본질"| a2["어떤 주제의 페이지 묶음인지를 전한다"]
a2 --> a3["글과 서비스 페이지·필러 페이지의 왕복을 만든다"]
a3 --> a4["단발이 아니라 주제의 덩어리로 보인다"]
그림 2: 링크는 사이트 내 이동 도구가 아니라, 주제의 묶음을 전하는 설계.
이 글의 지식 맵
내부 링크의 본질은 회유 횟수를 늘리는 일이 아니라, 글·글 허브·서비스 페이지·필러 페이지·문의 페이지라는 페이지들이 어떤 주제를 다루는지를 전하는 데 있습니다. 글은 서비스 페이지로, 서비스 페이지는 필러 페이지와 문의 페이지로 되돌아갈 수 있는 왕복 구조가 중요하며, 앵커 텍스트는 “자세한 내용은 여기”와 같은 일반적인 표현을 피하고 링크 대상의 역할이 그대로 드러나는 설명적인 문구로 씁니다. 구현에서는 링크를 a 요소와 href 속성으로 크롤 가능한 형태로 두고, 내부 링크에는 nofollow를 붙이지 않으며, 외부 링크에는 sponsored·ugc·nofollow를 용도에 따라 구분합니다. 브레드크럼과 사이트맵도 내부 링크를 보완하는 장치이며, 효과는 Search Console의 링크 리포트로 확인할 수 있습니다.
flowchart LR
accTitle: 내부 링크 설계의 지식 맵
accDescr: 글·글 허브·서비스 페이지·필러 페이지·문의 페이지가 오가는 내부 링크 구조, 설명적인 앵커 텍스트 권장, 크롤 가능한 링크와 rel 속성 등 구현상의 주의점, 브레드크럼과 사이트맵의 관계를 보여주는 그림
internal_link["내부 링크"]
service_page["서비스 페이지"]
blog_article["기사"]
pillar_page["필러 페이지"]
contact_page["문의 페이지"]
article_hub["기사 허브"]
descriptive_anchor_text["설명적 앵커 텍스트"]
generic_anchor_text["일반적인 표현의 앵커 텍스트"]
crawlable_link["크롤 가능 링크"]
rel_nofollow["rel=#quot;nofollow#quot; 속성"]
breadcrumb["브레드크럼"]
xml_sitemap["사이트맵"]
isolated_page["고립된 페이지"]
search_console["Google Search Console"]
rel_sponsored["rel=#quot;sponsored#quot; 속성"]
outbound_link["외부 링크"]
rel_ugc["rel=#quot;ugc#quot; 속성"]
blog_article -.->|"전제로 한다"| service_page
service_page -.->|"전제로 한다"| pillar_page
pillar_page -.->|"전제로 한다"| service_page
service_page -.->|"전제로 한다"| contact_page
article_hub -.->|"전제로 한다"| blog_article
blog_article -.->|"전제로 한다"| article_hub
descriptive_anchor_text -->|"권장되는 대응"| internal_link
generic_anchor_text -->|"사용은 비권장"| internal_link
internal_link -->|"전제로 한다"| crawlable_link
rel_nofollow -->|"사용은 비권장"| internal_link
breadcrumb -->|"이용한다"| internal_link
xml_sitemap -.->|"완화한다"| isolated_page
internal_link -->|"방지한다"| isolated_page
internal_link -->|"에서 확인할 수 있다"| search_console
rel_sponsored -->|"권장되는 대응"| outbound_link
rel_ugc -->|"권장되는 대응"| outbound_link
rel_nofollow -->|"권장되는 대응"| outbound_link
그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 17건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle
2. 앵커 텍스트는 링크 대상의 역할을 그대로 쓴다
내부 링크에서 가장 흔한 실패는 자세히 보기나 여기로 피하는 것입니다.
이래서는 링크 대상이 어떤 페이지인지 알 수 없습니다.
좋은 앵커 텍스트는 링크 대상의 역할이 그대로 보입니다.
| 두는 위치 | 약한 예 | 좋은 예 |
|---|---|---|
| 글 본문 | 자세히 보기 | 웹사이트 제작의 진행 방식을 본다 |
| 글 본문 | 이 글 | 웹사이트 제작에서 문의 동선을 상담한다 |
| 서비스 페이지 | 관련 페이지 | 웹사이트 제작을 본다 |
| 회사 정보 | 문의하기 | 문의에서 상담한다 |
Google은 링크 문구를 페이지 이해의 단서로 씁니다.
그래서 웹사이트 제작처럼, 링크 대상의 이름을 그대로 두는 편이 전해집니다.23
Google 스스로도, 좋은 앵커 텍스트는 「설명적이고, 적당히 짧으며, 링크 출발 페이지와 도착 페이지 양쪽에 관련되어 있는」 것이라고 하고, click here 같은 일반적인 표현을 피하라고 안내합니다.1
flowchart TB
accTitle: 앵커 텍스트의 좋고 나쁨
accDescr: 「자세히 보기」 같은 문구로는 링크 대상이 어떤 페이지인지 알 수 없고, Google은 링크 문구를 페이지 이해의 단서로 쓰므로, 설명적이고 적당히 짧으며 출발 페이지와 도착 페이지 양쪽에 관련된 문구로, 링크 대상의 역할을 그대로 쓰는 편이 독자에게도 검색 엔진에도 전해진다는 것을 나타내는 그림.
b0{"앵커 텍스트는"}
b0 -.->|"여기·자세히 보기"| b1["링크 대상이 어떤 페이지인지 모른다"]
b0 -->|"링크 대상의 역할을 그대로 쓴다"| b2["독자에게도 검색 엔진에도 전해진다"]
b2 -.-> b3["판정: 글자만 뽑아 목적지가 보이는가"]
그림 3: 링크 글자만 뽑아 목적지가 보이는지가, 유일한 판정 기준.
2.1 다른 업종으로 쓰면 어떻게 되는가
자사 말로 바꾸기 쉽도록, 업종을 바꾼 예도 늘어놓습니다. 링크로 걸지 않은, 문구 자체의 비교입니다.
| 업종 | 약한 앵커 텍스트 | 좋은 앵커 텍스트 |
|---|---|---|
| 장치 제조사 | 제품 정보는 여기 | 이송 컨베이어 사양 목록을 본다 |
| 조경·식재 | 실적 소개 | 대형 컨테이너 식재 납품 실적을 본다 |
| 회계 사무소 | 서비스 안내 | 법인 세무 자문의 업무 범위와 요금을 본다 |
| 수주 소프트웨어 개발 | 상세 페이지로 | 기존 시스템을 멈추지 않고 고치는 진행 방식을 본다 |
판정은 하나뿐입니다. 링크 글자만 뽑아 늘어놓았을 때, 어디로 가는 페이지인지 보이는가. 「자세히 보기」「실적 소개」만 늘어선 사이트는, 이 시점에서 구별할 수 없습니다.
3. 글에서 서비스 페이지로 되돌리는 세 가지 동선
글과 서비스 페이지는 적어도 세 곳에서 이어져 있으면 강합니다.
- 글 본문
- 글 말미의 관련 글
- 서비스 페이지의 관련 글
이 세 가지가 갖춰지면, 독자는 글을 읽은 뒤 자연스럽게 다음으로 나아갑니다. 예를 들어, 이 글에서는 웹사이트 제작으로 돌아가는 것이 자연스럽습니다.
flowchart TB
accTitle: 글과 서비스 페이지를 잇는 세 가지 동선
accDescr: 글과 서비스 페이지는 글 본문, 글 말미의 관련 글, 서비스 페이지 쪽의 관련 글 적어도 세 곳에 동선을 두면 이동하기 쉬워지고, 이 세 가지가 갖춰지면 독자는 글을 읽은 뒤 자연스럽게 다음으로 나아간다는 것을 나타내는 그림.
c1["1. 글 본문의 링크"] --> c4["세 곳이 갖춰진다"]
c2["2. 글 말미의 관련 글"] --> c4
c3["3. 서비스 페이지 쪽의 관련 글"] --> c4
c4 --> c5["읽은 뒤 자연스럽게 다음으로 나아간다"]
그림 4: 이음매는 한 곳이 아니라, 본문·글 말미·서비스 페이지 쪽의 세 곳.
4. 서비스 페이지에서 필러 페이지로 되돌린다
서비스 페이지 쪽에서도, 필러 페이지로 돌아갈 수 있는 동선이 필요합니다. 특히 단일 서비스와 필러 페이지가 나뉘어 있는 경우에는, 그 사이를 오갈 수 있는 것이 중요합니다.
KomuraSoft에서는 웹사이트 제작을 Web 쪽 상담 입구로 두고, 거기에서 제작 내용, SEO, 문의 동선 이야기로 나누는 구성으로 합니다. 이 형태로 두면, 글에서 온 사람도 서비스 페이지에서 온 사람도, 같은 상담 입구로 모으기 쉬워집니다.
5. 자주 있는 실패
내부 링크에서 자주 있는 실패는 이 부근입니다.
- 어느 페이지나 같은 「자세히 보기」인 것
- 글에만 링크가 있고, 서비스 페이지에서 돌아가지 못하는 것
- 필러 페이지가 있는데도, 그리로 되돌리는 동선이 없는 것
- 문의 페이지만 고립되어 있는 것
이 상태면, 글을 읽은 사람이 어디로 가야 할지 모르게 됩니다. 고립된 페이지는 sitemap을 제출하면 크롤 자체는 도움이 되지만, 그것은 페이지의 존재를 검색 엔진에 알리는 보조이지, 독자가 다음에 나아갈 길을 대신하지는 않습니다.4 내부 링크는 수보다 각 글에서 주요 허브/서비스 페이지로의 돌아가는 곳이 분명한지가 중요합니다.
flowchart TB
accTitle: 자주 있는 실패와 공통 증상
accDescr: 어느 페이지나 같은 「자세히 보기」인 것, 글에만 링크가 있고 서비스 페이지에서 돌아가지 못하는 것, 필러 페이지로 되돌리는 동선이 없는 것, 문의 페이지만 고립되어 있는 실패는 모두, 글을 읽은 사람이 어디로 가야 할지 모르게 되는 증상으로 이어지며, 중요한 것은 수가 아니라 각 글에서 주요 허브/서비스 페이지로의 돌아가는 곳이 분명한지임을 나타내는 그림.
d1["전부 「자세히 보기」"] -.-> d5["나아갈 곳이 보이지 않는다"]
d2["서비스에서 돌아가지 못한다"] -.-> d5
d3["필러 페이지로 되돌리는 동선이 없다"] -.-> d5
d4["문의가 고립"] -.-> d5
d5 --> d6["수보다 돌아가는 곳의 분명함"]
그림 5: 네 가지 실패는 모두 「돌아갈 곳이 정해져 있지 않다」로 귀결된다.
6. 구현에서 주의할 점
설계가 맞아도, 링크 쓰는 법에 따라 검색 엔진이 따라가지 못합니다.
Google은 a 요소에 href 속성이 붙은 형태가 아니면 크롤할 수 없다고 명시합니다.1
그래서 구현에서는 다음 세 가지를 확인합니다.
| 확인할 것 | 괜찮은 형태 | 위험한 형태 |
|---|---|---|
| 링크 쓰는 법 | a 요소에 href 속성을 쓴다 |
span이나 div에 클릭 이벤트만 붙인 것 |
| JavaScript 다루기 | JavaScript로 삽입하는 경우에도, 최종적으로 a와 href 형태가 되어 있다 |
프레임워크의 라우팅 속성만 두고, href를 출력하지 않은 것 |
rel 속성 |
광고나 외부 게시 등, 표시가 필요한 외부 링크에만 붙인다 | 자사 중요 페이지로의 내부 링크에, 의미 없이 rel="nofollow"를 붙인 것 |
JavaScript로 링크를 동적으로 끼워 넣는 것 자체는 문제가 되지 않습니다. Google도, 위의 HTML 형태이면 크롤할 수 있다고 안내합니다.1
rel 속성은 sponsored가 광고나 유료 게재, ugc가 게시·댓글에서 온 링크, nofollow가 그 밖에서 관련을 붙이고 싶지 않은 경우, 라는 쓰임새로 안내되어 있습니다.5
모두 외부 링크를 표시하기 위한 것이고, 자사 사이트 안 페이지를 검색 엔진에 보이고 싶지 않은 경우에는 robots.txt의 disallow 규칙을 쓰라고 안내되어 있습니다.5
즉, 내부 링크에 nofollow를 붙이는 것은, 설계로서 잘못된 것입니다.
flowchart TB
accTitle: 크롤할 수 있는 링크의 형태
accDescr: Google은 a 요소에 href 속성이 붙은 형태가 아니면 크롤할 수 없다고 명시하며, JavaScript로 삽입하는 경우에도 최종적으로 a와 href 형태이면 문제없고, rel 속성은 외부 링크를 표시하기 위한 것이며, 내부 링크에 nofollow를 붙이는 것은 설계로서 잘못임을 나타내는 그림.
e1{"링크 구현은"}
e1 -->|"a 요소+href 속성"| e2["크롤할 수 있다 (JS 삽입이어도 최종 형태가 이것이면 OK)"]
e1 -.->|"span이나 div에 클릭 이벤트만"| e3["검색 엔진이 따라가지 못한다"]
e2 -.-> e4["rel 표시는 외부 링크용. 내부 링크에 nofollow는 잘못"]
그림 6: 설계가 맞아도, a+href 형태가 아니면 따라가지 못한다.
7. 사이트 구조와 breadcrumb
내부 링크는 본문 속 링크만이 아닙니다. breadcrumb은 그 페이지가 사이트 계층의 어디에 있는지를 나타내는 상시 내부 링크입니다. Google은 breadcrumb이 사이트 이해와 사이트 내 이동을 돕는다고 설명하며, 구조화 데이터로 보이면 검색 결과 쪽에도 반영되는 경우가 있습니다.6
계층 설계는 다음 두 가지를 지키면 크게 무너지지 않습니다.
- 한 주제에 필러 페이지는 하나만 둔다. 비슷한 필러 페이지가 두 개 있으면, 글의 돌아가는 곳이 매번 흔들립니다.
- 어느 글에서든 2클릭 이내에 필러 페이지나 서비스 페이지에 닿는다. 글에서 글로만 끝없이 이어지는 상태를 만들지 않는다는 뜻입니다.
flowchart TB
accTitle: 무너지지 않는 계층 설계의 두 규칙
accDescr: 한 주제에 필러 페이지는 하나만 둘 것, 어느 글에서든 2클릭 이내에 필러 페이지나 서비스 페이지에 닿을 것, 이 두 가지를 지키면 계층 설계는 크게 무너지지 않으며, 비슷한 필러 페이지가 두 개 있으면 글의 돌아가는 곳이 매번 흔들리고, 글에서 글로만 끝없이 이어지는 상태도 피할 수 있음을 나타내는 그림.
f1["규칙 1: 필러 페이지는 주제당 하나"] --> f3["계층은 크게 무너지지 않는다"]
f2["규칙 2: 2클릭으로 필러 페이지에"] --> f3
f1 -.-> f4["필러 페이지가 두 개면 돌아가는 곳이 흔들린다"]
f2 -.-> f5["글만의 연쇄를 막는다"]
그림 7: 계층은 두 규칙을 지키는 것만으로, 돌아가는 곳이 흔들리지 않게 된다.
덧붙여, Google의 안내는 링크를 크롤할 수 있는 형태로 두는 것과 앵커 텍스트를 설명적으로 쓰는 것이지, 페이지당 링크 수 상한이 아닙니다.1 수를 목표로 하기보다, 스스로 운용 규칙을 정해 두는 편이 실무적입니다. 예를 들어 이렇게 정합니다.
- 같은 링크 대상을, 한 단락 안에서 두 번 이상 걸지 않는다
- 본문 속 링크는, 그 단락을 읽는 손이 멈추지 않는 범위에 둔다
- 글 말미의 관련 글은 건수를 먼저 정해 고정한다. 나열 순서에도 의미를 둔다
8. 자기 사이트에 적용하는 절차
여기까지의 내용을 그대로 작업 절차로 하면 다음 네 단계가 됩니다. 글이 어느 정도 쌓인 사이트라면, 처음 두 단계만으로도 정리가 진행됩니다.
8.1 글 목록 정리
먼저 표를 한 장만 만듭니다. 복잡한 도구는 필요 없습니다.
| 열 | 무엇을 쓰는가 |
|---|---|
| URL | 글의 주소 |
| 주제 | 어느 서비스에 가장 가까운가. 어느 쪽에도 가깝지 않으면 「없음」이라고 쓴다 |
| 본문의 링크 대상 | 지금 본문에서 나가는 링크의 도착지 |
| 돌아가는 곳 | 서비스 페이지나 필러 페이지로 돌아가 있는가. 돌아가 있지 않으면 빈칸 |
「돌아가는 곳」이 빈칸인 행이, 그대로 고칠 대상입니다.
8.2 필러 페이지와 글 허브를 정한다
주제 열을 집계하면, 글이 많이 모인 주제가 보입니다. 그 주제마다 필러 페이지를 하나 정합니다. 기존 서비스 페이지를 필러 페이지로 그대로 써도 됩니다.
이때 주제가 「없음」인 글이 3편 이상이면, 그것은 새 필러 페이지의 후보입니다. 반대로 1편뿐인 주제는, 무리해서 필러 페이지를 만들지 않고 기존 필러 페이지로 모읍니다.
8.3 링크 배치의 우선순위
전부를 한 번에 고칠 필요는 없습니다. 효과가 나기 쉬운 순으로 나열하면 이렇게 됩니다.
- 방문이 많은 글에서 서비스 페이지로 되돌린다. 여기가 가장 빨리 효과가 납니다
- 서비스 페이지에서 그 글로 되돌린다. 한쪽 방향을 왕복으로 바꿉니다
- 글 허브를 정리하고, 거기에서 각 글로 잇는다
- 필러 페이지와 서비스 페이지를 서로 링크한다
- 나머지 글을 위에서부터 순서대로 처리한다
8.4 반대 방향을 반드시 만든다
3의 절차까지 왔으면, 8.1의 표에 「돌아가는 곳」을 채워 가며 진행합니다. 한쪽 방향 링크만 더하고 끝나면, 5장의 「글에만 링크가 있고, 서비스 페이지에서 돌아가지 못하는」 상태가 다시 만들어집니다.
flowchart TB
accTitle: 자기 사이트에 적용하는 네 단계
accDescr: 글 목록 정리 표를 만들고, 주제 집계에서 필러 페이지와 글 허브를 정하며, 방문이 많은 글부터 효과가 나기 쉬운 순으로 링크를 배치하고, 마지막에 반드시 반대 방향 링크를 만들어 왕복으로 만든다는 네 단계 작업 절차를 나타내는 그림.
g1["8.1 글 목록 정리 표를 만든다 (돌아가는 곳의 빈칸을 찾는다)"] --> g2["8.2 주제 집계에서 필러 페이지와 글 허브를 정한다"]
g2 --> g3["8.3 효과가 나기 쉬운 순으로 링크를 배치한다"]
g3 --> g4["8.4 반대 방향을 반드시 만들어 왕복으로 한다"]
g4 -.-> g5["한쪽 방향으로 끝내면 실패가 다시 만들어진다"]
그림 8: 절차는 목록 정리→필러 페이지 결정→배치→반대 방향의 네 단계이며, 왕복까지 만들어야 완료.
9. 효과를 어떻게 보는가
내부 링크의 효과는 순위보다 먼저 구조로서 의도대로 되어 있는지로 확인할 수 있습니다.
Search Console의 링크 보고서에서는, 사이트 안 링크가 많은 페이지나, 링크 출발 텍스트를 확인할 수 있습니다.7 여기서 볼 것은 다음 두 가지입니다.
- 필러 페이지와 서비스 페이지가, 사이트 안 링크가 많은 페이지의 상위에 와 있는가. 와 있지 않으면, 설계한 돌아가는 곳에 실제로는 걸려 있지 않습니다
- 링크 출발 텍스트로 「여기」「상세」만 늘어서 있지 않은가
그다음에, 고친 페이지의 노출수와 클릭수를, 고치기 전과 후를 같은 길이의 기간으로 비교합니다. 얼마나 움직이는지는 사이트 규모와 경쟁 상황에 따라 달라지므로, 기준 숫자를 다른 회사에서 빌려 오지 않는 편이 좋습니다.
flowchart TB
accTitle: 내부 링크 효과를 보는 방법
accDescr: 효과는 순위보다 먼저 구조로서 의도대로인지를 확인하고, Search Console의 링크 보고서에서 필러 페이지와 서비스 페이지가 사이트 안 링크 상위에 와 있는지, 링크 출발 텍스트에 「여기」만 늘어서 있지 않은지를 본 뒤, 노출수와 클릭수를 고치기 전후 같은 길이의 기간으로 비교한다는 것을 나타내는 그림.
h1["링크 보고서로 구조를 확인한다"] --> h2["필러 페이지와 서비스 페이지가 상위에 와 있는가"]
h2 --> h3["링크 출발 텍스트가 「여기」만은 아닌가"]
h3 --> h4["노출·클릭을 고치기 전후 같은 기간으로 비교한다"]
h4 -.-> h5["기준 숫자는 다른 회사에서 빌리지 않는다"]
그림 9: 순위보다 먼저, 구조가 의도대로인지를 링크 보고서로 확인한다.
정리
내부 링크 설계의 기본은 글을 늘리는 것이 아니라, 글, 서비스 페이지, 필러 페이지의 왕복을 만드는 것입니다. 먼저 웹 제작·SEO 토픽에서 웹사이트 제작으로 되돌리고, 필요하면 문의 동선이나 글 설계 상담으로 나누는 흐름을 만들면, 동선이 안정됩니다.
글의 링크 대상을 헤매지 않고 고를 수 있게 되면, 검색에도 독자에게도 친절한 사이트가 됩니다.
관련 글
참고 자료
-
Google Search Central, Link best practices for Google ↩ ↩2 ↩3 ↩4 ↩5
-
Google Search Central, Search Essentials ↩
-
Google Search Central, Influencing title links in search results ↩
-
Google Search Central, Build and submit a sitemap ↩
-
Google Search Central, Qualify your outbound links to Google ↩ ↩2
-
Google Search Console Help, Links report ↩
관련 기사
같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.
BtoB 사이트에서 문의를 늘리기 ── 고치는 순서의 전체 지도(유입부터 폼까지)
BtoB 사이트 문의를 늘리려면 측정으로 병목을 찾고, 서비스 페이지를 정비하고, 동선을 고친 뒤, 마지막에 유입을 더하는 순서가 유효합니다. 각 시책 글을 고치는 순서에 맞춰 지도로 정리하고, 90일 계획까지 묶습니다.
서비스 페이지는 어떻게 만들 것인가 - 기술계·B2B를 위한 정리 절차
기술계·B2B를 대상으로, 서비스 페이지의 역할, 제목, 설명문, CTA, 문의 동선을 어떻게 정리할지를 정리합니다.
문의가 오지 않는 사이트에서 먼저 고쳐야 할 세 곳
문의가 멈춘 사이트에서 먼저 고쳐야 할 홈, 서비스 페이지, 문의 페이지의 논점을, 이탈하기 쉬운 동선별로 정리합니다.
기술계 기업의 홈페이지에서 「무엇을 하는 회사인가」가 전해지지 않는 이유
기술계·B2B 사이트에서 회사의 실체가 전해지지 않는 원인을, 홈·서비스 페이지·회사 정보의 역할 분담부터 정리합니다.
사이트 리뉴얼 사례: 미야자키의 운송 회사 ドーズキャリーサービス ── 기존 사이트에서 무엇을 어떻게 이어받았는가
미야자키의 운송 회사 ドーズキャリー서비스 사이트 리뉴얼에서, 디자인보다 먼저 URL 전수 조사와 301 설계, 콘텐츠 유지 점검을 진행한 방식을 실제 사례로 설명합니다.
관련 토픽
이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.
Windows 기술 토픽
Windows 개발, 장애 조사, 기존 자산 활용에 관한 KomuraSoft LLC 기사를 모은 토픽 허브입니다.
웹 개발 & SEO 토픽
웹사이트 제작, SEO, 문의 동선, 내부 링크 설계를 정리한 토픽 허브입니다.
관련 사례
실제 정리와 개선 진행 방식이 가까운 사례 페이지입니다.
사이트를 두 기둥 구조로 재설계한 사례
Windows 중심의 표현에서 웹·SEO도 전해지는 2축 구조로 KomuraSoft LLC 사이트를 재설계한 사례 페이지입니다.
이 주제와 연결되는 서비스
이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.
웹사이트 제작
글에서 서비스 페이지로 잇는 내부 링크 설계는, 검색 동선과 문의 동선을 정리하는 SEO의 중심이기 때문입니다.
자주 묻는 질문
이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.
- 글을 늘렸는데도 문의로 이어지지 않는 이유는 무엇인가요?
- 글의 내용보다, 글에서 서비스 페이지로 돌아가는 길이 약한 것이 원인인 경우가 많습니다. 내부 링크의 본질은 페이지 이동 횟수를 늘리는 것이 아니라, 이 페이지 묶음이 어떤 주제를 다루는지를 전하는 것입니다. 글에서 서비스 페이지로, 서비스 페이지에서 필러 페이지(주제의 중심이 되는 허브 페이지)로 왕복할 수 있으면, 페이지는 단발이 아니라 주제의 덩어리로 보입니다.
- 내부 링크의 앵커 텍스트는 어떻게 쓰면 되나요?
- 링크 대상의 역할이 그대로 보이는 문구로 씁니다. 가장 흔한 실패는 「자세히 보기」나 「여기」로 피하는 것이고, 이래서는 링크 대상이 어떤 페이지인지 알 수 없습니다. Google은 링크 문구를 페이지 이해의 단서로 쓰므로, 「웹사이트 제작의 진행 방식을 본다」처럼 링크 대상의 이름을 그대로 두는 편이 독자에게도 검색 엔진에도 전해집니다.
- 글과 서비스 페이지는 어디에서 이어야 하나요?
- 적어도 세 곳에 동선을 두면, 글에서 서비스 페이지로 이동하기 쉬워집니다. 글 본문, 글 말미의 관련 글, 서비스 페이지 쪽의 관련 글입니다. 이 세 가지가 갖춰지면 독자는 글을 읽은 뒤 자연스럽게 다음으로 나아갑니다. 글 쪽에만 링크가 있고 서비스 페이지에서 돌아가지 못하는 상태는, 자주 있는 실패 중 하나입니다.
- 내부 링크에서 자주 하는 실패는 무엇인가요?
- 어느 페이지나 같은 「자세히 보기」인 것, 글에만 링크가 있고 서비스 페이지에서 돌아가지 못하는 것, 필러 페이지가 있는데도 그리로 되돌리는 동선이 없는 것, 문의 페이지만 고립되어 있는 것, 이 네 가지가 전형입니다. 이 상태면 글을 읽은 사람이 어디로 가야 할지 모르게 됩니다. 내부 링크는 수보다, 각 글에서 주요 허브/서비스 페이지로의 돌아가는 곳이 분명한지가 중요합니다.