메뉴만 정하면 끝일까? 내부 링크로 완성하는 사이트 구조

상단 메뉴를 ‘회사 소개, 서비스, 블로그, 문의’로 정했다고 사이트 구조가 완성되는 것은 아닙니다. 방문자는 블로그 글이나 서비스 상세처럼 중간 페이지에서 들어올 수도 있습니다. 어느 화면에서 시작하더라도 다음에 필요한 정보를 찾을 수 있게 연결해야 합니다.

1. 메뉴 이름보다 페이지의 역할을 먼저 적어 보세요

실무에서는 각 페이지가 답할 질문을 한 문장으로 정리하는 방법을 권합니다. 회사 소개는 ‘누가 운영하는가’, 서비스 소개는 ‘무엇을 어디까지 제공하는가’, 사례는 ‘어떤 조건에서 무엇을 했는가’, 문의는 ‘어떻게 대화를 시작하는가’처럼 나눌 수 있습니다. 이는 모든 사이트가 따라야 하는 고정 메뉴가 아니라 기획을 위한 예시입니다.

두 페이지가 같은 질문에 같은 답을 준다면 합칠 여지가 있는지 검토하고, 한 페이지가 너무 많은 역할을 떠안고 있다면 나눌 필요가 있는지 살펴보세요. 페이지 수를 늘리는 것 자체를 목표로 삼기보다 독자가 필요한 답을 찾는 흐름을 그려 보는 편이 좋습니다.

2. 중요한 페이지에는 찾아갈 수 있는 연결이 필요합니다

Google은 중요하게 생각하는 페이지가 사이트 안의 다른 페이지 최소 한 곳에서 링크되어 있어야 한다고 안내합니다. 내부 링크는 새 페이지를 발견하고 내용을 이해하는 데에도 활용됩니다. Google 링크 권장사항의 내부 링크 항목을 참고하세요.

적용 예시: 제작 의뢰서 작성법을 설명한 글에서는 독자가 실제로 준비해야 할 자료가 담긴 서비스 안내로 연결합니다. 서비스 안내에서는 작업 범위를 확인한 뒤 문의할 수 있도록 연결합니다. 모든 페이지에 모든 링크를 넣기보다, 해당 문맥에서 필요한 다음 정보를 골라 주는 방식입니다.

3. 링크 문구는 도착할 곳을 설명해야 합니다

Google은 링크 텍스트가 구체적이고 적절히 간결하며 출발 페이지와 도착 페이지의 내용에 관련되도록 권장합니다. 목적을 알아보기 어려운 ‘여기’, ‘더 보기’만 반복하는 것보다 링크 자체에서 이동할 내용을 짐작할 수 있게 만드는 편이 좋습니다. 공식 링크 텍스트 안내에 근거한 원칙입니다.

예를 들어 본문 중간의 ‘자세히 보기’는 ‘홈페이지 제작 진행 과정 보기’로 바꿔 볼 수 있습니다. 개발할 때도 목적지 주소를 가진 <a href="…"> 링크를 기본으로 사용하세요. 클릭 이벤트만 있는 다른 요소는 Google이 URL을 안정적으로 추출하지 못할 수 있다는 설명이 같은 문서에 나옵니다.

4. XML 사이트맵은 방문자용 메뉴를 대신하지 않습니다

XML 사이트맵은 검색엔진에 페이지와 파일 정보를 전달하는 자료입니다. Google은 사이트맵이 URL 발견에 도움을 주지만 모든 URL의 크롤링과 색인을 보장하지는 않는다고 설명합니다. 내부 페이지가 잘 연결되어 있다면 검색엔진은 그 연결을 따라 중요한 페이지를 발견할 수 있습니다. Google 사이트맵 안내를 참고하세요.

따라서 사이트맵 제출 여부와 방문자가 실제로 길을 찾을 수 있는지는 따로 살펴봐야 합니다. 사이트맵 파일에 주소가 있다고 해서 본문에서 고립된 페이지의 이용 문제가 해결되는 것은 아닙니다.

5. 처음에는 작은 연결표 하나면 충분합니다

기획 문서에 ‘페이지 이름 / 답할 질문 / 들어오는 링크 / 다음에 안내할 페이지 / 콘텐츠 담당자’ 다섯 항목을 만들어 보세요. 모든 항목을 복잡하게 채우기보다 주요 서비스와 문의 화면부터 시작하면 됩니다. 이 연결표는 정해진 검색 순위 공식이 아니라 누락된 안내와 운영 책임을 찾기 위한 실무 도구입니다.

좋은 사이트 구조는 메뉴의 개수보다 연결의 이유가 분명한 구조입니다. 사용자가 지금 읽는 내용에서 자연스럽게 다음 질문으로 이동할 수 있는지부터 살펴보세요.

자료 확인일: 2026년 9월 7일. 공식 문서를 바탕으로 AI의 도움을 받아 작성한 정보성 콘텐츠입니다. 적용 예시는 이해를 돕기 위한 가상 예시이며, 특정 프로젝트의 성과나 검증 결과를 의미하지 않습니다. 서비스의 정책과 문서는 변경될 수 있습니다.

문의하기 쉬운 웹사이트를 만드는 접근성 기본기

방문자가 문의 버튼까지 찾았는데 입력을 마치지 못한다면 무엇부터 살펴봐야 할까요? 문구나 버튼 색상만의 문제는 아닐 수 있습니다. 입력칸의 의미가 불분명하거나, 오류가 어디에 생겼는지 알 수 없거나, 키보드로 다음 항목에 갈 수 없는 상황도 함께 생각해야 합니다.

1. 클릭하지 않아도 주요 기능을 사용할 수 있어야 합니다

W3C WAI는 메뉴, 아코디언, 미디어 플레이어 등 상호작용 요소의 키보드 접근성을 고려하도록 안내합니다. 눈에 보이는 모양만 버튼처럼 만들지 말고, 기능과 상태를 보조 기술에도 전달해야 합니다. WAI 개발 접근성 안내에서 관련 원칙을 확인할 수 있습니다.

실무에서는 ‘메뉴 열기 → 서비스 선택 → 문의 이동 → 입력 → 제출’이라는 한 가지 흐름부터 정리해 보세요. 각 단계에서 현재 선택된 요소가 보이고 다음 행동을 수행할 수 있는지 살펴보는 방식입니다. 키보드로 들어갈 수는 있지만 빠져나올 수 없는 요소도 사용자에게 장애물이 됩니다.

2. 입력칸의 이름은 입력 중에도 알아볼 수 있게 만드세요

WAI는 폼 컨트롤마다 연결된 레이블을 제공하도록 안내합니다. 일반적으로 입력 요소의 id와 레이블의 for를 연결할 수 있습니다. 이미지가 정보를 전달한다면 대체 텍스트를 제공하고, 순수한 장식 이미지라면 빈 대체 텍스트를 사용하도록 구분합니다. 레이블과 이미지에 관한 공식 개발 안내를 참고하세요.

적용 예시: 문의 양식에 ‘이메일’이라는 이름을 계속 표시하고, 입력 예시는 보조 설명으로 둡니다. 이미지를 버튼으로 사용한다면 파일명을 읽어 주는 대신 ‘첨부파일 추가’처럼 어떤 동작인지 알 수 있는 이름을 준비하는 방향을 권합니다.

3. 오류를 빨간색 하나로만 알리지 마세요

WAI의 디자인 안내는 색상만으로 정보를 구분하지 말고, 명확한 피드백을 제공하도록 권장합니다. 글자와 배경의 충분한 대비도 필요합니다. 사진 위 텍스트나 버튼 안의 작은 글자도 함께 고려해야 합니다. WAI 디자인 접근성 안내에 설명된 원칙입니다.

예를 들어 이메일 형식이 잘못됐을 때 테두리만 빨갛게 바꾸기보다 ‘이메일 주소에 @와 도메인을 포함해 주세요’라는 설명을 함께 제공할 수 있습니다. 필수 항목에는 색 외에 ‘필수’ 문구를 쓰고, 제출 결과도 ‘전송 완료’처럼 명확히 알리는 방식을 제안합니다.

4. 한 화면이 아니라 완료까지의 흐름을 보세요

입력 화면만 정돈되어 있어도 오류 발생 뒤의 안내나 완료 화면이 불명확하면 사용자는 작업을 마쳤는지 판단하기 어렵습니다. 팀에서 기본 상태, 입력 중, 오류 발생, 전송 중, 완료 상태를 나눠 필요한 안내를 정리해 보세요. 이는 위 원칙을 문의 양식에 적용하기 위한 실무 제안입니다.

담당자끼리 ‘접근성을 적용했다’는 말만 주고받기보다 어느 기능에 무엇을 반영했는지 남기는 편이 좋습니다. 레이블 제공, 오류 문구 추가, 키보드 조작 가능 여부처럼 구체적인 항목으로 나누면 수정 범위를 이해하기 쉽습니다.

5. 기본기를 적용했다고 전체 준수가 끝나는 것은 아닙니다

WAI의 시작하기 문서는 접근성을 위한 일부 고려사항을 소개하는 자료입니다. 위 항목만으로 전체 WCAG 충족 여부를 판정할 수는 없습니다. 개발 안내의 추가 학습 자료를 바탕으로 서비스의 화면과 기능 범위를 넓혀 가야 합니다.

출발점은 거창할 필요가 없습니다. 가장 중요한 한 가지 이용 흐름을 정하고, 방문자가 어느 단계에서도 다음 행동을 이해할 수 있도록 만드는 일부터 시작해 보세요.

웹사이트 속도, 점수보다 먼저 봐야 할 세 가지

속도가 느리다는 말에는 서로 다른 문제가 섞여 있습니다. 첫 화면이 늦게 나타나는 것과 버튼을 눌러도 반응하지 않는 것은 같은 문제가 아닙니다. 성능을 개선하려면 하나의 점수만 보기보다 사용자가 어느 순간에 불편을 겪는지 구분하는 것이 출발점입니다.

1. LCP·INP·CLS는 서로 다른 경험을 측정합니다

Core Web Vitals의 현재 지표는 LCP, INP, CLS입니다. LCP는 주요 콘텐츠가 나타나는 로딩 경험, INP는 상호작용에 대한 반응성, CLS는 예기치 않은 화면 이동과 관련된 시각적 안정성을 다룹니다. 정의는 web.dev의 Web Vitals 안내에 정리되어 있습니다.

좋음 기준: LCP는 2.5초 이하, INP는 200밀리초 이하, CLS는 0.1 이하입니다. CLS는 시간이 아니라 점수입니다. 평가는 모바일과 데스크톱을 구분한 실제 방문 데이터의 75번째 백분위 값을 기준으로 봅니다. 평균값이나 가장 빠른 한 번의 기록과는 다릅니다. 공식 임곗값 설명을 참고하세요.

2. 실험실 점수와 실제 방문 경험을 구분하세요

정해진 환경에서 실행하는 측정은 개발 중 원인을 찾는 데 유용하지만 실제 사용자 데이터를 대체하지는 못합니다. 사용자의 기기, 네트워크, 페이지에서 하는 행동이 다르기 때문입니다. 일반적인 Lighthouse 페이지 로딩 측정은 사용자 상호작용이 없어 INP를 직접 측정하지 못하며 TBT를 참고 지표로 사용합니다. Web Vitals의 실험실·현장 측정 설명에 나오는 구분입니다.

예를 들어 개발자의 노트북에서는 첫 화면이 빠르게 떠도, 사용자가 오래 머무르며 검색 필터를 조작할 때는 반응이 느릴 수 있습니다. 따라서 ‘메인 화면을 열었을 때’뿐 아니라 ‘상품을 찾을 때’, ‘문의 양식을 작성할 때’처럼 이용 흐름을 나눠 문제를 기록하는 방법을 권합니다.

3. 증상에 맞는 개선부터 시작하세요

첫 화면이 늦다면: LCP에 해당하는 이미지가 늦게 발견되거나 지연 로딩되고 있는지 살펴볼 수 있습니다. 버튼 반응이 느리다면: 불필요한 JavaScript와 긴 작업을 줄이거나 나누는 방향을 검토합니다. 화면이 밀린다면: 이미지와 임베드가 차지할 공간을 크기나 비율로 미리 확보하는 방법이 있습니다. 세 방향 모두 web.dev의 Core Web Vitals 개선 권장사항에 근거합니다.

모든 이미지에 같은 지연 로딩 정책을 적용하거나, 이유를 확인하지 않고 플러그인을 일괄 삭제하는 방식은 피하는 편이 좋습니다. 실제 병목이 무엇인지에 따라 필요한 수정이 달라지기 때문입니다. 기능을 없애지 않고도 자원이 실행되는 시점과 범위를 조정할 수 있는지 먼저 논의해 보세요.

4. 점수와 비즈니스 목표는 따로 기록하세요

Google은 Core Web Vitals를 실제 사용자 경험을 측정하는 지표로 설명하고 좋은 경험을 권장합니다. 하지만 이 설명을 특정 점수만으로 검색 순위나 매출이 보장된다는 뜻으로 확대해서는 안 됩니다. 근거 범위는 Google의 Core Web Vitals 안내를 참고하세요.

실무 기록에는 문제 화면, 사용자의 행동, 관련 지표, 수정 내용, 문의 완료 같은 운영 목표를 별도 항목으로 남기는 방식을 제안합니다. 측정값이 좋아졌다는 사실과 실제 성과가 달라졌다는 사실을 분리하면 다음 개선의 우선순위도 더 명확해집니다.

GEO는 SEO와 무엇이 다를까? AI 검색을 준비하는 현실적인 방법

검색결과의 링크뿐 아니라 AI가 작성한 답변 안에서도 우리 서비스를 발견하게 하고 싶다는 요구가 생기고 있습니다. 이 글에서는 생성형 AI의 답변에서 콘텐츠가 발견되거나 참고될 가능성을 높이려는 작업을 GEO라고 부르겠습니다. 다만 모든 AI 서비스에 통하는 하나의 공식이나 노출 보장 규칙이 있다는 뜻은 아닙니다.

1. Google의 AI 검색에서도 SEO 기본기는 이어집니다

Google은 AI Overviews와 AI Mode에 나타나기 위해 별도의 특별한 최적화가 필요한 것은 아니라고 설명합니다. 지원 링크로 표시될 수 있으려면 페이지가 색인되어 있고 검색에서 스니펫 표시 자격을 갖추어야 하며, 조건을 갖춰도 노출은 보장되지 않습니다. Google의 AI 기능과 웹사이트 안내가 설명하는 범위입니다.

따라서 기존 SEO를 모두 버리고 AI용 페이지를 따로 만드는 일부터 시작할 필요는 없습니다. 또한 Google에 대한 설명을 다른 회사의 AI 검색 서비스에 그대로 적용해서도 안 됩니다. 서비스마다 공개한 문서와 접근 정책을 구분해서 읽어야 합니다.

2. 특별한 파일보다 먼저 정리할 것이 있습니다

Google의 생성형 AI 최적화 가이드는 Google 검색이 llms.txt를 사용하지 않으며, 생성형 AI 검색을 위한 특별한 구조화 데이터도 요구하지 않는다고 명시합니다. 이는 다른 서비스가 해당 파일을 사용하는지와는 별개의 설명입니다. Google 생성형 AI 검색 최적화 가이드에서 적용 범위를 확인하세요.

실무적으로는 새로운 파일을 추가하기 전에 서비스명, 제공 범위, 대상 고객, 운영 조건이 서로 모순되지 않는지 정리하는 것을 권합니다. 소개 페이지에는 ‘유지보수 포함’, 견적 안내에는 ‘유지보수 별도’라고 적혀 있다면 사람도 조건을 판단하기 어렵습니다. 먼저 어느 설명이 현재 기준인지 정해야 합니다.

3. 짧게 쪼개기보다 독자가 이해할 수 있게 쓰세요

Google은 AI를 위해 본문을 아주 작은 단위로 나누거나 특별한 문체로 다시 쓸 필요가 없다고 안내합니다. 독자에게 유용한 고유한 관점과 명확한 구성이 중요하다는 설명입니다. 공식 최적화 가이드의 콘텐츠·오해 해설을 참고하세요.

적용 예시: ‘반응형 웹사이트를 제작합니다’라는 한 문장 뒤에 어떤 화면을 지원하는지, 콘텐츠를 누가 수정하는지, 기존 데이터를 이전하는지 설명할 수 있습니다. 실제로 수행한 프로젝트가 있다면 공개 가능한 범위에서 조건과 선택 이유를 덧붙이세요. 경험이 없다면 가상의 성과를 쓰는 대신 설명용 예시라고 명시해야 합니다.

4. 사실과 제안, 작성 방식을 구분하세요

공식 문서가 확인해 주는 사실, 작성자의 해석, 아직 확인하지 못한 가설은 서로 다릅니다. Google의 콘텐츠 가이드는 누가, 어떻게, 왜 작성했는지를 독자가 이해할 수 있도록 하는 관점을 제시합니다. 유용하고 신뢰할 수 있는 콘텐츠 안내를 참고하세요.

운영 방법으로는 중요한 주장 옆에 출처를 연결하고, 가격이나 제공 범위가 바뀌면 관련 페이지를 함께 수정하는 방식을 제안합니다. AI 답변에 한 번 등장한 결과만으로 지속적인 노출을 약속해서도 안 됩니다. GEO의 출발점은 ‘AI가 좋아할 문장’을 추측하는 것보다 사람이 이해하고 근거를 확인할 수 있는 원본을 만드는 데 있습니다.

홈페이지 SEO, 오픈 전에 챙겨야 할 기본기

홈페이지 디자인이 완성되면 검색에서도 곧바로 발견될까요? 공개와 검색 노출은 다른 단계입니다. SEO는 검색엔진이 내용을 이해하도록 돕고, 검색한 사람이 방문할 만한 페이지인지 판단하도록 만드는 작업입니다. 처음부터 순위를 약속하기보다, 발견하고 읽을 수 있는 상태를 만드는 데 집중해 보세요.

1. 검색엔진이 들어올 수 있는지부터 살펴보세요

Google이 제시하는 기본 기술 조건은 크롤러가 차단되지 않을 것, 페이지가 HTTP 200 응답으로 정상 제공될 것, 색인 가능한 콘텐츠가 있을 것입니다. 이 조건을 만족해도 색인이 보장되는 것은 아닙니다. Google 검색의 기술 요구사항에서 각 조건을 확인할 수 있습니다.

제작 중 사용한 로그인 제한이나 검색 제외 설정을 공개 뒤에도 유지하면 중요한 페이지가 발견되지 않을 수 있습니다. 반대로 관리자 화면과 개인정보가 담긴 페이지는 공개할 대상이 아닙니다. 실무에서는 먼저 ‘검색에 보여줄 페이지’와 ‘보호할 페이지’를 나눈 뒤 설정을 정리하는 편이 안전합니다.

2. 제목은 키워드 묶음보다 페이지의 약속에 가깝습니다

Google은 페이지마다 고유하고 간결하며 본문을 정확히 설명하는 제목을 권장합니다. 같은 단어를 과도하게 반복하는 방식은 피해야 합니다. 검색결과 제목은 제목 태그뿐 아니라 페이지의 다른 요소를 참고해 생성될 수 있습니다. Google SEO 기본 가이드의 제목 안내를 참고하세요.

예를 들어 모든 페이지에 ‘홈페이지 제작 전문 업체’를 붙이기보다, 서비스 소개에는 ‘기업 홈페이지 제작 범위와 진행 과정’, 안내 글에는 ‘홈페이지 제작 의뢰서에 적을 항목’처럼 역할이 드러나는 제목을 붙일 수 있습니다. 이는 정답으로 정해진 문구가 아니라 페이지의 차이를 분명히 만드는 예시입니다.

3. 고객이 결정하는 데 필요한 답을 본문에 넣으세요

제목은 구체적인데 본문이 ‘최고의 품질을 제공합니다’로 끝난다면 독자의 질문은 해결되지 않습니다. 글의 길이를 늘리기 전에 누가 읽고 무엇을 결정해야 하는지부터 적어 보세요. Google도 특정 글자 수를 순위의 정답으로 제시하지 않습니다. 같은 SEO 기본 가이드는 읽기 쉽고 유용한 콘텐츠에 집중하도록 안내합니다.

적용 예시: 제작 서비스 페이지라면 작업 범위, 고객이 준비할 자료, 일정에 영향을 주는 조건, 납품 후 운영 범위를 구분합니다. 금액을 일괄 공개하기 어렵다면 ‘어떤 조건에 따라 견적이 달라지는지’를 설명하는 방식도 가능합니다. 공개할 수 없는 정보를 만들어 내거나, 보유하지 않은 실적을 넣어서는 안 됩니다.

4. 오픈일에는 담당자와 확인 대상을 남기세요

실무용 준비 목록으로는 핵심 페이지 주소, 페이지별 제목, 검색 공개 여부, 콘텐츠 담당자, 다음 검토일을 한 표에 정리하는 방식을 제안합니다. 검색 상태를 살펴볼 때는 Search Console의 URL 검사 도구를 활용할 수 있습니다. 기술 조건과 검사 도구는 공식 기술 문서에 안내되어 있습니다.

핵심은 순서를 지키는 것입니다. 접근 가능한 상태를 만들고, 페이지의 역할을 설명하고, 고객의 질문에 답하세요. 그다음 공개 이후의 데이터를 바탕으로 수정할 대상을 고르는 편이, 근거 없이 제목을 계속 바꾸는 것보다 합리적인 운영 방식입니다.

Hello world!

Welcome to WordPress. This is your first post. Edit or delete it, then start writing!

메뉴만 정하면 끝일까? 내부 링크로 완성하는 사이트 구조.