검색과 AI에 잘 잡히는 홈페이지 구조 설계법

홈페이지를 새로 만들 때 대부분의 사업가는 색상과 폰트, 메인 이미지부터 고민한다. 그러나 정작 검색 노출과 AI 인용을 좌우하는 것은 눈에 보이는 화면이 아니라, "그 화면 뒤에 숨어 있는 구조"다. 메뉴를 어떻게 나누고, URL을 어떻게 짓고, 페이지끼리 어떻게 연결하느냐가 곧 구조다.

결론부터 말하면 이렇다. 좋은 홈페이지 구조란 사람도 헤매지 않고, 구글도 빠르게 훑고, AI도 오해 없이 인용할 수 있는 정보 설계를 말한다. 이것은 디자인이 완성된 뒤에 손보는 마무리 작업이 아니라, 기획 단계에서 가장 먼저 정해야 하는 뼈대다.

뼈대가 부실하면 그 위에 아무리 예쁜 살을 붙여도 오래 못 간다. 이 글은 정보구조(IA)와 URL 설계, 내부 링크, 그리고 요즘 화두인 AI 검색 대응까지, 홈페이지 구조를 처음부터 제대로 짜는 법을 예시 중심으로 정리한다.

이 글에서 먼저 챙겨 갈 핵심만 추리면 이렇다.

• 정보구조(IA)란 홈페이지 안의 콘텐츠를 어떻게 묶고 나눌지 정하는 설계도다 — 메뉴와 카테고리, URL이 모두 여기서 출발한다
• URL은 구글 공식 가이드대로 읽기 쉬운 단어와 하이픈으로 짓는다 — 의미 없는 숫자·파라미터는 정리한다
• 카테고리는 너무 얕지도, 너무 깊지도 않게 — 사람과 크롤러 모두 몇 번의 클릭으로 원하는 페이지에 닿아야 한다
• 내부 링크가 구조를 완성한다 — 아무리 카테고리를 잘 나눠도 링크로 잇지 않으면 무용지물이다
• 2026년 구글은 "AI를 위해 억지로 콘텐츠를 잘게 쪼개지 말라"고 공식 경고했다 — 대신 사람이 읽기 좋은 구조가 AI에도 결국 유리하다

조금 더 풀어 말하면, 홈페이지 구조는 도서관의 서가 배치와 닮았다. 서가가 주제별로 논리적으로 나뉘어 있으면 사서(검색엔진)도 손님(방문자)도 원하는 책을 금방 찾는다. 반대로 책이 아무렇게나 꽂혀 있으면, 아무리 좋은 책이 있어도 존재 자체가 묻혀 버린다.

이 글은 홈페이지를 새로 만들거나 리뉴얼을 앞둔 사업가, 그리고 이미 만든 사이트의 구조를 점검하고 싶은 담당자를 대상으로 한다. 어려운 용어는 나오는 자리에서 바로 한 문장으로 풀어 쓰고, 업종별 구체적인 예시와 나쁜 예·좋은 예를 곳곳에 배치했다.

최근 구글 검색 결과 화면에 AI가 생성한 요약이 자주 뜨면서, "우리 사이트는 왜 그 요약에 인용되지 않을까"를 묻는 사업가가 부쩍 늘었다. 원인을 추적해 보면 화려한 디자인이나 부족한 글자 수보다, 애초에 사이트 구조 자체가 애매해서 AI도 구글도 무엇을 인용해야 할지 판단하지 못하는 경우가 훨씬 많다. 그래서 이 글은 디자인 트렌드가 아니라, 그보다 한 단계 아래에 있는 구조 이야기부터 시작한다.

정보구조(IA)란 무엇이고 왜 가장 먼저 정해야 하나?

정보구조(IA, Information Architecture)란 홈페이지 안의 모든 콘텐츠를 어떤 기준으로 묶고, 어떤 위계로 나눌지 정하는 설계도를 말한다. 메뉴 이름, 카테고리 분류, 페이지 간 상하 관계가 모두 이 설계도 위에서 정해진다.

정보구조를 집짓기에 비유하면 이해가 쉽다. 인테리어(디자인)를 고르기 전에 방이 몇 개이고 어디에 무엇을 둘지부터 정해야 한다. 정보구조가 바로 이 "몇 개의 방을 어떻게 배치할지"에 해당한다. 방 배치가 잘못되면 나중에 벽지를 아무리 예쁘게 발라도 살기 불편한 집이 된다.

정보구조가 검색과 직결되는 이유는 세 가지다. 첫째, 구글은 사이트의 위계 구조를 보고 어떤 페이지가 더 중요한지 가늠한다. 홈에서 가까운 페이지, 상위 카테고리에 속한 페이지일수록 더 비중 있게 다뤄진다는 신호로 읽힌다. 둘째, 구조가 명확하면 URL과 메뉴, 브레드크럼(탐색경로)이 자연스럽게 따라 나온다. 여기서 브레드크럼이란 "홈 > 서비스 > 홈페이지 제작"처럼 현재 위치를 보여주는 탐색경로 표시를 말한다. 셋째, AI 검색 도구가 사이트를 요약할 때도 이 위계를 참고한다. 카테고리와 하위 페이지 관계가 뚜렷하면 AI가 "이 사이트는 무엇을 하는 곳인지"를 훨씬 정확히 파악한다.

정보구조를 나중에 손보는 것은 다 지은 집의 벽을 허물고 방을 다시 나누는 것과 같다. 사이트가 커지기 전, 페이지 수가 적을 때 바로잡는 것이 압도적으로 쉽다.

정보구조를 짤 때 던져야 할 질문은 하나다. "우리 손님은 이 사이트에서 무엇을 찾으러 왔고, 어떤 순서로 정보를 원할까?" 회사가 보여주고 싶은 순서가 아니라, 손님이 궁금해하는 순서로 카테고리를 나눠야 한다.

예를 들어 홈페이지 제작사라면 손님은 대개 "어떤 서비스가 있는지 → 얼마인지 → 실제로 잘 만드는지(포트폴리오·후기) → 어떻게 연락하는지" 순서로 정보를 찾는다. 이 순서를 그대로 카테고리 구조에 반영하면 자연스러운 사이트가 된다.

정보구조를 설계할 때 자주 쓰는 방법은 카드 소팅(card sorting)이다. 사이트에 넣을 콘텐츠 주제를 카드처럼 하나씩 적어 놓고, 비슷한 것끼리 묶어 카테고리 이름을 붙이는 방식이다. 거창한 도구가 없어도 포스트잇 몇 장으로 충분히 해볼 수 있다.

예를 들어 피부과 홈페이지를 새로 만든다고 해보자. "여드름 치료", "미백 관리", "보톡스", "필러", "예약 방법", "의료진 소개", "이용 후기", "주차 안내"라는 여덟 개의 주제 카드가 있다면, 이를 손님의 관점에서 "시술 종류(여드름·미백·보톡스·필러)", "병원 소개(의료진·후기)", "이용 안내(예약·주차)"라는 세 개의 카테고리로 묶을 수 있다. 이렇게 카드를 물리적으로 옮겨 가며 묶어 보면, 머릿속으로만 구상할 때보다 훨씬 빠르게 자연스러운 위계가 드러난다.

정보구조가 곧 URL 구조, 메뉴 구조, 내부 링크 구조의 뿌리가 된다는 점을 기억하자. 이 뿌리가 흔들리면 아래에서 다룰 나머지 모든 것이 흔들린다.

URL은 어떻게 설계해야 검색에 유리할까?

URL은 짧고, 읽을 수 있고, 그 페이지 내용을 짐작할 수 있게 지어야 한다. 구글은 공식 문서(Search Central의 URL 구조 가이드)에서 이 원칙을 분명히 밝히고 있다.

구글이 명시한 핵심 권장 사항은 다음과 같다.

• 의미 있는 단어를 쓴다. index.php?topic=42처럼 의미 없는 숫자·기호 조합 대신, 사람이 읽고 바로 이해할 수 있는 단어를 URL에 담으라고 권한다.
• 단어 구분은 하이픈(-)으로 한다. 구글은 "단어를 구분할 때는 언더스코어(_) 대신 하이픈(-)을 쓰라"고 명확히 권고한다. 언더스코어는 프로그래밍에서 전통적으로 "붙어 있어야 하는 하나의 개념"을 뜻하는 기호라, 검색엔진이 단어를 나누어 인식하는 데 하이픈보다 불리하다.
• 불필요한 파라미터를 정리한다. 페이지 내용에 영향을 주지 않는 세션 ID, 추적 코드 같은 파라미터는 가능한 한 없애거나 최소화하라고 안내한다.
• 비ASCII 문자는 퍼센트 인코딩한다. 한글 등 비영문 문자를 URL에 직접 쓸 경우 브라우저·서버가 다르게 처리할 수 있으므로 표준 인코딩 방식을 따르는 것이 안전하다.
• 대소문자를 구분한다는 점을 인지한다. 구글은 URL을 대소문자로 구분되는 것으로 처리하므로, 같은 페이지인데 대문자·소문자가 섞여 다른 URL로 남으면 중복 콘텐츠 문제가 생길 수 있다.

여기서 중요한 사실을 하나 짚어야 한다. 구글은 "폴더는 몇 단계까지", "글자 수는 몇 자까지"처럼 딱 떨어지는 숫자 기준을 공식적으로 못박지 않는다. 대신 "지나치게 복잡하거나 파라미터가 과도한 URL을 피하라"는 원칙을 제시한다. 그러니 "무조건 몇 단계 이하"라는 말을 절대 규칙처럼 받아들이기보다, 짧고 명확할수록 유리하다는 방향성으로 이해하는 것이 정확하다.

이 원칙을 실제 업종에 적용해 나쁜 예와 좋은 예를 비교해 보자.

업종	나쁜 예	좋은 예
홈페이지 제작사 서비스	iruweb.com/service?id=3&cat=2	iruweb.com/services/seo-website
카페 메뉴 소개	cafe.com/page.php?p=17	cafe.com/menu/summer-drinks
쇼핑몰 상품	mall.com/item_view/A_00231	mall.com/products/linen-shirt
블로그 글	blog.com/2026/07/26/post123	blog.com/blog/website-structure-for-seo
지역 서비스업	dental.com/index?menu=2	dental.com/implant

나쁜 예의 공통점은 사람이 주소만 보고는 그 페이지가 무엇인지 전혀 짐작할 수 없다는 것이다. 좋은 예는 주소 자체가 이미 "이 페이지가 무엇에 관한 것인지" 말해 준다. URL은 검색 결과에서도 그대로 보이는, 또 하나의 작은 광고 문구라는 점을 기억하자.

좋은 URL의 기준은 하나다. "이 주소만 보고도 사람이 내용을 짐작할 수 있는가?" 그렇다면 좋은 URL이다.

URL을 지을 때 자주 나오는 실무 질문도 함께 정리해 둔다. 조사나 어미 같은 한글 문법 요소는 URL에 넣지 않는다. "홈페이지-제작을-잘하는-법"처럼 조사를 그대로 넣으면 부자연스럽고 길어지기만 한다. "홈페이지-제작-잘하는-법"처럼 핵심 명사와 동사 위주로 간결하게 줄이는 것이 좋다. 또한 너무 짧은 한 단어짜리 URL(/service)은 카테고리가 하나뿐일 때는 괜찮지만, 여러 서비스를 다룬다면 각 서비스를 구분할 수 있을 만큼 구체적인 단어를 추가해야 한다.

카테고리형 사이트라면 URL 안에 상위 구조를 자연스럽게 반영하는 것도 좋은 방법이다. 예를 들어 iruweb.com/blog/website-structure-for-seo처럼 콘텐츠 종류(블로그)를 경로에 담으면, 사람도 구글도 그 페이지의 위치와 성격을 한눈에 파악한다.

다만 지나치게 깊은 경로(/category/subcategory/subsubcategory/product-name처럼 폴더가 여러 겹인 구조)는 관리도 어렵고, 사람이 주소를 눈으로 읽기도 부담스러워진다. 의미 있는 위계는 살리되, 폴더 단계는 필요한 만큼만 쓰는 것이 현실적인 균형점이다.

필터·정렬 페이지에서 URL이 무한정 늘어나는 문제는 어떻게 막나?

쇼핑몰이나 부동산 매물 사이트처럼 필터(가격순, 색상별, 지역별)와 정렬 기능이 있는 사이트는 URL 구조에서 특히 조심해야 할 함정이 하나 있다. 필터를 조합할 때마다 ?color=red&size=m&sort=price처럼 파라미터가 새로 붙은 URL이 계속 생겨나고, 이 조합이 수천 개로 불어나면 사실상 내용이 거의 같은 페이지가 URL만 다르게 무한정 늘어나는 문제가 생긴다.

이를 방치하면 두 가지 손해가 발생한다. 첫째, 구글이 비슷한 페이지를 반복해서 크롤링하느라 정작 중요한 페이지를 늦게 발견할 수 있다. 둘째, 어떤 버전의 URL이 "진짜 대표 페이지"인지 구글이 혼란스러워하며 순위가 여러 URL로 분산될 수 있다.

해결 방법은 어렵지 않다. 정렬·필터처럼 내용의 본질을 바꾸지 않는 파라미터가 붙은 URL에는 정규 URL(canonical, 대표 주소로 지정하는 표시)을 원래 카테고리 페이지로 지정해 두면 된다. 이렇게 하면 "이 페이지들은 결국 다 같은 대표 페이지의 변형"이라는 것을 구글에게 명확히 알려줄 수 있다.

구분	나쁜 예	좋은 예
필터 URL 처리	모든 필터 조합이 색인 대상으로 방치	대표 카테고리 URL로 정규 URL(canonical) 지정
정렬 URL 처리	?sort=price_asc 등도 각각 별도 페이지처럼 취급	정렬은 화면 기능으로만 두고 URL 색인은 최소화

카테고리와 메뉴, 몇 단계로 나누는 게 좋을까?

정답은 "손님이 원하는 페이지까지 최대한 적은 클릭으로 닿을 수 있는 깊이"다. 흔히 이야기하는 "3번 클릭 규칙"은 구글의 공식 알고리즘 규정은 아니지만, 사용자 경험과 크롤링 효율을 함께 챙기는 현실적인 기준으로 업계에서 널리 쓰인다.

카테고리 구조는 크게 두 가지 방식으로 나뉜다.

평면 구조(플랫 구조)는 홈 아래 카테고리를 많이 늘어놓지 않고, 대부분의 페이지가 홈에서 한두 번의 클릭으로 닿게 만드는 방식이다. 페이지 수가 적은 소규모 사이트(개인 사업자, 소형 서비스업)에 잘 맞는다.

계층 구조는 대분류 아래 중분류, 그 아래 소분류를 두는 방식이다. 상품이나 페이지 수가 많은 쇼핑몰, 정보량이 많은 미디어·블로그 사이트에 적합하다.

어느 쪽이든 지켜야 할 원칙은 같다. 각 단계의 카테고리 수가 너무 많지도, 너무 적지도 않아야 한다. 한 카테고리 안에 하위 항목이 수십 개씩 쏟아지면 손님은 무엇을 눌러야 할지 몰라 이탈한다. 반대로 카테고리를 지나치게 잘게 쪼개면, 각 페이지에 담을 내용이 부족해지고 클릭 단계만 늘어난다.

업종별로 적정한 깊이를 예시로 정리하면 다음과 같다.

사이트 유형	권장 구조	예시
소규모 서비스업(치과, 카페, 학원)	홈 → 서비스/메뉴 → 상세 (2단계)	홈 → 진료 안내 → 임플란트
홈페이지 제작사	홈 → 서비스 → 세부 서비스 (2–3단계)	홈 → 서비스 → SEO 홈페이지 제작
쇼핑몰(상품 수 많음)	홈 → 대분류 → 소분류 → 상품 (3–4단계)	홈 → 여성의류 → 셔츠 → 린넨 셔츠
블로그/미디어	홈 → 블로그 → 카테고리 → 글 (3단계)	홈 → 블로그 → 홈페이지 제작 → 이 글

여기서 중요한 것은 "단계 수 자체보다 각 단계에서 다음 선택지가 명확한가"이다. 예를 들어 쇼핑몰에서 "여성의류"를 눌렀는데 그 안에 상품 200개가 아무 분류 없이 쏟아진다면, 4단계 구조라도 실제로는 2단계나 다름없이 혼란스럽다.

카테고리 단계 수를 줄이는 것보다 중요한 것은, 각 갈림길에서 손님이 "다음에 뭘 눌러야 할지" 헷갈리지 않는 것이다.

메뉴(내비게이션) 설계에서 자주 하는 실수도 짚고 넘어가자. 메뉴 항목은 7개 안팎을 넘지 않는 것이 좋다. 사람이 한 번에 인지하고 비교할 수 있는 선택지의 수에는 한계가 있기 때문이다. 메뉴에 모든 하위 페이지를 다 늘어놓으려 하지 말고, 대표 카테고리만 상단 메뉴에 두고 나머지는 하위 페이지나 사이트맵, 내부 링크로 연결하는 편이 낫다.

허브 페이지와 토픽 클러스터는 어떻게 짜야 하나?

콘텐츠가 늘어나는 사이트일수록, 큰 주제 하나를 다루는 "허브 페이지" 하나와 그 아래 세부 주제를 다루는 여러 "세부 글"을 묶는 구조가 유리하다. 이 방식을 흔히 토픽 클러스터(topic cluster)라고 부른다.

허브 페이지는 큰 주제를 전체적으로 조망하며 각 세부 주제로 안내하는 역할을 한다. 예를 들어 "홈페이지 제작"이라는 큰 주제의 허브 페이지가 있다면, 그 아래 "홈페이지 제작 비용", "홈페이지 제작 기간", "홈페이지 제작 절차"처럼 세부 주제를 다루는 글들이 허브 페이지와 서로 링크로 연결된다.

이 구조가 유리한 이유는 세 가지다. 첫째, 구글이 이 주제 전체를 다루는 사이트라는 것을 명확히 인식한다. 세부 글이 흩어져 있을 때보다, 허브를 중심으로 묶여 있을 때 "이 사이트는 이 분야에 전문성이 있다"는 신호가 더 뚜렷해진다. 둘째, 방문자가 관련 정보를 계속 이어서 읽게 된다. 허브에서 세부 글로, 세부 글에서 다시 허브나 다른 세부 글로 이동하며 체류시간이 늘어난다. 셋째, 새 세부 글을 추가하기 쉽다. 이미 짜인 틀 안에 링크만 추가하면 되므로, 콘텐츠가 늘어나도 구조가 무너지지 않는다.

이루웹 블로그도 이 원리를 그대로 따른다. 이 글(홈페이지 구조 설계)과 내부 링크 전략, 사이트맵 글은 모두 "검색엔진에 잘 잡히는 사이트 만들기"라는 큰 주제 아래 묶인 세부 글들이며, 서로 링크로 연결돼 하나의 클러스터를 이룬다.

토픽 클러스터를 짤 때 실전 순서는 다음과 같다.

1. 손님이 가장 궁금해하는 큰 주제 3–5개를 먼저 정한다. 홈페이지 제작사라면 "홈페이지 제작", "SEO", "AI 검색 대응" 같은 큰 축이 될 수 있다.
2. 각 주제마다 허브 페이지(또는 카테고리 페이지) 하나를 만든다. 이 페이지는 주제를 전체적으로 요약하고 세부 글로 안내하는 역할을 한다.
3. 세부 글을 채워 넣으며 허브와 서로 링크한다. 세부 글에서 허브로, 허브에서 세부 글로 양방향 링크를 건다.
4. 세부 글끼리도 관련성이 있으면 서로 링크한다. 클러스터 안의 글들이 그물처럼 촘촘히 얽힐수록 구조가 단단해진다.

허브 페이지 없이 세부 글만 계속 쌓으면, 개별 글은 잘 써도 "이 사이트가 전체적으로 무엇을 다루는 곳인지"가 흐려진다. 허브는 낱개의 글들을 하나의 전문 분야로 묶어 주는 이음새다.

토픽 클러스터를 짤 때 흔히 하는 오해가 하나 있다. "허브 페이지 하나만 잘 만들면 세부 글은 대충 채워도 된다"는 생각이다. 실제로는 그 반대에 가깝다. 허브 페이지는 안내 역할일 뿐, 실제 검색 유입과 신뢰를 만드는 것은 세부 글 하나하나의 완성도다. 허브는 세부 글들을 하나로 묶어 더 큰 의미를 만드는 장치이지, 세부 글의 부실함을 가려 주는 장치가 아니다.

내부 링크는 구조를 어떻게 완성하는가?

정보구조와 URL을 아무리 잘 짜도, 페이지끼리 링크로 잇지 않으면 그 구조는 종이 위의 설계도로만 남는다. 내부 링크는 설계도를 실제로 작동하는 건물로 바꾸는 배관과 전선 같은 존재다.

내부 링크가 하는 역할은 크게 두 가지다. 첫째, 구글이 사이트 안의 페이지를 발견하고 이동하는 통로가 된다. 아무리 사이트맵에 등록해도, 본문이나 메뉴에서 실제로 연결되지 않은 페이지는 "고아 페이지"가 되어 발견이 늦어진다. 둘째, 관련된 페이지끼리 맥락을 만들어 준다. 이 글에서 다루는 정보구조 이야기가 실제 내부 링크 전략과 자연스럽게 이어지는 것처럼, 관련 주제를 서로 이어 주면 방문자도 구글도 사이트 전체의 맥락을 더 잘 이해한다.

정보구조와 내부 링크는 사실 한 몸이다. 카테고리 페이지는 그 하위 글들로 링크를 걸어야 하고, 개별 글은 다시 상위 카테고리와 관련 글로 링크를 걸어야 한다. 이 왕복 연결이 촘촘할수록 사이트는 "서로 잘 짜인 그물"처럼 작동한다.

실전에서 자주 놓치는 연결 지점을 정리하면 다음과 같다.

• 새 페이지를 만들면 즉시 관련 페이지에서 링크를 건다. 발행만 해 두고 어디서도 연결하지 않으면 고아 페이지가 된다.
• 카테고리(목록) 페이지에서 하위 글로 링크한다. 목록 페이지 자체도 검색에 잡히지만, 그 안의 링크가 하위 글의 발견 통로가 된다.
• 개별 글 안에서 관련 서비스 페이지로 자연스럽게 연결한다. 정보를 읽은 방문자가 다음 행동(상담, 서비스 확인)으로 자연스럽게 넘어가도록 돕는다.
• 브레드크럼(탐색경로)을 페이지 상단에 넣는다. "홈 > 블로그 > 홈페이지 제작 > 이 글"처럼 현재 위치를 보여주면, 방문자는 언제든 상위 카테고리로 돌아갈 수 있고 구글도 위계를 명확히 파악한다.

이 사이트 역시 블로그 글마다 브레드크럼 구조화 데이터를 자동으로 붙이고 있으며, 이는 JSON-LD 스키마 마크업으로 검색엔진에 위치 정보를 전달하는 방식이다. 내부 링크를 어떻게 배치해야 순위와 체류시간에 실질적으로 도움이 되는지는 앞서 다룬 내부 링크 전략 글에서 더 자세한 기준과 앵커텍스트 작성법을 참고하면 좋다.

AI 검색은 홈페이지 구조를 어떻게 "읽는가"?

결론부터 말하면, AI 검색 도구는 화려한 디자인이 아니라 명확한 텍스트 구조와 위계를 재료로 삼아 페이지를 요약하고 인용한다. 그래서 구조 설계는 이제 구글의 전통적인 검색뿐 아니라, AI 오버뷰나 챗봇형 검색에도 그대로 영향을 미친다.

다만 여기서 반드시 팩트체크가 필요한 부분이 있다. 한동안 업계에는 "AI가 읽기 쉽도록 콘텐츠를 짧은 조각(청킹, chunking)으로 잘게 쪼개야 한다"는 주장이 퍼졌었다. 그러나 2026년 1월 8일, 구글의 검색 리에종(Search Liaison)인 대니 설리번(Danny Sullivan)은 팟캐스트 "Search Off the Record"를 통해 이 방식을 명확히 경고했다.

설리번은 창작자들이 검색·AI 시스템만을 겨냥해 콘텐츠를 잘게 쪼개는 행위에 대해 "그렇게 하는 것을 원하지 않는다. 정말로 원하지 않는다"고 말했다. 이어 "사람들이 검색을 위해 특별히 무언가를 짜내야 한다고 생각하지 않길 바란다"며, 검색 시스템은 계속 바뀌기 때문에 특정 알고리즘만 노린 요령은 오래가지 못한다고 설명했다. 결국 구글이 강조한 것은 "사람을 위해 쓴 콘텐츠를 보상하는 방향으로 시스템이 계속 개선된다"는 원칙이었다.

이 발언이 뜻하는 바를 정확히 짚어야 한다. "섹션을 논리적으로 나눠 가독성을 높이는 것"과 "AI를 속이려고 억지로 문장을 토막 내는 것"은 전혀 다른 이야기다. 전자는 사람에게도 좋은 글쓰기 원칙이고, 후자는 구글이 명확히 경계한 얕은 수다.

좋은 구조는 원래 사람을 위한 것이었다. AI가 그 구조를 좋아하는 것은, AI 역시 결국 "사람이 이해하기 쉬운 글"을 학습해서 만들어졌기 때문이다.

그렇다면 무엇을 해야 할까. 구글이 일관되게 강조하는 방향은 다음과 같다.

• 질문형 제목(H2·H3) + 바로 아래 직접적인 답변 구조로 쓴다. 사람이 훑어봐도, AI가 발췌해도 의미가 온전히 전달된다.
• 명확한 정의 문장을 앞세운다. "OO란 무엇이다"처럼 짧고 단정적인 문장이 인용되기 쉽다.
• 논리적인 헤딩 계층(H1은 제외, H2 → H3)을 지킨다. 헤딩 계층이 뒤죽박죽이면 AI도 어디가 핵심인지 헷갈린다.
• 구체적인 수치와 사실을 담는다. 막연한 형용사보다 "약 25–30자", "2026년 1월"처럼 구체적인 정보가 인용 가치를 높인다.

이 원칙들의 공통점은 결국 "좋은 정보구조와 좋은 글쓰기가 곧 AI 대응"이라는 것이다. AI만을 위한 별도의 요령을 찾아다니기보다, 이 글에서 다룬 정보구조·URL·내부 링크 원칙을 충실히 지키는 것 자체가 최선의 AI 검색 대응이다.

혼동하기 쉬운 두 가지를 표로 나눠 정리하면 감이 더 뚜렷해진다.

방식	설명	구글의 입장
논리적 섹션 구분	질문형 소제목 아래 완결된 답을 배치, 문단을 짧게 유지	권장 — 사람과 AI 모두에게 좋은 글쓰기
인위적 문장 토막 내기	AI가 발췌하기 쉽도록 의미 없이 문장을 잘게 쪼개 나열	경고 — 시스템을 겨냥한 얕은 수로 판단
명확한 정의문 배치	"OO란 무엇이다"처럼 핵심을 앞세운 문장	권장 — 인용 가치를 높이는 자연스러운 방식
키워드만 나열한 리스트	문맥 없이 키워드만 콤마로 나열	비권장 — 사람에게도 의미 전달이 안 됨

이 표에서 보듯, 구글이 긍정적으로 보는 방식과 부정적으로 보는 방식을 가르는 기준은 "AI를 겨냥했는가, 사람을 위해 썼는가"이지 "짧은가, 긴가"가 아니다. 문단을 짧게 쓰는 것과 문장을 무의미하게 토막 내는 것은 전혀 다른 이야기라는 점을 다시 한번 강조한다.

엔티티 인식이란 무엇이고 구조에 어떻게 반영하나?

엔티티(entity)란 사람·장소·서비스·개념처럼 검색엔진이 하나의 "구체적인 대상"으로 인식하는 단위를 말한다. 예를 들어 "이루웹"이라는 회사 이름, "임플란트"라는 시술, "성수동"이라는 지역은 각각 하나의 엔티티로 취급될 수 있다.

검색엔진과 AI는 단순히 키워드 일치를 넘어, 이 엔티티들이 서로 어떤 관계인지를 이해하려 한다. "이루웹은 홈페이지 제작 서비스를 제공하는 회사다"라는 문장은 "이루웹(엔티티1) - 제공한다(관계) - 홈페이지 제작 서비스(엔티티2)"라는 구조로 해석될 수 있다는 뜻이다.

이 관계를 검색엔진에게 명시적으로 알려주는 방법이 구조화 데이터(JSON-LD)다. 예를 들어 이 사이트는 회사 정보에 Organization 스키마를, 서비스 페이지에 Service 스키마를, 블로그 글에 Article과 BreadcrumbList 스키마를 붙인다. 이렇게 하면 "이 페이지가 어떤 조직의, 어떤 종류의 콘텐츠인지"를 검색엔진이 추측이 아니라 명확한 데이터로 읽을 수 있다.

구조화 데이터를 넣는다고 순위가 즉시 오르는 마법은 아니다. 다만 업계에서 폭넓게 권장되는 이유는 분명하다. 검색 결과에서 별점, FAQ, 브레드크럼 같은 리치 결과(더 풍부한 검색 노출 형태)로 이어질 가능성을 높이고, AI가 페이지의 성격을 오해 없이 파악하도록 돕기 때문이다. JSON-LD 스키마 마크업을 아직 안 넣었다면, 정보구조를 다 짠 뒤 마지막 단계에서 반드시 챙길 항목이다.

엔티티 인식을 구조 설계에 반영하는 실전 방법은 다음과 같다.

• 페이지마다 "이 페이지가 무엇에 관한 것인지"를 헤딩과 첫 문단에서 명확히 밝힌다. 애매하게 돌려 말하지 않는다.
• 같은 대상을 부르는 이름을 사이트 전체에서 일관되게 쓴다. 어떤 곳에서는 "이루웹", 어떤 곳에서는 "저희 회사"라고 섞어 쓰면 검색엔진이 같은 엔티티로 묶어 이해하기 어려워진다.
• 관련 페이지끼리 링크로 관계를 보여준다. 서비스 페이지와 그 서비스를 설명하는 블로그 글을 서로 링크하면, "이 둘은 같은 주제를 다룬다"는 신호가 된다.
• 구조화 데이터로 관계를 명시한다. 회사·서비스·글·후기를 각각의 스키마 타입으로 표시하고, 서로 참조하도록 연결한다.

정리하면, 엔티티 인식이라는 다소 어려운 개념도 결국 이 글 전체가 강조하는 것과 같은 결론으로 이어진다. 명확한 정보구조 + 일관된 표현 + 촘촘한 내부 링크 + 정확한 구조화 데이터, 이 네 가지가 갖춰지면 검색엔진도 AI도 사이트를 헷갈리지 않고 이해한다.

실제 예로 풀어 보면 더 와닿는다. 이루웹이라는 회사(엔티티)는 "SEO 최적화 홈페이지 제작"이라는 서비스(엔티티)를 제공하고, 그 서비스를 설명하는 블로그 글(엔티티)이 여러 편 존재하며, 실제 이용 고객의 후기(엔티티)가 그 신뢰를 뒷받침한다. 이 네 종류의 엔티티가 구조화 데이터로 각각 표시되고 서로 링크로 연결되어 있으면, 검색엔진은 "이 회사가 실제로 이 서비스를 제공하며, 관련 정보와 후기까지 갖추고 있다"는 그림을 어렵지 않게 그릴 수 있다.

반대로 이런 표시 없이 텍스트만 나열되어 있으면, 검색엔진은 더 많은 추론을 거쳐야 같은 결론에 도달한다. 추론 과정이 길어질수록 오해나 누락의 여지도 커진다. 구조화 데이터는 이 추론 과정을 줄여 주는 지름길이라고 이해하면 된다.

업종별로 홈페이지 구조는 어떻게 다르게 짜야 하나?

같은 원칙이라도 업종에 따라 실제 적용 방식은 달라진다. 몇 가지 대표 업종으로 살펴본다.

서비스업(치과, 미용실, 학원 등)

한 줄 요약: 서비스/진료 항목별로 개별 페이지를 만들고, 홈에서 한 번의 클릭으로 각 서비스에 닿게 한다.

구분	나쁜 예	좋은 예
구조	모든 진료 항목을 "진료안내"라는 페이지 하나에 뭉쳐서 나열	"임플란트", "충치치료", "스케일링" 각각 개별 페이지
URL	dental.com/service (모든 항목이 이 한 페이지에)	dental.com/implant, dental.com/scaling
결과	"임플란트"를 검색해도 이 페이지가 뜨기 어려움	각 검색어에 맞는 페이지가 개별적으로 노출 가능

진료 항목을 한 페이지에 뭉치면 관리는 편해 보이지만, 검색 노출 기회 자체가 줄어든다. "임플란트"를 검색하는 사람과 "충치치료"를 검색하는 사람은 서로 다른 의도를 가지고 있으므로, 각각에 맞는 개별 페이지가 있어야 정확히 대응할 수 있다.

쇼핑몰

한 줄 요약: 대분류-소분류-상품의 3단계 구조를 지키고, 상품이 늘어나도 카테고리 체계가 무너지지 않게 미리 설계한다.

쇼핑몰은 페이지 수가 수백, 수천 개에 이르기 쉬워 구조 설계의 효과가 가장 크게 드러나는 업종이다. 카테고리를 나중에 손대려면 이미 등록된 수백 개 상품의 URL과 링크를 전부 다시 잡아야 하므로, 처음부터 확장을 고려한 카테고리 체계를 짜야 한다.

쇼핑몰의 카테고리 구조는 한번 정해지면 되돌리기 가장 어려운 결정 중 하나다. 상품이 10개일 때 미리 100개, 1,000개가 되었을 때를 그려보고 설계하는 것이 안전하다.

홈페이지 제작사·전문 서비스업

한 줄 요약: "우리가 무엇을 하는 회사인지"를 서비스 카테고리로 명확히 나누고, 각 서비스와 관련 블로그 글을 서로 링크한다.

이 유형은 서비스 소개, 포트폴리오·후기, 블로그(인사이트), 회사 소개, 문의라는 다섯 축으로 정보구조를 짜는 경우가 많다. 서비스 페이지는 "무엇을 제공하는지", 블로그는 "왜 우리를 신뢰해야 하는지"를 보여주는 역할로 서로 나뉘고, 이 둘을 내부 링크로 이으면 방문자가 자연스럽게 상담까지 이어진다.

지역 기반 소상공인

한 줄 요약: 지역명을 카테고리나 URL에 자연스럽게 반영해, 동네 검색에서 놓치지 않는다.

카페, 미용실, 필라테스 학원처럼 지역 손님이 중요한 업종은 "성수동 카페", "망원동 필라테스"처럼 지역명이 실제 검색어에 들어간다. 정보구조 단계에서부터 지역 정보를 페이지 제목과 URL에 자연스럽게 녹여 두면, 나중에 콘텐츠를 추가할 때도 일관성이 유지된다.

블로그·미디어형 사이트

한 줄 요약: 주제별 카테고리(토픽 클러스터)를 먼저 정하고, 그 아래 개별 글을 채워 넣는 방식으로 설계한다.

글이 쌓일수록 카테고리 없이 발행일 순서로만 나열하면 정보가 파묻힌다. 처음부터 몇 개의 큰 주제(카테고리)를 정하고, 그 아래 세부 글들을 채워 넣는 토픽 클러스터 방식으로 설계하면, 나중에 글이 수백 편으로 늘어나도 구조가 흔들리지 않는다.

부동산 중개

한 줄 요약: 매물 종류(아파트·오피스텔·상가)와 거래 형태(매매·전세·월세), 지역을 조합한 구조로 짜서 세부 검색어에 정확히 대응한다.

부동산은 "판교 오피스텔 전세"처럼 지역·매물종류·거래형태가 함께 검색되는 경우가 많다. 이 세 가지 축을 카테고리 구조에 미리 반영해 두면, 매물이 늘어나도 realestate.com/pangyo/officetel/jeonse처럼 일관된 URL 체계를 유지할 수 있다. 반대로 이 축을 정하지 않고 매물을 등록일 순서로만 쌓으면, 특정 조합을 찾는 검색어에 정확히 대응하는 페이지가 없어 기회를 놓친다.

온라인 강의·교육 플랫폼

한 줄 요약: 과목-난이도-개별 강의의 위계로 나누고, 수강 전 페이지와 수강 중 페이지의 URL 성격을 분리한다.

교육 플랫폼은 검색엔진에 노출돼야 하는 "강의 소개 페이지"와, 로그인 후에만 보이는 "실제 학습 페이지"가 섞이기 쉽다. 소개 페이지는 과목(예: 프로그래밍) - 세부 분야(예: 웹개발) - 개별 강의 순서로 누구나 검색으로 들어올 수 있게 공개된 구조로 짜고, 학습 페이지는 별도 경로로 분리해 검색 노출과 실제 학습 공간의 역할을 명확히 나누는 것이 좋다.

홈페이지 구조 설계에서 흔히 저지르는 실수는 무엇인가?

첫 번째, 메뉴를 회사 조직도 순서로 짜는 것. "회사소개 - 연혁 - 조직도 - 사업부문 - 문의"처럼 회사 내부 기준으로 메뉴를 짜면, 정작 손님이 궁금한 "무엇을 얼마에 살 수 있는지"가 뒤로 밀린다. 메뉴는 손님의 궁금증 순서로 짜야 한다.

두 번째, 카테고리를 "나중에 정리하지"라며 미루는 것. 페이지가 몇 개 없을 때는 대충 넣어도 티가 안 나지만, 백 개, 천 개로 늘어난 뒤에 구조를 바꾸려면 URL이 바뀌고, 그동안 쌓인 검색 순위와 백링크까지 흔들릴 수 있다. 처음부터 확장 가능한 구조로 짜는 것이 나중에 드는 비용을 크게 줄인다.

세 번째, 하나의 페이지에 너무 많은 주제를 욱여넣는 것. "회사소개"라는 페이지 하나에 연혁, 서비스, 팀 소개, 채용 정보까지 다 넣으면, 이 페이지는 어떤 검색어에도 정확히 맞아떨어지지 않는 애매한 페이지가 된다. 주제가 다르면 페이지도 나누는 것이 원칙이다.

네 번째, 새 페이지를 링크 없이 방치하는 것. 아무리 좋은 콘텐츠를 만들어도 어디서도 연결되지 않으면 고아 페이지가 되어 발견이 늦어진다. 발행과 동시에 관련 페이지에서 링크를 거는 습관을 들여야 한다.

다섯 번째, URL을 CMS(콘텐츠관리시스템)의 기본값 그대로 두는 것. 워드프레스나 쇼핑몰 솔루션의 기본 설정을 그대로 쓰면 ?p=123, /product_view/A00231처럼 사람이 읽을 수 없는 주소가 그대로 남는다. 대부분의 플랫폼은 URL 형식을 바꾸는 설정을 제공하니, 제작 초기에 반드시 점검해야 한다.

여섯 번째, 구조 개편 시 이전 URL을 그냥 버리는 것. 카테고리를 바꾸거나 URL 체계를 새로 짤 때, 예전 주소로 들어오는 방문자나 검색엔진을 위한 리디렉션(다른 주소로 자동 이동시키는 설정) 없이 그냥 페이지를 없애면, 그동안 쌓인 검색 순위가 한순간에 사라질 수 있다. 구조를 바꿀 때는 예전 URL에서 새 URL로 리디렉션을 반드시 설정해야 한다.

일곱 번째, 카테고리 이름을 사업자 용어로 짓는 것. "솔루션", "토탈 케어", "프리미엄 패키지"처럼 회사 내부에서만 통하는 이름을 카테고리에 그대로 쓰면, 손님이 실제로 검색하는 단어와 어긋난다. 카테고리 이름도 키워드 리서치를 거쳐 손님의 언어로 짓는 것이 원칙이다.

여덟 번째, 구조 설계를 문서화하지 않는 것. 담당자 머릿속에만 구조가 있고 문서로 남기지 않으면, 담당자가 바뀌거나 시간이 지난 뒤 왜 이렇게 나눴는지 아무도 설명하지 못하게 된다. 카테고리 트리와 URL 규칙은 짧더라도 문서로 남겨, 다음에 페이지를 추가할 사람이 같은 원칙을 따를 수 있게 해야 한다.

사이트맵과 robots.txt는 구조와 어떤 관계인가?

사이트맵과 robots.txt는 정보구조를 대체하지 않는다. 이미 짜인 구조를 검색엔진에게 "설명서"처럼 전달하는 역할을 한다. 둘을 혼동하면 "사이트맵만 잘 만들면 구조가 부실해도 괜찮다"는 오해로 이어지기 쉬운데, 이는 사실이 아니다.

사이트맵(sitemap.xml)은 사이트 안의 페이지 목록을 구글에게 알려주는 파일이다. "이런 페이지들이 있으니 확인해 달라"는 초대장에 가깝다. 다만 사이트맵에 올라 있다고 해서 그 페이지가 얼마나 중요한지, 다른 페이지와 어떤 관계인지까지 전달되지는 않는다. 그 역할은 여전히 메뉴와 내부 링크, 즉 정보구조의 몫이다.

robots.txt는 반대로 "이 영역은 크롤링하지 않아도 된다"는 안내문이다. 관리자 페이지, 검색 결과 페이지, 장바구니처럼 검색에 노출될 필요가 없는 영역을 크롤링 대상에서 제외할 때 쓴다. 정보구조를 잘 짜 두면 애초에 이런 예외 영역이 명확히 구분되어 robots.txt 설정도 훨씬 간단해진다.

정리하면 이렇다.

요소	역할	정보구조와의 관계
정보구조(IA)	콘텐츠를 묶고 위계를 정하는 설계도	근본 뼈대
URL·메뉴·내부 링크	설계도를 실제로 구현하는 뼈와 근육	구조의 실행
사이트맵	구글에게 페이지 목록을 알려주는 안내문	구조를 요약해 전달하는 보조 수단
robots.txt	크롤링하지 않아도 되는 영역을 알려주는 안내문	구조에서 제외할 영역을 표시

사이트맵과 robots.txt를 아무리 정교하게 만들어도, 정작 메뉴와 내부 링크로 이어지지 않은 부실한 구조를 대신 고쳐 주지는 못한다. 순서는 언제나 "구조를 먼저 바로잡고, 사이트맵·robots.txt로 이를 전달"하는 것이다.

홈페이지 제작을 의뢰할 때 구조를 어떻게 요구해야 하나?

홈페이지 제작을 맡길 때는 시안(디자인 이미지)을 보기 전에, 반드시 정보구조 문서(사이트맵 트리, 메뉴 구조도)를 먼저 요청해야 한다. 시안은 화려해 보여도 구조가 부실하면 오래가지 못하는 사이트가 된다.

제작사에 요청할 때 확인하면 좋은 항목은 다음과 같다.

• 전체 페이지 목록과 위계도를 문서로 받는다. 트리 형태로 홈-카테고리-하위 페이지가 정리된 문서가 있어야, 나중에 페이지를 추가할 때도 같은 틀을 유지할 수 있다.
• URL 체계에 대한 설명을 요청한다. 페이지마다 어떤 규칙으로 주소가 정해지는지 사전에 확인하면, 나중에 ?id= 같은 의미 없는 주소가 나오는 것을 미리 막을 수 있다.
• 블로그·콘텐츠 영역이 있다면 카테고리 확장 계획을 함께 논의한다. 글이 100편, 300편으로 늘어났을 때도 지금의 구조가 버틸 수 있는지 미리 점검한다.
• 구조화 데이터(JSON-LD) 적용 범위를 확인한다. 회사 정보, 서비스, 블로그 글, 후기 각각에 어떤 스키마가 들어가는지 사전에 확인하는 것이 좋다.

시안을 먼저 보여 달라고 재촉하기보다, "우리 사이트의 정보구조도부터 보여 달라"고 요청하는 순간, 그 제작사가 SEO를 얼마나 진지하게 다루는지가 드러난다.

이런 항목들은 제작이 다 끝난 뒤에 점검하면 이미 늦은 경우가 많다. 계약 전, 늦어도 기획 단계에서 반드시 짚고 넘어가야 나중에 구조를 다시 갈아엎는 비용을 피할 수 있다.

지금 바로 우리 사이트의 구조를 점검하는 법

이론을 다 읽었어도 막상 "우리 사이트는 어떤 상태인지" 감이 안 잡힐 수 있다. 아래 순서대로 점검하면 큰 그림을 빠르게 파악할 수 있다.

1. 사이트맵을 열어 전체 페이지 목록을 확인한다. 사이트맵(sitemap.xml)은 사이트에 어떤 페이지가 있는지 보여주는 목록이다. 이 목록만 봐도 카테고리 체계가 잡혀 있는지, 페이지가 뒤죽박죽인지 드러난다.
2. 홈에서 몇 번의 클릭으로 각 페이지에 닿는지 직접 눌러 본다. 중요한 페이지인데 서너 번을 눌러야 닿는다면 메뉴나 내부 링크 구조를 다시 봐야 한다.
3. URL 목록을 쭉 훑어보며 의미 없는 숫자·파라미터가 있는지 확인한다. ?id=, ?p= 같은 패턴이 반복된다면 URL 구조를 정리할 시점이다.
4. 각 페이지가 어떤 페이지에서 링크를 받는지 확인한다. 아무 곳에서도 링크되지 않은 페이지(고아 페이지)가 있다면 관련 페이지에서 링크를 추가한다.
5. 주요 페이지의 헤딩 계층을 확인한다. H1은 페이지당 하나, 그 아래 H2·H3가 논리적으로 이어지는지 살핀다.
6. 구글 서치 콘솔의 페이지 색인 보고서를 확인한다. "검색결과에 등록됨"과 "등록되지 않음" 페이지를 비교해 보면, 구조상 발견이 안 되고 있는 페이지가 있는지 드러난다.
7. 경쟁사나 같은 업종의 잘된 사이트 구조를 참고한다. 그대로 베끼라는 뜻이 아니라, "이 업종에서는 보통 몇 단계로, 어떤 카테고리로 정보를 나누는지" 감을 잡는 참고 자료로 활용한다.

이 일곱 단계를 한 번에 다 하려고 부담 갖지 않아도 된다. 처음에는 1–3번만이라도 확인해 보면, 우리 사이트 구조에서 가장 시급하게 손볼 부분이 무엇인지 대략적인 그림이 잡힌다.

구조 점검은 한 번으로 끝나는 일이 아니다. 페이지가 늘어날 때마다, 특히 새 카테고리를 추가할 때마다 이 단계들을 짧게라도 다시 훑어보는 습관이 사이트를 오래 건강하게 만든다.

자주 묻는 질문

홈페이지 구조는 디자인 전에 정해야 하나요, 함께 정해도 되나요?

디자인보다 먼저, 최소한 기획 단계에서 함께 정해야 한다. 정보구조가 정해져야 메뉴 개수, 카테고리별 콘텐츠 양, 페이지 종류가 나오고, 이 결과에 따라 디자인의 틀(레이아웃)이 달라지기 때문이다.

디자인을 먼저 확정한 뒤 구조를 끼워 맞추면, 콘텐츠가 레이아웃에 억지로 눌려 담기거나 반대로 레이아웃이 텅 비는 경우가 흔하다. 정보구조 → 콘텐츠 초안 → 디자인 순서가 뒤탈이 적다.

이미 운영 중인 사이트의 구조를 바꾸면 순위가 떨어지지 않나요?

제대로 하면 오히려 개선되지만, 잘못하면 순위가 흔들릴 수 있다. 핵심은 URL이 바뀌는 경우 반드시 이전 주소에서 새 주소로 리디렉션을 설정하는 것이다. 리디렉션 없이 페이지를 옮기거나 지우면, 그 페이지가 쌓아온 검색 신호가 끊어질 수 있다.

구조 개편은 가능하면 한꺼번에 크게 바꾸기보다, 영향이 큰 부분부터 단계적으로 진행하고 구글 서치 콘솔에서 색인 상태를 지켜보며 조정하는 편이 안전하다.

카테고리가 몇 개 없는 소규모 사이트도 정보구조가 필요한가요?

필요하다. 페이지가 대여섯 개뿐이라도, 그 몇 개를 어떤 순서와 이름으로 메뉴에 배치하느냐에 따라 손님이 원하는 정보를 얼마나 빨리 찾는지가 달라진다.

오히려 페이지가 적을 때 제대로 된 구조를 잡아 두면, 나중에 페이지가 늘어나도 같은 틀 안에 자연스럽게 추가할 수 있어 훨씬 수월하다.

메뉴에 모든 하위 페이지를 다 넣어야 하나요?

아니다. 메뉴는 대표 카테고리 위주로 간결하게 구성하고, 나머지 하위 페이지는 카테고리 페이지 안의 목록, 본문 내부 링크, 사이트맵을 통해 연결하는 것이 좋다.

메뉴에 너무 많은 항목을 나열하면 오히려 손님이 무엇을 눌러야 할지 몰라 헤매게 되고, 정작 중요한 항목이 눈에 띄지 않게 된다.

AI 검색을 위해 문장을 짧게 쪼개서 써야 하나요?

억지로 쪼갤 필요는 없다. 앞서 다룬 것처럼, 구글은 2026년 1월 콘텐츠를 AI만을 겨냥해 잘게 쪼개는 방식을 명확히 경계한다고 밝혔다.

대신 문단을 짧고 명확하게 쓰고, 질문형 제목 아래 바로 답을 주는 자연스러운 글쓰기 원칙을 지키면 충분하다. 이것은 원래 사람을 위한 좋은 글쓰기 방식이고, 결과적으로 AI에도 유리하게 작용한다.

구조화 데이터(JSON-LD)는 꼭 넣어야 검색에 잡히나요?

구조화 데이터가 없다고 검색에서 아예 배제되지는 않는다. 다만 넣으면 리치 결과 노출 가능성이 높아지고, 검색엔진과 AI가 페이지 성격을 더 명확히 파악하는 데 도움이 된다.

정보구조와 콘텐츠가 잘 갖춰진 상태에서 구조화 데이터까지 더하면, 검색과 AI 양쪽에서 오해 없이 인용될 가능성이 함께 올라간다고 보는 것이 정확하다.

정보구조를 바꾸는 작업, 직접 해도 되나요 전문가가 필요한가요?

소규모 사이트라면 이 글의 원칙만으로도 충분히 직접 시도해 볼 수 있다. 카드 소팅으로 카테고리를 정리하고, 메뉴 항목을 손님 관점에서 다시 배열하는 정도는 별도 도구 없이도 가능하다.

다만 페이지 수가 많거나, URL 체계를 바꾸며 리디렉션까지 함께 설계해야 하는 경우에는 실수로 검색 순위가 흔들릴 위험이 있으므로, 이런 규모의 개편은 경험 있는 담당자나 전문가와 함께 진행하는 것을 권한다.

브레드크럼(탐색경로)은 화면에 꼭 보여야 하나요?

화면에 보이면 방문자와 검색엔진 모두에게 좋지만, 구조화 데이터만으로도 일부 효과를 볼 수 있다. 화면에 보이는 브레드크럼은 방문자가 현재 위치를 한눈에 파악하고 상위 카테고리로 쉽게 돌아가도록 돕는다.

동시에 BreadcrumbList 구조화 데이터를 함께 넣으면, 검색 결과에도 전체 URL 대신 "홈 > 블로그 > 홈페이지 제작" 같은 경로가 표시될 수 있어 클릭률에도 도움이 된다. 가능하다면 화면 표시와 구조화 데이터를 함께 갖추는 것이 가장 안전하다.

모바일과 PC의 홈페이지 구조가 달라도 되나요?

뼈대(정보구조·URL)는 같게 유지하고, 화면에 보여주는 방식(메뉴 형태)만 달라져야 한다. 예를 들어 PC에서는 상단에 전체 메뉴를 펼쳐 보여주고, 모바일에서는 햄버거 메뉴(누르면 펼쳐지는 삼단 줄 아이콘) 안에 같은 메뉴를 담는 식이다.

같은 콘텐츠인데 PC와 모바일이 서로 다른 URL을 쓰는 구조(별도 모바일 도메인 등)는 요즘은 거의 권장되지 않는다. 하나의 URL이 화면 크기에 따라 반응형으로 다르게 보이는 방식이 관리와 검색 노출 양쪽에서 더 안전하다.

다국어 사이트는 구조를 어떻게 나눠야 하나요?

언어별로 URL 경로나 서브도메인을 분리하고, 같은 내용의 다른 언어 페이지끼리 서로 연결 정보를 표시하는 것이 기본 원칙이다. 흔히 쓰는 방식은 example.com/ko/, example.com/en/처럼 언어 코드를 경로에 넣는 방식이다.

이 경우 정보구조 자체(카테고리 이름과 위계)는 언어별로 최대한 동일하게 유지하는 것이 좋다. 언어마다 카테고리 체계가 다르면 관리가 복잡해지고, 검색엔진도 어떤 페이지가 어떤 페이지의 번역본인지 파악하기 어려워진다.

소규모 사이트인데 카테고리를 미리 여러 개 만들어 둬도 되나요?

콘텐츠가 채워질 계획이 있다면 미리 만들어 두어도 괜찮지만, 빈 카테고리를 무작정 늘리는 것은 권하지 않는다. 하위 콘텐츠가 거의 없는 카테고리 페이지가 많으면, 방문자 입장에서는 "내용이 부실한 사이트"라는 인상을 줄 수 있다.

카테고리는 앞으로 채울 콘텐츠 계획에 맞춰 필요한 만큼만 먼저 만들고, 실제로 글이나 페이지가 쌓이는 속도에 맞춰 하나씩 늘려가는 편이 자연스럽다.

카테고리 이름에 영어와 한글을 섞어 써도 되나요?

손님이 실제로 쓰는 표현을 우선하되, 지나치게 섞어 쓰는 것은 피하는 것이 좋다. "홈페이지 제작", "SEO 컨설팅"처럼 이미 한글 표현보다 영어(또는 영문 약어)가 더 널리 통용되는 경우에는 그대로 쓰는 것이 자연스럽다.

다만 "스마트 토탈 케어 솔루션"처럼 의미가 모호한 영어 단어를 억지로 조합한 이름은 피해야 한다. 카테고리 이름을 정할 때는 "이 표현을 실제로 검색창에 치는 사람이 있는가"를 기준으로 삼으면 대부분 자연스럽게 정리된다.

홈페이지 구조와 콘텐츠 전략은 누가 먼저 정해야 하나요?

콘텐츠로 다룰 주제 범위를 먼저 정하고, 그 범위에 맞춰 구조를 설계하는 순서가 안전하다. 어떤 주제를, 얼마나 깊이 다룰 것인지가 정해져야 몇 개의 카테고리가 필요한지, 각 카테고리 아래 얼마나 많은 하위 페이지가 들어갈지 가늠할 수 있다.

구조를 먼저 정하고 나중에 콘텐츠 범위를 억지로 맞추면, 카테고리는 있는데 채울 내용이 없거나 반대로 내용은 많은데 담을 카테고리가 없는 상황이 생기기 쉽다.

마무리: 뼈대부터 제대로 세우자

홈페이지 구조는 화려하지 않다. 색상도, 애니메이션도 없다. 그러나 정보구조와 URL, 내부 링크라는 이 눈에 안 보이는 뼈대가, 결국 사람도 구글도 AI도 이 사이트를 얼마나 잘 이해하는지를 결정한다.

오늘 배운 것을 요약하면 이렇다.

• 정보구조(IA)를 디자인보다 먼저 정한다 — 손님이 궁금해하는 순서로 카테고리를 짠다
• URL은 구글 공식 권장대로 읽기 쉬운 단어와 하이픈으로 짓고, 의미 없는 파라미터는 정리한다
• 카테고리 깊이는 손님이 헤매지 않을 만큼만 — 단계 수보다 각 갈림길의 명확함이 중요하다
• 내부 링크로 구조를 실제로 작동시킨다 — 고아 페이지를 만들지 않는다
• AI 검색을 위해 억지로 콘텐츠를 쪼갤 필요는 없다 — 사람을 위한 좋은 구조가 결국 AI에도 통한다
• 구조화 데이터로 엔티티 관계를 명확히 알려주면 검색과 AI 양쪽에 도움이 된다

무인도에 아무리 예쁜 호텔을 지어도 손님이 존재를 모르면 소용없다는 말을 이 블로그에서 자주 한다. 구조가 부실한 사이트는 이와 비슷하다. 손님이 존재는 알아도, 그 안에서 원하는 방을 못 찾아 그냥 나가 버리는 호텔과 같다.

홈페이지를 처음 만드는 단계라면 오늘 다룬 정보구조, URL, 내부 링크 원칙 세 가지만 순서대로 짚어도 절반은 완성된 셈이다. 이미 운영 중인 사이트라면, 앞서 정리한 점검 순서대로 사이트맵과 클릭 깊이, URL, 고아 페이지 여부만 훑어봐도 무엇을 먼저 손봐야 할지 감이 잡힐 것이다.

이루웹은 기획 단계부터 정보구조와 URL 설계를 반영해 홈페이지를 만드는 SEO 웹 에이전시입니다. 카테고리 설계, 내부 링크 구조, 구조화 데이터까지 검색과 AI 양쪽에 잘 잡히는 뼈대를 함께 세워 드립니다. 지금 사이트의 구조가 괜찮은지 궁금하시다면 SEO 홈페이지 제작 서비스와 전체 서비스를 살펴보시고, 무료 상담으로 현재 구조를 함께 진단받아 보시길 권해 드립니다. 뼈대부터 제대로 세우는 일, 저희가 함께하겠습니다.