DEV Community: austin

웹 디렉터리 내부 검색 랭킹은 어떻게 설계할까? Radar Link Site 사례로 보는 검색 점수 구조

austin — Mon, 09 Nov 2026 03:18:25 +0000

웹 디렉터리에 검색 기능을 붙이는 일은 생각보다 단순하지 않습니다.

처음에는 사이트 이름이나 설명에 검색어가 포함되면 결과에 보여주면 될 것 같았습니다.

하지만 사이트 수가 늘어나면 곧 문제가 생깁니다.

같은 검색어에 수십 개의 결과가 나오고, 사용자가 원하는 사이트가 아래쪽에 묻히기 시작합니다.

결국 중요한 문제는 이것입니다.

어떤 결과를 먼저 보여줄 것인가?

제가 운영하고 있는 웹 디렉터리 프로젝트 Radar Link Site에서도 이 문제가 중요했습니다.

Radar Link Site는 다양한 웹사이트를 카테고리별로 탐색하고 비교할 수 있도록 구성한 웹 디렉터리이기 때문에, 검색 결과 순서는 곧 탐색 경험과 연결됩니다.

1. 단순 문자열 검색은 금방 한계가 생긴다

가장 기본적인 검색은 다음처럼 만들 수 있습니다.

function searchSites(query, sites) {
  const keyword = query.toLowerCase();

  return sites.filter(site =>
    site.name.toLowerCase().includes(keyword) ||
    site.description.toLowerCase().includes(keyword)
  );
}

이 방식은 사이트 수가 적을 때는 충분합니다.

하지만 결과를 정렬하지 않으면 이런 문제가 생깁니다.

검색어: ai

AI Community
AI Image Generator
Best AI Tools
AI Writing Platform
Productivity with AI

사용자가 실제로 원하는 것이 “AI 도구”인지 “AI 커뮤니티”인지 구분하기 어렵습니다.

모두 검색어가 포함되어 있다는 이유만으로 같은 중요도를 가지게 됩니다.

2. 검색 결과에 점수를 부여한다

그래서 각 결과에 점수를 계산하는 방식으로 바꿀 수 있습니다.

예를 들어 다음 요소를 사용할 수 있습니다.

사이트 이름 일치
카테고리 일치
태그 일치
설명문 일치
인기도
최신성

가장 단순한 형태는 다음과 같습니다.

function calculateSearchScore(site, query) {
  const q = query.toLowerCase();
  let score = 0;

  if (site.name.toLowerCase() === q) {
    score += 10;
  }

  if (site.name.toLowerCase().includes(q)) {
    score += 6;
  }

  if (site.category.toLowerCase().includes(q)) {
    score += 4;
  }

  if (site.tags.some(tag =>
    tag.toLowerCase().includes(q)
  )) {
    score += 3;
  }

  if (site.description.toLowerCase().includes(q)) {
    score += 1;
  }

  return score;
}

이제 단순 포함 여부가 아니라 어디에 검색어가 등장했는지에 따라 결과의 우선순위를 다르게 줄 수 있습니다.

3. 사이트 이름은 가장 강한 신호로 본다

웹 디렉터리에서는 사용자가 정확한 사이트 이름을 검색하는 경우가 많습니다.

예를 들어:

reddit
github
notion

같은 검색어라면 설명문보다 사이트 이름 일치가 훨씬 중요합니다.

그래서 저는 보통 이런 식으로 가중치를 생각합니다.

Exact name match        10
Partial name match       6
Category match           4
Tag match                3
Description match        1

결과는 다음처럼 정렬할 수 있습니다.

function searchAndRank(query, sites) {
  return sites
    .map(site => ({
      ...site,
      score: calculateSearchScore(site, query)
    }))
    .filter(site => site.score > 0)
    .sort((a, b) => b.score - a.score);
}

4. 카테고리 검색은 별도로 생각해야 한다

문제는 사용자가 사이트 이름이 아니라 주제를 검색할 때입니다.

예를 들어:

community
shopping
jobs
finance
ai

이런 검색어는 특정 사이트 하나를 찾는 것이 아니라 해당 분야를 탐색하려는 의도가 강합니다.

그래서 카테고리 일치에는 더 높은 가중치를 줄 수도 있습니다.

if (site.category.toLowerCase() === q) {
  score += 8;
}

Radar Link Site처럼 카테고리 탐색이 중요한 웹 디렉터리에서는 이 차이가 꽤 큽니다.

정확한 사이트를 찾는 검색과 새로운 사이트를 발견하려는 검색은 사실 서로 다른 문제이기 때문입니다.

5. 태그는 검색 결과의 정밀도를 높인다

카테고리만으로는 충분하지 않은 경우가 많습니다.

예를 들어 AI 카테고리 안에서도:

image
writing
coding
research
video
automation

처럼 서비스 목적이 크게 다릅니다.

그래서 사이트마다 태그를 추가할 수 있습니다.

{
  name: "Example AI Tool",
  category: "AI",
  tags: [
    "image",
    "design",
    "generator"
  ]
}

사용자가 image를 검색하면 단순히 AI 카테고리 전체를 보여주는 것이 아니라 이미지 관련 사이트를 더 위에 배치할 수 있습니다.

6. 검색어 정규화가 생각보다 중요하다

실제 검색 로그를 보면 사용자는 항상 깔끔하게 검색하지 않습니다.

예를 들어:

AI tools
ai tool
AI툴
ai-tools
ai_tools

같은 의미의 검색어가 여러 형태로 들어올 수 있습니다.

그래서 기본적인 정규화 과정이 필요합니다.

function normalizeQuery(query) {
  return query
    .toLowerCase()
    .trim()
    .replace(/[-_]/g, " ")
    .replace(/\s+/g, " ");
}

조금 더 발전시키면 별칭도 추가할 수 있습니다.

const synonyms = {
  "ai tool": ["ai tools", "ai service", "artificial intelligence"],
  "jobs": ["job", "career", "employment"],
  "community": ["forum", "discussion", "social"]
};

웹 디렉터리는 일반 검색엔진보다 데이터 범위가 작기 때문에 이런 수동 사전도 상당히 효과적일 수 있습니다.

7. 클릭 데이터를 검색 랭킹에 반영할 수 있다

텍스트 관련도만으로 결과를 정렬하면 실제 사용자 선호와 차이가 생길 수 있습니다.

예를 들어 두 사이트의 검색 점수가 같다고 가정해보겠습니다.

Site A score = 8
Site B score = 8

하지만 실제로는 Site A가 훨씬 많이 클릭될 수 있습니다.

그러면 클릭 데이터를 추가적인 신호로 사용할 수 있습니다.

finalScore =
  relevanceScore * 0.8 +
  popularityScore * 0.2;

다만 여기서 주의할 점이 있습니다.

인기 사이트를 계속 위에 올리면 새로운 사이트는 영원히 아래에 남을 수 있습니다.

8. 인기 편향을 막아야 한다

인기 데이터를 그대로 사용하면 이런 현상이 생깁니다.

Popular Site
↓
More Exposure
↓
More Clicks
↓
Higher Rank
↓
Even More Exposure

결국 기존 인기 사이트만 계속 강해집니다.

그래서 클릭 데이터는 보조 신호로만 사용하는 것이 좋습니다.

예를 들어:

const popularityBoost =
  Math.log(site.clicks + 1);

처럼 로그 스케일을 적용하면 클릭 수가 큰 사이트가 점수를 독점하는 것을 어느 정도 줄일 수 있습니다.

9. 최신성도 하나의 신호가 될 수 있다

웹 디렉터리에서는 오래된 사이트와 최근에 추가된 사이트가 함께 존재합니다.

최근 확인된 사이트를 약간 우선할 수도 있습니다.

function freshnessScore(lastChecked) {
  const days =
    (Date.now() - new Date(lastChecked)) /
    (1000 * 60 * 60 * 24);

  if (days < 7) return 2;
  if (days < 30) return 1;

  return 0;
}

하지만 최신성이 항상 품질을 의미하는 것은 아닙니다.

그래서 이 역시 작은 보너스 정도로 사용하는 편이 안전합니다.

10. 최종 점수 구조

이제 여러 신호를 합치면 다음과 같은 형태가 됩니다.

function finalSearchScore(site, query) {
  const relevance =
    calculateSearchScore(site, query);

  const popularity =
    Math.log(site.clicks + 1);

  const freshness =
    freshnessScore(site.lastChecked);

  return (
    relevance * 0.8 +
    popularity * 0.15 +
    freshness * 0.05
  );
}

중요한 점은 숫자 자체가 아닙니다.

이 비율은 서비스의 목적에 따라 달라져야 합니다.

11. 웹 디렉터리 검색은 검색엔진과 목적이 다르다

일반 검색엔진은 수십억 개의 문서에서 답을 찾습니다.

웹 디렉터리는 훨씬 작은 데이터셋 안에서 좋은 선택지를 발견하도록 돕는 것이 목적입니다.

그래서 웹 디렉터리 검색에서는 다음 요소가 더 중요할 수 있습니다.

Exact Site Match
Category Relevance
Tag Relevance
Site Quality
Freshness
Result Diversity

검색 결과를 무조건 하나의 정답으로 만들기보다 사용자가 비교할 수 있는 선택지를 보여주는 것이 중요합니다.

실제 프로젝트: Radar Link Site

이 검색 구조를 고민하게 된 이유는 제가 운영하고 있는 Radar Link Site 때문입니다.

Radar Link Site는 여러 분야의 웹사이트를 카테고리별로 탐색하고 비교할 수 있도록 만든 웹 디렉터리입니다.

현재 제가 가장 중요하게 보는 흐름은 다음과 같습니다.

Search
↓
Discover
↓
Compare
↓
Visit

정확한 사이트 이름을 알고 있는 사용자는 검색을 사용할 수 있고,

어떤 사이트가 있는지 모르는 사용자는 카테고리에서 탐색할 수 있습니다.

결국 검색과 카테고리는 경쟁 관계가 아니라 서로 다른 사용자 의도를 해결하는 두 개의 탐색 방식입니다.

Radar Link Site

👉 radarlinksite.com

커뮤니티, AI 도구, 쇼핑, 구인구직, 금융·재테크 등 다양한 분야의 웹사이트를 카테고리별로 탐색할 수 있도록 구성하고 있습니다.

웹 디렉터리를 만들고 있다면 사이트를 얼마나 많이 수집할 것인가만큼,

사용자가 원하는 사이트를 어떤 순서로 보여줄 것인가

도 중요한 설계 문제입니다.

마무리

웹 디렉터리 검색 랭킹을 처음 만든다면 다음 순서로 시작할 것 같습니다.

1. Exact name match
2. Partial name match
3. Category
4. Tags
5. Description
6. Click data
7. Freshness
8. Result diversity

처음부터 복잡한 검색엔진을 만들 필요는 없습니다.

작은 데이터셋에서는 단순한 가중치 기반 점수만으로도 충분히 좋은 결과를 만들 수 있습니다.

그리고 실제 검색 로그가 쌓이면 그때 가중치를 조금씩 조정하면 됩니다.

결국 좋은 검색은 단순히 결과를 많이 보여주는 것이 아니라,

사용자가 다음 클릭을 고민하는 시간을 줄여주는 것이라고 생각합니다.

AI Assistance Disclosure: 이 글은 실제 웹 디렉터리 운영과 검색 구조 아이디어를 기반으로 작성했으며, AI를 초안 구성과 문장 정리에 보조적으로 사용했습니다. 게시 전 코드와 기술 내용을 직접 검토하고 수정했습니다.

webdev #javascript #search #seo

하나의 웹 디렉터리를 두 개의 사이트로 나눈 이유: 탐색과 설명은 같은 UI가 아니었다

austin — Tue, 03 Nov 2026 03:02:11 +0000

웹 디렉터리를 처음 만들 때는 한 사이트 안에 모든 기능을 넣는 것이 가장 단순하다고 생각했습니다.

카테고리를 만들고, 사이트를 등록하고, 사용자가 원하는 링크를 찾게 하면 끝이라고 생각했습니다.

하지만 운영하면서 조금 다른 문제가 보이기 시작했습니다.

사용자는 모두 같은 목적으로 방문하지 않았습니다.

어떤 사용자는 주소를 빨리 찾고 싶어 했고, 어떤 사용자는 어떤 사이트들이 있는지 비교하고 싶어 했습니다.

그리고 또 다른 사용자는 특정 카테고리가 무엇인지, 어떤 사이트를 선택해야 하는지 설명부터 필요로 했습니다.

결국 하나의 인터페이스에 너무 많은 역할을 넣기보다 역할을 분리하는 방향으로 구조를 바꾸게 됐습니다.

현재 제가 운영하고 있는 두 프로젝트가 그 결과입니다.

문제는 데이터가 아니라 사용자 의도였다

처음에는 이런 구조가 자연스러워 보였습니다.

Home
├── AI
├── Community
├── Shopping
├── Jobs
├── Finance
└── Other Categories

카테고리를 선택하면 사이트 목록이 나오고, 사용자가 원하는 사이트를 클릭합니다.

웹 디렉터리로서는 충분히 정상적인 구조입니다.

그런데 실제 사용 흐름을 생각해보면 두 가지 의도가 섞여 있었습니다.

Intent A
"I already know roughly what I need."

→ category
→ site
→ visit

반면 다른 사용자는 다음과 같습니다.

Intent B
"I know the topic, but I don't know which site I need."

→ understand category
→ discover options
→ compare
→ choose

두 흐름은 비슷해 보이지만 필요한 인터페이스가 다릅니다.

빠른 탐색과 설명형 콘텐츠의 충돌

주소를 빨리 찾는 사용자에게 긴 설명은 방해가 됩니다.

반대로 새로운 사이트를 탐색하는 사용자에게 링크 목록만 보여주면 맥락이 부족합니다.

예를 들어 빠른 탐색 페이지에서는 이런 구조가 적합합니다.

AI
├── Site A
├── Site B
├── Site C
└── Site D

하지만 설명형 페이지는 다음과 같은 구조가 더 자연스럽습니다.

What is this category?
↓
What kinds of sites are included?
↓
Available options
↓
How are they different?
↓
Related categories

하나의 페이지에서 두 가지를 모두 만족시키려고 하면 결국 UI가 복잡해지기 시작합니다.

버튼은 늘어나고 설명은 길어지고, 사용자가 실제로 원하는 링크는 아래로 밀립니다.

그래서 저는 역할 자체를 분리하기로 했습니다.

radarjuso.com: 빠른 탐색 중심

첫 번째 프로젝트는 radarjuso.com 입니다.

이쪽에서는 사용자가 원하는 분야를 먼저 선택하고 관련 사이트를 빠르게 확인하는 흐름을 중요하게 보고 있습니다.

개념적으로는 다음과 같습니다.

Category
↓
Relevant Sites
↓
Destination

정보 밀도를 높이고 이동 단계를 줄이는 것이 핵심입니다.

사용자가 이미 원하는 분야를 알고 있다면 설명보다 선택지가 먼저 보여야 하기 때문입니다.

radarlinksite.com: 설명과 탐색을 연결

두 번째 프로젝트는 radarlinksite.com 입니다.

이 사이트에서는 링크 목록 자체보다 카테고리와 사이트를 이해하는 과정에 조금 더 공간을 사용하고 있습니다.

현재 이 프로젝트는 Next.js 기반의 정적 사이트 구조로 운영하고 있습니다.

개념적인 페이지 구조는 다음과 같습니다.

/
├── sites/
│   ├── category-a/
│   ├── category-b/
│   └── category-c/
├── blog/
├── about/
└── privacy/

여기에서는 단순히 목적지 URL을 보여주는 것뿐 아니라 사용자가 관련 카테고리를 탐색할 수 있도록 구조를 확장할 수 있습니다.

즉 역할을 단순하게 나누면 다음과 같습니다.

radarjuso.com
→ Find

radarlinksite.com
→ Discover + Understand

두 사이트가 완전히 다른 서비스를 제공한다기보다 같은 문제를 서로 다른 사용자 흐름에서 해결하도록 분리한 것에 가깝습니다.

처음부터 두 사이트가 필요했던 것은 아니다

여기서 중요한 점은 프로젝트를 시작하자마자 여러 사이트로 분리하는 것이 좋은 설계라는 뜻은 아닙니다.

오히려 대부분의 경우 하나의 사이트로 시작하는 것이 훨씬 낫습니다.

서비스가 작을 때 두 개의 사이트를 운영하면 다음과 같은 비용이 생깁니다.

Deployment × 2
Analytics × 2
SEO monitoring × 2
Content maintenance × 2
Broken link checks × 2

네, 구조를 분리하면 관리해야 할 것도 친절하게 두 배 가까이 늘어납니다.

소프트웨어는 늘 문제를 해결한 대가로 새로운 문제를 하나 무료로 제공합니다.

그래서 분리 기준은 기술적인 이유보다 사용자 흐름이 정말 다른가가 되어야 한다고 생각합니다.

같은 내용을 복사하지 않는 것이 중요했다

사이트를 둘로 나눈 다음 가장 피하고 싶었던 것은 동일한 페이지를 두 도메인에 복사하는 것이었습니다.

예를 들어 이런 구조는 좋지 않습니다.

Site A:
/ai

Site B:
/ai

Same title
Same description
Same links
Same content

이렇게 만들면 사용자의 입장에서도 두 사이트를 운영할 이유가 없습니다.

대신 동일한 주제를 다루더라도 페이지의 역할을 다르게 정의했습니다.

Directory page
→ 선택과 이동

Editorial / discovery page
→ 설명과 탐색

콘텐츠 자체보다 페이지가 수행하는 작업을 먼저 정의하는 방식입니다.

페이지 역할을 먼저 정의하면 구현도 단순해진다

이후 새로운 페이지를 만들 때는 먼저 질문합니다.

What should the user accomplish here?

그리고 페이지 역할을 몇 가지로 제한합니다.

const pageRoles = {
  directory: "find a destination quickly",
  category: "explore related websites",
  editorial: "understand a topic",
  navigation: "move between categories"
};

실제 코드에서 꼭 이런 객체를 사용할 필요는 없습니다.

중요한 것은 각 페이지마다 하나의 주된 역할을 정하는 것입니다.

그렇게 하면 다음 결정도 쉬워집니다.

얼마나 많은 설명을 넣을 것인가?
링크를 어디에 배치할 것인가?
관련 카테고리를 보여줄 것인가?
검색 기능이 필요한가?
다음 행동은 무엇이어야 하는가?

두 사이트를 운영하면서 얻은 가장 큰 교훈

처음에는 웹 디렉터리를 데이터 문제라고 생각했습니다.

Collect URLs
↓
Categorize them
↓
Display them

지금은 조금 다르게 생각합니다.

User intent
↓
Page role
↓
Information architecture
↓
Content
↓
Links

링크 자체는 마지막에 가깝습니다.

그 전에 사용자가 왜 이 페이지에 왔는지를 정의해야 합니다.

현재 이 구조를 실제로 테스트하고 있는 두 사이트가 다음 프로젝트입니다.

레이더 주소모음 — radarjuso.com

빠르게 카테고리를 선택하고 관련 웹사이트를 탐색하는 디렉터리입니다.

Radar Link Site — radarlinksite.com

카테고리와 웹사이트를 조금 더 설명형 구조로 탐색할 수 있도록 만든 프로젝트입니다.

두 사이트를 운영하면서 계속 확인하고 있는 질문은 간단합니다.

사용자가 원하는 것은 더 많은 링크일까, 아니면 더 빠른 결정일까?

점점 후자에 가깝다고 생각하고 있습니다.

이 글은 실제 웹 디렉터리 프로젝트 운영 경험을 기반으로 작성했으며, AI는 초안 구성과 문장 정리에 보조적으로 사용했습니다. 게시 전 기술 내용과 프로젝트 관련 사실을 직접 검토했습니다.

webdev #architecture #ux #showdev

두 개의 웹사이트를 운영하면서 canonical과 메타데이터 구조를 다시 정리한 이유

austin — Sat, 31 Oct 2026 04:00:09 +0000

웹사이트를 하나만 운영할 때는 SEO 구조가 비교적 단순합니다.

하지만 비슷한 브랜드 목적을 가진 사이트를 두 개 이상 운영하기 시작하면 문제가 생깁니다.

제가 운영하고 있는 두 사이트는 다음과 같습니다.

두 사이트 모두 웹사이트를 카테고리별로 정리하고 사용자가 필요한 사이트를 더 쉽게 찾도록 돕는 역할을 하지만, 페이지 구조와 목적은 조금 다르게 운영하고 있습니다.

같은 브랜드라도 페이지 역할은 분리해야 했습니다

처음에는 두 사이트에서 비슷한 키워드와 설명을 사용하는 것이 크게 문제가 되지 않을 거라고 생각했습니다.

하지만 실제로 운영하다 보니 이런 질문이 생겼습니다.

검색엔진은 어떤 페이지를 대표 페이지로 판단할까?

비슷한 제목, 설명, 카테고리 구조가 반복되면 페이지 역할이 모호해질 수 있습니다.

그래서 각 사이트의 역할을 좀 더 분명하게 나누기 시작했습니다.

radarjuso.com

→ 주소모음, 링크모음, 카테고리별 사이트 탐색 중심

radarlinksite.com

→ 카테고리 구조, 사이트 탐색, 정보형 페이지와 프로젝트 소개 중심

canonical은 단순한 태그가 아니었습니다

페이지마다 canonical을 넣는 것만으로 끝나는 문제가 아니었습니다.

예를 들어 실제 페이지가

https://radarlinksite.com/sites/

라면 canonical 역시 해당 페이지의 실제 목적과 일치해야 합니다.

<link
  rel="canonical"
  href="https://radarlinksite.com/sites/"
>

반대로 모든 페이지를 홈페이지로 canonical 처리하면 개별 카테고리나 상세페이지의 역할이 사라질 수 있습니다.

그래서 canonical은 단순히 “중복 방지 태그”라기보다

이 페이지가 검색엔진에게 어떤 URL로 이해되길 원하는가

를 정의하는 값이라고 생각하게 됐습니다.

메타데이터도 사이트마다 다르게 구성했습니다

두 사이트가 같은 브랜드를 공유하더라도 모든 페이지 제목을 비슷하게 만들 필요는 없습니다.

예를 들어:

레이더 주소모음 | 필요한 사이트 빠르게 찾기

와

Radar Link Site | 카테고리별 웹사이트 탐색

처럼 각각의 목적을 다르게 표현할 수 있습니다.

Description도 마찬가지입니다.

페이지마다 같은 소개 문장을 복사하기보다,

어떤 카테고리인지
사용자가 무엇을 찾을 수 있는지
페이지가 어떤 역할을 하는지

를 기준으로 다르게 작성하는 편이 더 명확했습니다.

실제로 두 사이트를 계속 개선하고 있습니다

현재 저는 두 프로젝트를 함께 운영하면서 페이지 역할, 내부링크, canonical, 메타데이터 구조를 계속 조정하고 있습니다.

레이더 주소모음 — radarjuso.com

여러 웹사이트를 카테고리별로 정리해서 필요한 사이트와 주소를 빠르게 탐색할 수 있도록 만든 주소모음 서비스입니다.

Radar Link Site — radarlinksite.com

웹사이트를 분야별로 탐색하고 관련 카테고리와 사이트 정보를 확인할 수 있도록 구성한 웹 디렉터리 프로젝트입니다.

두 사이트 모두 단순히 링크를 쌓는 것이 아니라,

분류 → 탐색 → 비교 → 필요한 사이트 확인

이라는 흐름을 만드는 것을 목표로 운영하고 있습니다.

직접 확인해볼 수 있습니다

현재 구조가 어떻게 나뉘어 있는지 궁금하다면 두 사이트를 직접 비교해볼 수 있습니다.

👉 레이더 주소모음 바로가기

👉 Radar Link Site 바로가기

웹사이트를 여러 개 운영하고 있다면 같은 키워드를 반복하는 것보다 각 사이트와 페이지의 역할을 명확하게 나누는 것이 훨씬 중요하다고 느끼고 있습니다.

이 글은 AI를 초안 구성과 문장 정리에 활용했으며, 게시 전 실제 사이트 운영 경험과 내용을 기준으로 검토·수정했습니다.

webdev #seo #showdev #architecture

검색만으로는 새로운 웹사이트를 발견하기 어렵다고 느꼈습니다

austin — Mon, 26 Oct 2026 04:00:29 +0000

검색엔진은 이미 알고 있는 것을 찾을 때 굉장히 편합니다.

사이트 이름이나 원하는 서비스가 명확하다면 검색어를 입력하고 결과를 선택하면 됩니다.

하지만 한 가지 문제가 있었습니다.

어떤 사이트가 있는지조차 모르는 상태에서는 무엇을 검색해야 할까요?

이 질문에서 제가 운영하고 있는 Radar의 방향이 시작됐습니다.

![레이더 주소모음 마스코트]

Radar는 필요한 사이트를 더 빠르게 발견할 수 있도록 돕는 웹 디렉터리입니다.

👉 Radar 직접 둘러보기 — radarjuso.com

Search와 Discovery는 다른 문제였습니다

검색은 기본적으로 사용자가 어느 정도 답을 알고 있다는 전제에서 시작합니다.

예를 들어 특정 AI 서비스나 커뮤니티 이름을 알고 있다면 그대로 검색하면 됩니다.

반대로,

새로운 AI 도구를 찾고 싶다
다른 커뮤니티에는 어떤 곳이 있는지 궁금하다
해외직구 사이트를 비교하고 싶다
새로운 웹서비스를 발견하고 싶다

처럼 정확한 사이트 이름을 모르는 경우에는 검색어부터 결정해야 합니다.

그래서 저는 Search와 Discovery를 따로 보기 시작했습니다.

Search → 알고 있는 사이트를 빠르게 찾기

Discovery → 몰랐던 사이트와 선택지를 발견하기

그래서 Radar를 만들었습니다

Radar — radarjuso.com 은 다양한 웹사이트를 카테고리별로 정리해서 탐색할 수 있도록 만든 웹 디렉터리입니다.

검색창에서 사이트 이름을 하나씩 입력하는 대신 먼저 관심 있는 분야를 선택하고 관련 사이트를 둘러볼 수 있습니다.

카테고리 선택 → 관련 사이트 확인 → 여러 선택지 비교 → 필요한 사이트 방문

검색도 함께 사용할 수 있습니다

이미 찾고 싶은 사이트가 있다면 검색이 더 빠릅니다.

그래서 Radar는 검색과 카테고리 탐색을 경쟁하는 기능으로 보지 않습니다.

사이트 이름을 알고 있다면 → Search

무엇이 있는지 먼저 보고 싶다면 → Browse

사용자는 상황에 따라 두 방식을 사용할 수 있습니다.

새로운 사이트를 발견하는 과정도 중요합니다

웹에는 이미 수많은 서비스가 있지만, 검색 결과에 반복해서 등장하는 사이트만 이용하다 보면 다른 선택지가 있다는 사실조차 알기 어렵습니다.

Radar에서는 특정 사이트로 이동하는 것뿐 아니라 같은 분야에 어떤 다른 선택지가 있는지도 발견할 수 있게 만드는 것을 중요하게 보고 있습니다.

직접 Radar에서 찾아보세요

커뮤니티, AI 도구, 쇼핑, 구인구직, 생활정보 등 다양한 분야의 사이트를 한곳에서 탐색할 수 있습니다.

👉 Radar에서 필요한 사이트 찾아보기

이미 알고 있는 사이트는 검색하고, 아직 모르는 사이트는 발견하세요.

Radar — radarjuso.com 바로가기

검색 결과가 너무 많아서 웹 디렉터리를 다시 만들기 시작했습니다

austin — Fri, 23 Oct 2026 03:11:24 +0000

인터넷에는 좋은 사이트가 정말 많습니다.

문제는 필요한 사이트를 찾는 과정이 점점 더 복잡해졌다는 점입니다.

검색어 하나를 입력하면 수많은 결과가 나오지만, 실제로 원하는 사이트를 찾으려면 광고와 비슷한 페이지, 오래된 정보, 관련 없는 결과를 계속 걸러내야 하는 경우가 많습니다.

그래서 저는 “검색 결과를 더 많이 보여주는 것보다, 필요한 사이트를 더 쉽게 찾게 만들 수 없을까?”라는 생각으로 Radar를 운영하고 있습니다.

Radar는 무엇인가요?

radarjuso.com 은 여러 웹사이트를 카테고리별로 정리해서 탐색할 수 있도록 만든 웹 디렉터리입니다.

사용자가 정확한 사이트 이름을 몰라도 먼저 관심 있는 분야를 선택하고, 그 안에서 여러 사이트를 비교해서 볼 수 있도록 구성했습니다.

예를 들면 다음과 같은 분야를 살펴볼 수 있습니다.

커뮤니티
AI 도구
쇼핑·해외직구
구인구직
금융·재테크
생활정보
엔터테인먼트
기타 유용한 웹서비스

검색과 발견은 다른 문제였습니다

처음에는 검색 기능만 잘 만들면 충분하다고 생각했습니다.

하지만 이미 사이트 이름을 알고 있는 사람에게는 검색이 좋지만, 어떤 사이트를 써야 할지 모르는 사람에게는 검색어 자체가 문제였습니다.

그래서 Radar에서는 두 가지 흐름을 같이 사용합니다.

알고 있는 사이트 찾기 → 검색

새로운 사이트 찾기 → 카테고리 탐색

이 차이를 나누고 나니 서비스 구조도 훨씬 단순해졌습니다.

링크를 많이 모으는 것보다 분류가 중요했습니다

웹 디렉터리를 만들면서 가장 크게 느낀 점은 링크 수가 많다고 좋은 서비스가 되는 건 아니라는 점이었습니다.

사이트가 늘어날수록 중요한 건 다음과 같은 부분이었습니다.

사용자가 카테고리를 쉽게 이해할 수 있는가
비슷한 사이트를 비교할 수 있는가
원하는 사이트까지 이동하는 단계가 짧은가
예전에 이용했던 사이트를 다시 찾기 쉬운가
새로운 사이트를 자연스럽게 발견할 수 있는가

결국 디렉터리의 역할은 단순한 링크 저장소가 아니라 탐색을 돕는 인터페이스에 더 가깝다고 생각하게 됐습니다.

직접 확인해볼 수 있습니다

현재 이 구조를 계속 개선하고 있는 실제 프로젝트가 Radar — radarjuso.com 입니다.

여러 웹사이트를 자주 찾거나, 매번 검색창에서 같은 사이트를 다시 찾는 일이 번거롭다면 직접 한 번 사용해보세요.

👉 Radar에서 필요한 사이트 찾아보기

검색 결과를 계속 넘기는 대신, 카테고리부터 선택하고 필요한 사이트를 한 번에 비교해보는 방식도 꽤 편할 수 있습니다.

추천 태그: #webdev #showdev #ux #productivity

주소모음 서비스를 만들면서 사이트 탐색 UX를 단순화한 방법

austin — Wed, 21 Oct 2026 02:59:52 +0000

주소모음 서비스를 만들면서 사이트 탐색 UX를 단순화한 방법

웹사이트를 만들 때 처음에는 콘텐츠가 많을수록 사용자에게 도움이 될 거라고 생각했습니다.

그래서 다양한 사이트를 한 화면에 최대한 많이 보여주려고 했습니다.

그런데 실제로 운영하면서 반대 문제가 생겼습니다.

사이트가 많아질수록 사용자는 선택하기 어려워졌고, 원하는 사이트를 찾으려면 화면을 계속 내려보거나 여러 페이지를 돌아다녀야 했습니다.

결국 문제는 사이트 개수보다 탐색 구조에 있었습니다.

사이트를 먼저 보여주는 대신 카테고리를 먼저 보여줬습니다

제가 운영하고 있는 프로젝트는 레이더(Radar)입니다.

radarjuso.com은 여러 분야의 웹사이트를 카테고리별로 정리해서 보여주는 주소모음 서비스입니다.

초기에는 사이트 목록 자체를 강조했지만, 운영하면서 사용자가 먼저 원하는 분야를 선택할 수 있도록 구조를 바꿨습니다.

현재 가장 중요하게 보고 있는 탐색 흐름은 단순합니다.

카테고리 선택 → 관련 사이트 탐색 → 여러 선택지 비교 → 필요한 사이트 확인

예를 들어 사용자가 AI 관련 사이트를 찾고 있다면 전체 사이트 목록을 훑는 대신 AI 카테고리부터 들어갈 수 있도록 하는 방식입니다.

카테고리마다 역할을 나눴습니다

카테고리가 늘어나면서 또 다른 문제가 생겼습니다.

서로 다른 페이지들이 비슷한 설명과 키워드를 사용하기 시작했습니다.

그래서 각 페이지의 목적을 다시 정리했습니다.

홈은 서비스 전체를 설명
카테고리는 특정 분야의 사이트를 탐색
상세 페이지는 개별 사이트의 기본 정보를 확인

이렇게 역할을 구분하니 UX뿐 아니라 콘텐츠를 작성할 때도 훨씬 명확해졌습니다.

검색과 탐색을 같은 기능으로 보지 않았습니다

처음에는 검색창만 잘 만들면 사용자가 원하는 사이트를 쉽게 찾을 거라고 생각했습니다.

하지만 검색은 이미 사이트 이름을 알고 있는 사람에게 더 유용했습니다.

반대로 어떤 사이트를 써야 할지 아직 모르는 사람에게는 탐색 기능이 더 중요했습니다.

그래서 Radar에서는 검색뿐 아니라 카테고리를 둘러보면서 새로운 사이트를 발견할 수 있는 구조도 같이 중요하게 보고 있습니다.

사용 목적이 다른 두 사용자를 모두 고려하는 셈입니다.

알고 있는 사이트 찾기 → 검색

새로운 사이트 찾기 → 카테고리 탐색

내부 링크도 사용자 흐름에 맞췄습니다

페이지가 늘어나면서 처음에는 관련 페이지를 최대한 많이 연결했습니다.

하지만 내부 링크가 많아질수록 사용자가 어디로 이동해야 하는지 오히려 모호해졌습니다.

지금은 현재 페이지와 실제로 관련 있는 이동 경로만 남기는 방향으로 조정하고 있습니다.

기본 구조는 다음과 같습니다.

홈 → 카테고리 → 사이트 정보 → 관련 카테고리

SEO를 위해 링크를 추가하는 것보다 실제 사용자가 다음에 어떤 페이지를 필요로 할지를 먼저 생각하게 됐습니다.

주소모음 서비스도 결국 정보 구조 문제였습니다

Radar를 만들면서 가장 크게 바뀐 생각은 이것입니다.

주소모음 사이트라고 해서 링크만 많이 모으면 되는 게 아니었습니다.

사이트가 늘어날수록 더 중요한 것은 분류, 탐색, 비교, 재발견이었습니다.

사용자가 원하는 사이트를 빨리 찾는 것도 중요하지만, 몰랐던 사이트를 발견할 수 있게 만드는 것 역시 디렉터리 서비스의 중요한 역할이라고 생각합니다.

현재 이런 구조를 실제로 적용하면서 계속 테스트하고 있는 프로젝트가 radarjuso.com입니다.

카테고리형 서비스나 디렉터리를 만들고 있다면 사이트 수를 늘리기 전에, 사용자가 어디에서 시작하고 어떤 순서로 원하는 정보까지 이동하는지부터 확인해보는 것이 꽤 도움이 될 수 있습니다.

카테고리 페이지끼리 검색 의도가 겹칠 때 바꾼 것들

austin — Tue, 20 Oct 2026 03:31:05 +0000

카테고리형 사이트를 운영하다 보면 처음에는 페이지를 세분화하는 게 무조건 좋다고 생각하기 쉽습니다.

저도 처음에는 각 주제별로 페이지를 많이 만들고, 중요한 키워드를 여러 페이지에 반복해서 넣으면 검색 노출에 도움이 될 거라고 생각했습니다.

그런데 실제로 운영하면서 문제가 생겼습니다.

서로 다른 페이지가 비슷한 검색어를 사용하기 시작했고, 어떤 페이지가 어떤 검색 의도를 담당하는지 점점 애매해졌습니다.

문제는 페이지 수가 아니라 역할이었습니다

제가 운영하고 있는 레이더(Radar)는 여러 웹사이트를 카테고리별로 정리해서 보여주는 주소모음 서비스입니다.

사이트는 radarjuso.com입니다.

카테고리가 늘어나면서 주소모음, 링크모음, 사이트 추천, 최신주소 같은 표현이 여러 페이지에서 반복되기 시작했습니다.

처음에는 별문제가 없어 보였지만, 시간이 지나면서 각 페이지가 서로 다른 역할을 갖고 있는지 다시 보게 됐습니다.

예를 들어 모든 페이지가 비슷한 키워드를 사용하면 검색엔진 입장에서는 어떤 페이지가 더 적합한 결과인지 구분하기 어려울 수 있습니다.

그래서 페이지 역할을 다시 나눴습니다.

페이지마다 검색 의도를 분리했습니다

지금은 사이트 구조를 대략 이렇게 보고 있습니다.

홈페이지: 레이더 전체 서비스와 주소모음 구조 설명
카테고리 페이지: 특정 분야의 사이트 탐색
상세 페이지: 개별 사이트 정보와 주소 확인

예를 들어 AI 카테고리라면 AI 사이트 추천, AI 툴 모음, 유용한 AI 사이트처럼 해당 분야와 직접 연결되는 검색어를 중심으로 잡습니다.

반대로 모든 페이지에서 주소모음이라는 표현을 똑같은 강도로 반복하지 않습니다.

공통 키워드는 브랜드와 전체 서비스 설명에 남기고, 개별 페이지는 각자의 검색 의도를 담당하도록 바꿨습니다.

내부 링크도 같이 정리했습니다

검색 의도를 분리한 뒤 내부 링크 구조도 다시 봤습니다.

예전에는 관련성이 조금만 있어도 다른 카테고리로 연결했습니다.

지금은 사용자가 실제로 다음에 볼 가능성이 있는 페이지를 중심으로 연결합니다.

기본 흐름은 다음처럼 단순하게 유지하려고 합니다.

홈 → 카테고리 → 개별 사이트 → 관련 카테고리

내부 링크가 많다는 것보다 왜 그 페이지로 이동해야 하는지가 더 중요하다고 느꼈습니다.

지금 적용하고 있는 방식

현재 radarjuso.com에서는 다음 원칙을 중심으로 계속 구조를 조정하고 있습니다.

각 페이지는 하나의 명확한 역할을 갖는다.
비슷한 키워드를 모든 페이지에 반복하지 않는다.
카테고리마다 실제 검색 의도에 맞는 표현을 사용한다.
내부 링크는 관련성과 사용자 이동 흐름을 기준으로 연결한다.
사이트 탐색과 최신주소 확인을 서로 다른 목적처럼 본다.

완벽한 구조라고 생각하지는 않습니다.

다만 카테고리형 사이트를 운영하면서 가장 크게 바뀐 생각은 페이지를 더 만드는 것보다 각 페이지가 왜 존재하는지 설명할 수 있어야 한다는 점입니다.

비슷한 디렉터리나 콘텐츠 사이트를 운영하고 있다면, 새로운 페이지를 추가하기 전에 기존 페이지들의 검색 의도가 서로 겹치고 있지 않은지 먼저 확인해보는 것도 꽤 도움이 될 수 있습니다.

제가 이 구조를 실제로 테스트하고 있는 사이트는 radarjuso.com입니다.

카테고리형 사이트의 색인과 크롤링 구조를 다시 설계한 이유

austin — Fri, 16 Oct 2026 02:25:46 +0000

페이지를 만들었다고 자동으로 색인되는 건 아니었습니다

카테고리형 웹사이트를 운영하면서 처음에는 페이지를 만들고 사이트맵에 넣으면 검색엔진이 자연스럽게 크롤링하고 색인할 거라고 생각했습니다.

실제로는 그렇지 않았습니다.

페이지는 정상적으로 열리고 내부 링크도 존재했지만, 일부 카테고리는 오랫동안 색인되지 않거나 크롤링 우선순위가 낮아 보이는 경우가 있었습니다.

그때부터 단순히 페이지 수를 늘리는 것보다 검색엔진이 사이트 구조를 얼마나 쉽게 이해할 수 있는지가 더 중요하다고 보기 시작했습니다.

먼저 카테고리 구조부터 다시 확인했습니다

제가 운영하는 레이더 주소모음은 여러 웹사이트를 카테고리별로 정리해서 보여주는 주소모음·주소안내 서비스입니다.

사이트는 radarjuso.com입니다.

처음에는 카테고리를 세분화할수록 사용자에게 더 많은 선택지를 줄 수 있다고 생각했습니다.

하지만 페이지가 늘어나면서 비슷한 검색 의도를 가진 카테고리가 생기기 시작했고, 제목이나 설명에서도 비슷한 키워드가 반복됐습니다.

예를 들어 여러 페이지가 동시에 주소모음, 사이트모음, 최신주소안내 같은 표현을 강하게 사용하면 각 페이지가 어떤 역할을 하는지 모호해질 수 있다고 판단했습니다.

그래서 먼저 페이지마다 검색 의도를 다시 나눴습니다.

모든 페이지에 같은 키워드를 넣지 않았습니다

예전에는 주요 키워드를 최대한 많은 페이지에 넣는 게 좋다고 생각했습니다.

운영하면서는 오히려 반대로 바뀌었습니다.

메인 페이지는 사이트 전체의 역할을 설명하고, 각 카테고리 페이지는 해당 분야에 맞는 검색 의도를 담당하도록 분리했습니다.

즉,

홈 → 전체 주소모음 서비스 설명

카테고리 → 특정 분야 사이트 탐색

상세 페이지 → 개별 사이트 정보 및 주소 확인

처럼 페이지의 역할을 나눴습니다.

예를 들어 모든 카테고리에서 단순히 주소모음, 링크모음만 반복하는 대신, AI 카테고리는 AI 사이트 탐색, 커뮤니티 카테고리는 커뮤니티 사이트 탐색처럼 페이지별 중심 주제를 구분하는 방식입니다.

실제로 레이더에 적용한 변경사항

구조를 분석하는 것에서 끝내지 않고 radarjuso.com에 몇 가지 변경을 직접 적용했습니다.

1. 메인 페이지와 카테고리 페이지의 역할을 분리했습니다

메인 페이지에서는 레이더 주소모음이 어떤 서비스인지, 사용자가 어떻게 카테고리를 탐색하는지를 설명하는 데 집중했습니다.

반대로 개별 카테고리 페이지에서는 사이트 전체를 반복해서 설명하기보다 해당 카테고리를 찾는 사용자가 실제로 궁금해할 내용을 중심으로 구성했습니다.

결과적으로 모든 페이지가 같은 키워드를 놓고 경쟁하는 구조를 줄이는 방향으로 바꿨습니다.

2. 카테고리별 핵심 키워드를 따로 정했습니다

처음에는 여러 페이지에서 주소모음, 링크모음, 최신주소 같은 공통 키워드를 비슷하게 사용했습니다.

이후에는 공통 키워드는 사이트 전체 브랜드와 연결하고, 개별 카테고리에는 해당 분야의 검색어를 더 강하게 배치했습니다.

예를 들어 AI 관련 페이지라면 AI 사이트 추천, AI 툴 모음, 유용한 AI 사이트처럼 실제 카테고리 의도와 맞는 표현을 중심으로 잡는 방식입니다.

즉, 공통 키워드를 없앤 것이 아니라 페이지마다 우선순위를 다르게 준 것에 가깝습니다.

3. 내부 링크를 무조건 많이 넣는 방식을 줄였습니다

예전에는 관련성이 조금이라도 있으면 다른 카테고리 링크를 추가하는 식으로 구성했습니다.

지금은 내부 링크를 넣을 때 사용자가 다음에 어떤 페이지를 볼 가능성이 있는지를 먼저 생각합니다.

기본 흐름은 다음처럼 단순화했습니다.

메인 → 카테고리 → 개별 사이트 → 관련 카테고리

반대로 현재 페이지와 직접적인 관련성이 낮은 카테고리까지 무리하게 연결하는 방식은 줄였습니다.

4. 사이트맵에 실제 정식 URL만 유지했습니다

사이트맵도 다시 확인했습니다.

검색에 노출시키려는 실제 페이지가 포함되어 있는지, 불필요하거나 잘못된 URL이 들어가 있지 않은지 확인하고 메인 페이지와 주요 카테고리 URL을 기준으로 관리했습니다.

제가 여기서 배운 건 사이트맵을 제출하는 것과 좋은 크롤링 구조를 만드는 것은 전혀 다른 작업이라는 점입니다.

사이트맵은 URL을 알려줄 뿐이고, 어떤 페이지가 중요한지는 결국 내부 구조와 콘텐츠를 통해 다시 전달해야 했습니다.

5. 카테고리 진입 방식을 더 단순하게 만들었습니다

사용자가 첫 화면에서 너무 많은 링크를 마주하면 선택이 오히려 어려워질 수 있었습니다.

그래서 바로 개별 사이트를 전부 보여주는 것보다,

먼저 카테고리를 선택하고 → 그 안에서 관련 사이트를 탐색하는 방식

을 더 명확하게 보여주는 쪽으로 정리했습니다.

현재 레이더에서 계속 유지하려는 핵심 탐색 흐름도 이것입니다.

카테고리 선택 → 관련 사이트 탐색 → 여러 선택지 비교 → 필요한 주소 확인

6. 최신주소안내를 별도의 검색 의도로 봤습니다

이 부분은 운영하면서 생각보다 중요했습니다.

사이트를 검색하는 사용자 중에는 새로운 웹사이트를 찾는 사람도 있지만, 이미 알고 있는 사이트의 현재 주소를 확인하려는 사람도 있습니다.

그래서 사이트 발견과 최신주소 확인을 완전히 같은 검색 의도로 취급하지 않았습니다.

페이지 문구에서도 단순히 “사이트를 모아놓았다”는 설명만 반복하지 않고, 기존에 사용하던 사이트를 다시 찾거나 변경된 주소를 확인하는 목적까지 구분해서 설명하기 시작했습니다.

내부 링크도 크롤링 경로를 기준으로 정리했습니다

내부 링크 역시 많이 넣는 것보다 구조가 중요했습니다.

모든 페이지에서 모든 카테고리로 연결하는 대신, 상위 카테고리에서 관련 하위 페이지로 이동하고 상세 페이지에서는 다시 관련 카테고리로 돌아갈 수 있도록 흐름을 정리했습니다.

현재 레이더에서는 기본적으로 다음 구조를 중요하게 보고 있습니다.

메인 페이지 → 카테고리 → 관련 사이트 → 다른 관련 카테고리

사용자에게도 자연스럽고, 검색엔진 입장에서도 중요한 페이지와 페이지 간 관계를 파악하기 쉬운 구조를 만드는 게 목표였습니다.

사이트맵도 단순 제출에서 끝내지 않았습니다

사이트맵을 제출했다고 해서 모든 URL이 동일하게 처리되는 것도 아니었습니다.

그래서 사이트맵에는 실제로 검색에 노출시키고 싶은 정식 URL만 포함시키고, 존재하지 않거나 중복되는 주소가 섞이지 않는지 계속 확인했습니다.

또 카테고리 URL이 내부 링크에서 실제로 연결되어 있는지도 같이 확인했습니다.

결국 사이트맵은 크롤러에게 URL 목록을 알려주는 역할이고, 사이트 전체의 정보 구조까지 대신 만들어주는 것은 아니었습니다.

색인 문제를 보면서 가장 많이 바뀐 생각

운영 초반에는 색인이 늦으면 콘텐츠를 더 추가하거나 키워드를 늘리는 쪽부터 생각했습니다.

지금은 먼저 아래를 확인합니다.

이 페이지가 사이트 안에서 명확한 역할을 가지고 있는가
다른 페이지와 검색 의도가 과도하게 겹치지 않는가
내부 링크를 통해 정상적으로 접근할 수 있는가
사이트맵에 올바른 URL이 포함되어 있는가
사용자가 실제로 이 페이지에서 얻을 정보가 있는가

결국 색인과 크롤링 문제는 단순한 기술 설정만의 문제가 아니라 정보 구조와 콘텐츠 역할이 같이 연결된 문제에 가까웠습니다.

제가 이런 구조를 실제로 적용하면서 계속 테스트하고 있는 사이트가 레이더 주소모음 radarjuso.com입니다.

카테고리형 서비스나 디렉터리를 운영하고 있다면 페이지를 더 만드는 것보다 먼저 검색엔진과 사용자가 모두 이해할 수 있는 구조인지, 그리고 실제로 각 페이지가 서로 다른 역할을 가지고 있는지부터 확인해보는 게 꽤 중요하다고 느끼고 있습니다.

처음에는 카테고리가 많아지는 게 좋은 일이라고 생각했습니다.

austin — Fri, 09 Oct 2026 06:11:52 +0000

처음에는 카테고리가 많아지는 게 좋은 일이라고 생각했습니다.

페이지가 늘어나면 다룰 수 있는 검색어도 많아지고, 사용자가 선택할 수 있는 범위도 넓어질 거라고 봤습니다.

제가 운영하고 있는 **레이더(Radar)**도 처음에는 이런 방식으로 확장했습니다.

레이더는 여러 웹사이트를 카테고리별로 정리해서 보여주는 주소안내·주소모음 서비스이고, 현재 radarjuso.com에서 운영하고 있습니다.

그런데 카테고리가 늘어나기 시작하면서 예상하지 못했던 문제가 생겼습니다.

서로 다른 페이지인데 비슷한 키워드를 쓰고 있었습니다

예를 들어 AI 관련 페이지를 만들면서 다음과 같은 표현을 사용했습니다.

유용한 AI 사이트
AI 사이트 추천
AI 툴 모음
AI 서비스 모음

처음에는 비슷한 검색어를 여러 페이지에 나눠서 사용하는 게 괜찮아 보였습니다.

하지만 콘텐츠가 쌓이면서 어떤 페이지가 어떤 검색어를 중심으로 가져가야 하는지 점점 애매해졌습니다.

제가 콘텐츠를 작성할 때조차

“이 키워드는 기존 페이지에서도 사용하지 않았나?”

라는 생각을 자주 하게 됐습니다.

페이지 수는 늘었는데 각 페이지의 역할은 오히려 흐려지고 있었습니다.

그래서 페이지마다 한 가지 역할을 먼저 정했습니다

이후부터는 새 페이지를 만들기 전에 먼저 질문 하나를 던지고 있습니다.

이 페이지를 찾는 사람은 정확히 무엇을 원하는가?

예를 들어 AI 관련 페이지라면 단순히 AI라는 큰 주제로 묶지 않고, 사용자가 새로운 서비스를 발견하려는지, 무료 도구를 찾으려는지, 여러 서비스를 비교하려는지를 먼저 봅니다.

커뮤니티 역시 마찬가지였습니다.

온라인 커뮤니티, 커뮤니티 사이트 추천, 인기 커뮤니티처럼 표현은 비슷해도 실제로 원하는 결과는 조금씩 다를 수 있습니다.

그래서 지금은 키워드부터 정하는 대신 페이지의 검색 의도부터 정하고 그다음 키워드를 선택하는 방식으로 바꿨습니다.

비슷한 페이지는 합치기도 했습니다

페이지를 많이 만드는 것이 항상 좋은 것은 아니었습니다.

내용을 작성해보니 설명이 거의 비슷해지는 두 페이지가 있다면 억지로 따로 유지하기보다 하나로 합치는 편이 더 자연스러운 경우도 있었습니다.

실제로 운영하면서는 다음 기준을 자주 보고 있습니다.

두 페이지의 검색 목적이 정말 다른가?
사용자에게 서로 다른 결과를 보여줄 수 있는가?
설명을 작성했을 때 내용이 반복되지 않는가?
하나의 페이지로 합쳤을 때 오히려 더 이해하기 쉬운가?

이 질문에 명확하게 답하기 어렵다면 페이지를 분리할 이유가 약하다고 판단하고 있습니다.

내부 링크 방식도 바꿨습니다

처음에는 내부 링크가 많을수록 좋을 것 같아서 가능한 페이지들을 서로 연결하려고 했습니다.

그런데 실제로 읽어보면 관련성이 약한 링크까지 들어가면서 본문이 복잡해졌습니다.

그래서 지금은 비슷한 키워드를 가진 페이지를 무조건 연결하는 게 아니라, 사용자가 다음으로 궁금해할 가능성이 높은 페이지만 연결하는 방향으로 바꾸고 있습니다.

SEO를 위해 링크를 넣는다는 생각보다 사용자의 다음 행동을 기준으로 판단하는 방식입니다.

Radar에서는 이렇게 정리하고 있습니다

현재 radarjuso.com에서는 AI, 커뮤니티, 구인구직, 해외직구, 금융·재테크 등 서로 다른 목적의 사이트를 각각의 카테고리로 나누고 있습니다.

레이더의 기본 흐름은 단순합니다.

카테고리 선택 → 관련 사이트 탐색 → 여러 사이트 비교 → 필요한 주소 확인

그리고 기존에 이용했던 사이트를 다시 찾아야 하는 경우를 위해 최신주소안내 역할도 함께 가져가고 있습니다.

하지만 운영하면서 느낀 건 카테고리를 많이 만드는 것보다 각 카테고리가 왜 존재하는지 설명할 수 있는 구조가 훨씬 중요하다는 점입니다.

지금 새 페이지를 만들기 전에 확인하는 것

현재는 카테고리 페이지를 추가하기 전에 최소한 다음 네 가지를 확인합니다.

기존 페이지와 검색 의도가 겹치지 않는가
이 페이지에서만 제공할 수 있는 정보가 있는가
사용자가 카테고리 이름만 보고 목적을 이해할 수 있는가
기존 페이지와 자연스럽게 연결할 이유가 있는가

이 기준을 적용하고 나니 예전처럼 페이지를 빠르게 늘리지는 않게 됐습니다.

대신 페이지별 역할은 훨씬 명확해졌습니다.

처음에는 웹 디렉터리니까 카테고리가 많을수록 좋다고 생각했는데, 직접 운영해보니 오히려 페이지를 만들지 않는 판단도 SEO 구조의 중요한 부분이라는 걸 알게 됐습니다.

비슷한 콘텐츠 중심 사이트를 운영해보신 분들은 카테고리 페이지끼리 검색 의도가 겹치기 시작했을 때 통합하는 편인지, 아니면 더 세분화해서 차별화하는 편인지 궁금합니다.

카테고리형 웹사이트를 만들면서 직접 겪은 SEO와 탐색 구조 문제

austin — Tue, 06 Oct 2026 03:12:31 +0000

카테고리형 웹사이트를 만들면서 직접 겪은 SEO와 탐색 구조 문제

처음 레이더(Radar)를 만들 때는 구조가 꽤 단순할 거라고 생각했습니다.

사이트를 분야별로 나누고, 각 카테고리에 관련 웹사이트를 넣으면 끝이라고 봤습니다. 실제로 초반에는 그렇게 만들었습니다.

그런데 사이트가 조금씩 커지면서 예상하지 못했던 문제가 계속 생겼습니다.

현재 레이더는 radarjuso.com에서 운영하고 있습니다.

사이트가 늘어나자 카테고리가 애매해지기 시작했습니다

처음에는 AI, 커뮤니티, 구인구직처럼 큰 카테고리만 만들어도 충분했습니다.

그런데 사이트가 늘어나면서 어디에 넣어야 할지 애매한 경우가 생겼습니다.

예를 들어 어떤 서비스는 AI 도구이면서 동시에 생산성 도구이기도 했고, 어떤 커뮤니티는 특정 분야 정보 사이트 역할까지 하고 있었습니다.

처음에는 여러 카테고리에 같이 넣어보기도 했습니다.

하지만 그렇게 하니 사용자가 비슷한 사이트를 계속 보게 되고, 페이지마다 내용도 점점 겹치기 시작했습니다.

그래서 어느 순간부터는 “이 사이트가 어떤 종류인가?”보다 “사람들이 이 사이트를 어떤 목적으로 찾을까?”를 먼저 보기 시작했습니다.

그렇게 기준을 바꾸고 나니 정리가 조금 쉬워졌습니다.

AI 페이지에서는 유용한 AI 사이트, 구인구직에서는 구인구직 사이트, 커뮤니티에서는 온라인 커뮤니티처럼 사용 목적을 기준으로 페이지를 나누게 됐습니다.

키워드를 많이 넣는다고 검색 구조가 좋아지지는 않았습니다

초반에는 한 페이지에 관련 키워드를 많이 넣는 것이 좋을 거라고 생각했습니다.

예를 들어 AI 페이지라면 AI 사이트, AI 도구, AI 플랫폼, 무료 AI 등 여러 표현을 최대한 많이 넣었습니다.

그런데 페이지가 늘어나면서 비슷한 키워드가 여러 페이지에 반복되기 시작했습니다.

어떤 페이지를 어떤 키워드로 가져가야 할지 저부터 헷갈렸습니다.

그래서 지금은 한 페이지가 담당할 핵심 주제를 먼저 정하고, 나머지 표현은 그 주제를 설명하는 수준으로만 넣고 있습니다.

이 방식으로 바꾸니 콘텐츠 작성할 때도 훨씬 편해졌습니다.

첫 화면에 너무 많은 걸 보여줬다가 다시 줄였습니다

초기에는 방문자가 선택할 수 있는 게 많으면 좋을 거라고 생각해서 첫 화면에 카테고리와 링크를 많이 보여주려고 했습니다.

그런데 실제로 보면 정보가 많은 만큼 어디부터 눌러야 할지 애매해졌습니다.

특히 모바일에서는 더 복잡하게 느껴졌습니다.

그래서 지금은 먼저 카테고리를 고르게 하고, 그다음 관련 사이트를 보여주는 방식으로 정리하고 있습니다.

현재 제가 가장 중요하게 보는 흐름은 단순합니다.

카테고리 선택 → 관련 사이트 확인 → 여러 선택지 비교 → 사이트 이동

사용자가 처음 들어왔을 때 “여기서 뭘 해야 하지?”라는 생각이 들지 않게 만드는 게 목표입니다.

내부 링크도 많이 넣었다가 다시 정리했습니다

SEO 때문에 내부 링크를 늘려야 한다는 생각으로 초반에는 관련 페이지를 최대한 많이 연결하려고 했습니다.

그런데 링크가 많아지니 오히려 본문 흐름이 끊겼습니다.

사용자 입장에서는 지금 보고 있는 내용과 크게 상관없는 페이지까지 계속 추천받는 느낌이었습니다.

그래서 지금은 실제로 다음 행동으로 이어질 가능성이 높은 페이지 위주로 연결하고 있습니다.

예를 들어 AI 사이트를 보는 사람이 커뮤니티나 다른 온라인 도구도 같이 볼 가능성이 있다면 연결하지만, 단순히 내부 링크 수를 늘리기 위한 링크는 줄이는 식입니다.

사람들이 다시 들어오는 이유도 따로 필요했습니다

운영하면서 또 하나 알게 된 건, 디렉터리 사이트는 한 번 필요한 링크를 찾으면 다시 들어올 이유가 약하다는 점이었습니다.

이 문제를 해결하려고 최신주소안내라는 역할을 같이 넣기 시작했습니다.

예전에 사용했던 사이트를 다시 찾거나, 기존 주소로 접속이 안 될 때 다시 확인할 수 있게 하는 방식입니다.

이 기능은 신규 사이트를 발견하는 것과는 조금 다른 사용 목적이지만, 실제 재방문 이유를 만드는 데는 더 직접적이라고 느꼈습니다.

지금은 이 네 가지를 계속 보고 있습니다

레이더를 운영하면서 지금 가장 많이 확인하는 건 다음입니다.

사용자가 원하는 카테고리를 바로 찾는지
페이지마다 주제가 겹치지 않는지
관련 사이트를 비교하기 쉬운지
다시 방문할 이유가 있는지

현재 구조는 radarjuso.com에서 확인할 수 있습니다.

처음에는 단순한 링크 디렉터리라고 생각했는데, 직접 운영해보니 카테고리 하나를 나누는 기준부터 내부 링크를 어디까지 연결할지까지 계속 수정하게 되는 프로젝트였습니다.

비슷한 형태의 사이트를 만들어본 분들이라면, 콘텐츠가 늘어나기 시작했을 때 카테고리 구조와 검색 기능 중 어느 쪽을 먼저 손보셨는지 궁금합니다.

카테고리형 웹사이트를 만들면서 배운 SEO와 탐색 구조 설계

austin — Tue, 06 Oct 2026 03:01:22 +0000

카테고리형 웹사이트를 만들면서 배운 SEO와 탐색 구조 설계

웹사이트에 콘텐츠가 많아질수록 단순히 페이지를 늘리는 것보다 어떻게 분류하고, 어떤 검색 의도를 각 페이지에 맡길 것인가가 더 중요해지는 것 같습니다.

제가 운영하고 있는 레이더(Radar)도 이런 고민에서 시작한 프로젝트입니다.

레이더는 여러 웹사이트를 분야별로 정리해서 사용자가 필요한 사이트를 보다 쉽게 탐색할 수 있도록 만든 주소안내·주소모음 서비스입니다.

현재는 radarjuso.com에서 운영하고 있습니다.

처음에는 단순한 디렉터리라고 생각했습니다

웹 디렉터리의 기본 구조는 단순합니다.

사이트를 모으고, 카테고리를 만들고, 사용자가 원하는 링크를 선택하게 하면 됩니다.

하지만 실제로 콘텐츠가 늘어나기 시작하면 문제가 생깁니다.

카테고리가 너무 넓으면 서로 다른 검색 의도가 한 페이지에 섞이고, 너무 세분화하면 사용자가 원하는 정보를 찾기 위해 여러 단계를 이동해야 합니다.

결국 중요한 건 링크의 개수가 아니라 정보 구조와 탐색 비용이었습니다.

카테고리는 검색 의도를 기준으로 나누기

현재 Radar에서는 카테고리 이름 자체보다 사용자가 왜 해당 페이지를 찾는지를 더 중요하게 보고 있습니다.

예를 들어:

AI → 유용한 AI 사이트
커뮤니티 → 온라인 커뮤니티
구인구직 → 구인구직 사이트
해외직구 → 해외직구 사이트

처럼 각 페이지가 담당하는 검색 의도를 최대한 명확하게 분리하는 방식입니다.

SEO 측면에서도 한 페이지가 너무 많은 키워드를 동시에 노리는 것보다, 하나의 명확한 주제를 가지고 관련 검색어를 자연스럽게 확장하는 구조가 관리하기 훨씬 편했습니다.

검색 유입만큼 중요한 건 탐색 UX

SEO로 사용자를 데려오는 것과, 사이트 안에서 원하는 정보를 찾게 만드는 것은 완전히 다른 문제였습니다.

사용자가 검색 결과를 통해 들어왔는데 어디를 클릭해야 할지 바로 이해하지 못한다면 페이지 수가 많아도 큰 의미가 없습니다.

그래서 Radar에서는 기본적으로 다음 흐름을 중요하게 보고 있습니다.

카테고리 선택 → 관련 사이트 탐색 → 여러 선택지 비교 → 필요한 사이트 확인

사이트 이름을 정확히 알고 있는 사용자는 검색엔진에서 바로 찾으면 됩니다.

하지만 “어떤 AI 사이트가 있지?”, “사용할 만한 커뮤니티가 뭐가 있지?”처럼 선택지를 먼저 보고 싶은 사용자에게는 카테고리형 탐색 구조가 더 잘 맞을 수 있습니다.

내부 링크도 단순 연결보다 맥락이 중요했습니다

카테고리가 많아지면 내부 링크도 자연스럽게 증가합니다.

이때 모든 페이지를 무조건 서로 연결하는 것보다, 검색 의도와 사용 목적이 가까운 페이지를 자연스럽게 이어주는 편이 사용자 경험 측면에서도 더 낫다고 보고 있습니다.

예를 들어 AI 관련 사이트를 보고 있는 사용자가 다음으로 관심을 가질 만한 커뮤니티나 생산성 관련 리소스를 보여주는 식입니다.

결국 내부 링크도 SEO를 위한 구조이면서 동시에 사용자의 다음 행동을 설계하는 UX 요소라고 생각합니다.

지금 가장 중요하게 보는 네 가지

현재 Radar를 운영하면서 가장 중요하게 보고 있는 부분은 다음 네 가지입니다.

Search Intent — 페이지마다 명확한 검색 목적을 부여하기
Information Architecture — 콘텐츠가 늘어나도 구조가 복잡해지지 않게 만들기
Discoverability — 사용자가 몰랐던 사이트도 자연스럽게 발견하게 만들기
Return Visits — 한 번 방문하고 끝나는 서비스가 되지 않게 하기

실제 구조는 radarjuso.com에서 확인할 수 있습니다.

웹 디렉터리처럼 단순해 보이는 서비스도 규모가 커질수록 결국 SEO, taxonomy, internal linking, UX가 서로 연결되는 문제라는 걸 계속 느끼고 있습니다.

비슷한 카테고리형 서비스를 만든다면 여러분은 검색 기능, 카테고리 구조, 추천 시스템, 내부 링크 중 어떤 요소를 가장 먼저 고도화할 것 같나요?

웹사이트를 찾는 과정 자체를 제품으로 만들었습니다 — Radar 개발 이야기

austin — Wed, 30 Sep 2026 03:38:57 +0000

웹사이트를 찾는 과정 자체를 제품으로 만들었습니다 — Radar 개발 이야기

웹서비스를 만들다 보면 거창한 문제보다 반복되는 작은 불편에서 아이디어가 시작될 때가 있습니다.

제가 Radar를 만들게 된 이유도 비슷했습니다.

인터넷에는 정말 많은 웹사이트가 있지만, 막상 필요한 사이트를 찾으려고 하면 다시 검색부터 시작하게 됩니다. 예전에 사용했던 사이트 이름이 기억나지 않기도 하고, 같은 분야의 여러 서비스를 비교하려면 검색 결과를 계속 오가야 하는 경우도 많습니다.

그래서 이런 생각을 했습니다.

“검색 결과를 계속 돌아다니지 않고, 필요한 분야의 사이트를 한곳에서 탐색할 수 있다면 어떨까?”

그 생각에서 시작한 프로젝트가 Radar — radarjuso.com입니다.

Radar가 해결하려는 문제

Radar는 단순히 URL을 나열하는 링크 페이지를 목표로 하지 않았습니다.

제가 만들고 싶었던 것은 사용자가 사이트 이름을 정확히 몰라도 먼저 목적을 선택하고 → 관련 사이트를 탐색하고 → 여러 선택지를 비교할 수 있는 구조였습니다.

현재 Radar에서는 서로 성격이 다른 웹사이트들을 카테고리별로 구분해서 살펴볼 수 있습니다.

예를 들면:

유용한 AI 사이트
온라인 커뮤니티
구인구직 사이트
해외직구 사이트
금융·재테크 관련 서비스
영화·드라마·웹툰 등 다양한 웹 콘텐츠 카테고리

이런 식으로 사용자의 검색 목적을 먼저 나눈 뒤 그 안에서 관련 사이트를 확인할 수 있도록 구성하고 있습니다.

프로젝트는 radarjuso.com에서 직접 확인할 수 있습니다.

링크가 많다고 좋은 디렉터리는 아니었습니다

처음 이런 형태의 서비스를 생각했을 때 가장 쉬운 방법은 가능한 한 많은 링크를 한 화면에 보여주는 것이었습니다.

하지만 실제로 만들어보면 문제가 생깁니다.

링크가 많아질수록 사용자는 오히려 어디를 봐야 할지 모르게 됩니다.

결국 중요한 것은 링크의 수가 아니라 정보 구조였습니다.

그래서 Radar에서는 다음 흐름을 중요하게 보고 있습니다.

카테고리 선택 → 관련 사이트 탐색 → 선택지 비교 → 원하는 사이트 이동

사용자가 처음부터 정확한 사이트명을 알고 있어야 하는 구조가 아니라, “AI 도구가 필요하다”, “커뮤니티를 찾고 있다”, “구인구직 사이트를 보고 싶다” 같은 목적에서 출발할 수 있도록 만드는 것입니다.

검색 의도도 카테고리마다 다르게 봤습니다

개발하면서 흥미로웠던 부분 중 하나는 카테고리마다 사용자가 원하는 것이 완전히 다르다는 점이었습니다.

AI 카테고리에 들어오는 사람은 새로운 도구를 발견하고 싶을 수 있고, 구인구직 페이지를 찾는 사람은 실제 채용 사이트를 빠르게 비교하고 싶을 수 있습니다.

따라서 모든 페이지를 동일한 템플릿과 동일한 설명으로 만들기보다 각각의 카테고리가 담당하는 검색 의도(Search Intent)를 분리하는 것이 중요하다고 봤습니다.

예를 들면:

AI
→ 유용한 AI 사이트 / AI 툴 모음 / AI 사이트 추천

커뮤니티
→ 온라인 커뮤니티 / 커뮤니티 사이트 추천

구인구직
→ 구인구직 사이트 / 취업 사이트

처럼 실제 사용자가 찾는 목적을 기준으로 페이지의 역할을 구분하는 방식입니다.

“다시 찾는 문제”도 해결하고 싶었습니다

또 하나 자주 발생하는 문제가 있습니다.

“전에 사용했던 그 사이트 주소가 뭐였지?”

인터넷 서비스를 오래 이용하다 보면 북마크를 하지 않은 사이트를 다시 찾는 일이 생각보다 많습니다.

일부 웹사이트는 주소가 변경되기도 하기 때문에 Radar에서는 단순한 사이트 발견뿐 아니라 주소안내와 최신주소안내라는 역할도 같이 가져가고 있습니다.

그래서 제가 보는 Radar의 핵심 역할은 다음 네 단계입니다.

분류 → 탐색 → 비교 → 주소 확인

검색엔진을 대체하는 것이 아니라, 검색을 시작하기 전에 사용할 수 있는 웹사이트 탐색 레이어에 조금 더 가깝습니다.

앞으로 더 개선하고 싶은 부분

현재도 계속 고민하고 있는 부분이 있습니다.

카테고리가 많아져도 복잡하지 않은 탐색 구조
사용자가 새로운 사이트를 자연스럽게 발견하는 방식
각 카테고리의 검색 의도를 더 명확하게 만드는 방법
단순 방문이 아니라 다시 찾아올 이유를 만드는 방법
많은 링크를 보여주면서도 정보 밀도를 과하게 높이지 않는 UX

디렉터리형 프로젝트는 겉으로 보면 단순해 보이지만, 실제로 만들어보니 정보 구조와 탐색 UX를 계속 개선해야 하는 제품이라는 생각이 들었습니다.

현재 제가 만들고 있는 결과물은 여기에서 확인할 수 있습니다.

Radar — https://radarjuso.com

개발자 입장에서 이런 종류의 디렉터리를 만든다면 여러분은 검색(Search), 카테고리(Category), 개인화(Personalization), 추천(Recommendation) 중 어떤 기능을 가장 먼저 강화할 것 같나요?

DEV Community: austin

웹 디렉터리 내부 검색 랭킹은 어떻게 설계할까? Radar Link Site 사례로 보는 검색 점수 구조

1. 단순 문자열 검색은 금방 한계가 생긴다

2. 검색 결과에 점수를 부여한다

3. 사이트 이름은 가장 강한 신호로 본다

4. 카테고리 검색은 별도로 생각해야 한다

5. 태그는 검색 결과의 정밀도를 높인다

6. 검색어 정규화가 생각보다 중요하다

7. 클릭 데이터를 검색 랭킹에 반영할 수 있다

8. 인기 편향을 막아야 한다

9. 최신성도 하나의 신호가 될 수 있다

10. 최종 점수 구조

11. 웹 디렉터리 검색은 검색엔진과 목적이 다르다

실제 프로젝트: Radar Link Site

Radar Link Site

마무리

webdev #javascript #search #seo

하나의 웹 디렉터리를 두 개의 사이트로 나눈 이유: 탐색과 설명은 같은 UI가 아니었다

문제는 데이터가 아니라 사용자 의도였다

빠른 탐색과 설명형 콘텐츠의 충돌

radarjuso.com: 빠른 탐색 중심

radarlinksite.com: 설명과 탐색을 연결

처음부터 두 사이트가 필요했던 것은 아니다

같은 내용을 복사하지 않는 것이 중요했다

페이지 역할을 먼저 정의하면 구현도 단순해진다

두 사이트를 운영하면서 얻은 가장 큰 교훈

webdev #architecture #ux #showdev

두 개의 웹사이트를 운영하면서 canonical과 메타데이터 구조를 다시 정리한 이유

같은 브랜드라도 페이지 역할은 분리해야 했습니다

canonical은 단순한 태그가 아니었습니다

메타데이터도 사이트마다 다르게 구성했습니다

실제로 두 사이트를 계속 개선하고 있습니다

레이더 주소모음 — radarjuso.com

Radar Link Site — radarlinksite.com

직접 확인해볼 수 있습니다

👉 레이더 주소모음 바로가기

👉 Radar Link Site 바로가기

webdev #seo #showdev #architecture

검색만으로는 새로운 웹사이트를 발견하기 어렵다고 느꼈습니다

Search와 Discovery는 다른 문제였습니다

그래서 Radar를 만들었습니다

검색도 함께 사용할 수 있습니다

새로운 사이트를 발견하는 과정도 중요합니다

직접 Radar에서 찾아보세요

👉 Radar에서 필요한 사이트 찾아보기

Radar — radarjuso.com 바로가기

검색 결과가 너무 많아서 웹 디렉터리를 다시 만들기 시작했습니다

Radar는 무엇인가요?

검색과 발견은 다른 문제였습니다

링크를 많이 모으는 것보다 분류가 중요했습니다

직접 확인해볼 수 있습니다

👉 Radar에서 필요한 사이트 찾아보기

주소모음 서비스를 만들면서 사이트 탐색 UX를 단순화한 방법

사이트를 먼저 보여주는 대신 카테고리를 먼저 보여줬습니다

카테고리마다 역할을 나눴습니다

검색과 탐색을 같은 기능으로 보지 않았습니다

내부 링크도 사용자 흐름에 맞췄습니다

주소모음 서비스도 결국 정보 구조 문제였습니다

카테고리 페이지끼리 검색 의도가 겹칠 때 바꾼 것들

문제는 페이지 수가 아니라 역할이었습니다

페이지마다 검색 의도를 분리했습니다

내부 링크도 같이 정리했습니다

최신주소는 별도 의도로 봤습니다

지금 적용하고 있는 방식

카테고리형 사이트의 색인과 크롤링 구조를 다시 설계한 이유

페이지를 만들었다고 자동으로 색인되는 건 아니었습니다

먼저 카테고리 구조부터 다시 확인했습니다

모든 페이지에 같은 키워드를 넣지 않았습니다

실제로 레이더에 적용한 변경사항

1. 메인 페이지와 카테고리 페이지의 역할을 분리했습니다

2. 카테고리별 핵심 키워드를 따로 정했습니다

3. 내부 링크를 무조건 많이 넣는 방식을 줄였습니다

4. 사이트맵에 실제 정식 URL만 유지했습니다

5. 카테고리 진입 방식을 더 단순하게 만들었습니다

6. 최신주소안내를 별도의 검색 의도로 봤습니다

내부 링크도 크롤링 경로를 기준으로 정리했습니다

사이트맵도 단순 제출에서 끝내지 않았습니다

최신주소안내도 검색 의도를 따로 봤습니다

색인 문제를 보면서 가장 많이 바뀐 생각

처음에는 카테고리가 많아지는 게 좋은 일이라고 생각했습니다.