Codex가 페이지를 연결하게 하세요 ── 모든 새 글이 역할을 갖도록

Codex를 사용해 고립된 페이지를 유용한 토픽 시스템으로 전환하세요: 페이지 역할을 정의하고, 문맥에 맞는 내부 링크를 제안하며, 모든 새 페이지에 독자 여정을 제공하세요.

페이지는 유용한 곳으로 이어져야 합니다

첫 트래픽 페이지에는 클릭을 얻는 것 이상의 역할이 필요합니다: 독자가 계속하고, 비교하고, 전환하고, 검증하도록 돕는 것. 내부 링크가 그 경로를 만듭니다.

완료의 정의: 추가, 제거 또는 나중에 생성할 문맥적 링크의 승인된 목록이 포함된 작은 토픽 맵.

45분 확보. 관련 URL 또는 초안 5~15개, 트래픽 미션, 첫 트래픽 페이지 인계를 가져오세요. 전체 도메인이 아닌 하나의 고객 문제부터 시작하세요.

Codex에 페이지 인벤토리 제공하기

트래픽 미션, 첫 트래픽 페이지, 이 URL 또는 로컬 파일을 읽어주세요: [목록].
토픽 시스템 맵 작성: 각 페이지의 방문자 역할, 허브 또는 전환 페이지,
문맥적 링크 제안 3~8개, 제안 앵커 텍스트 의미, 고립/중복 경고.
목적지가 독자의 다음 결정을 도울 때만 링크. 편집하지 말고, 링크를 추가하지 말고,
페이지를 발명하지 마세요.

먼저 작은 인벤토리 만들기

첫 토픽 시스템에 크롤러는 필요 없습니다. 관련 페이지 또는 초안 5~15개의 표를 만드세요:

url_or_draft,title,current_visitor_job,primary_question,next_action,confirmed

새 사이트는 계획된 URL을 사용하세요. 기존 사이트는 전체 도메인이 아닌 하나의 토픽부터 시작하세요. 목표는 사이트 전체에서 무언가를 자동화하기 전에 유용한 독자 여정을 연결하는 것입니다.

독자 여정을 드러내는 인벤토리 구축하기

부기 예시에서 첫 인벤토리는 4개 행일 수 있습니다:

이것은 이미 토픽 시스템입니다. 100개 URL이 필요하지 않습니다. 각 행은 다른 결정을 가지며, 각 결정은 다음 링크에 존재 이유를 줍니다.

모든 링크에 독자 이유 주기

각 제안은 답해야 합니다: 소스 독자가 어디서 더 많은 도움이 필요한가, 목적지가 어떤 결정을 돕는가, 어떤 문구가 정직하게 설명하는가, 도착 후 무슨 일이 일어나는가?

제안된 각 내부 링크에 대해 링크 전 소스 문장, 제안된 링크 구문, 목적지 URL/초안,
독자 이유, 링크가 억지스러울 수 있는 경우 위험 메모를 보여주세요.
명확한 독자 이유가 없는 링크는 거부하세요.

좋음: 마감일 체크리스트가 전문가 도움이 언제 유용한지 설명한 후 부기 서비스 페이지로 링크. 나쁨: 모든 페이지가 키워드 밀집 앵커로 모든 페이지에 링크.

맥락에서 제안 검사하기

링크 제안에는 전체 소스 문장이 포함되어야 합니다. 비교하세요:

약한 소스: 디자이너용 부기에 대해 더 알아보기.
약한 앵커: 디자이너용 부기.
이유: SEO 내부 링크.

유용한 소스: 이 체크리스트의 기록이 매달 쌓이고 있다면, 디스커버리 콜이 가치 있는지
결정하기 전에 프리랜스 디자이너용 월간 부기에 무엇이 포함되는지 검토하세요.
유용한 앵커: 프리랜스 디자이너용 월간 부기에 포함되는 것.
이유: 독자는 서비스 적합성 페이지가 다음 결정에 도움이 되는 지점에 도달했습니다.

두 번째 버전은 키워드를 밀기 위해 존재하지 않습니다. 왜 목적지가 지금 관련이 있는지 독자에게 알려줍니다.

Codex가 일반적인 푸터형 링크 목록을 제안하면 이 수정 프롬프트를 사용하세요:

소스 문장, 독자 결정, 그 결정을 해결하는 목적지가 없는 모든 제안을 거부하세요.
이 토픽 맵에서 8개 이하의 링크를 유지하세요. 같은 앵커 텍스트를 재사용하거나
사이트 전체 삽입을 추천하지 마세요.

독자 필요로 링크 승인하기

각 제안에 대해 물어보세요: 이 섹션을 막 읽은 독자가 정말 그 다음 페이지를 원할까? 아니오라면 거부하세요. 그런 다음 Codex에 사이트 전체 자동 링크 삽입이 아닌 검토 가능한 페이지 차이를 요청하세요.

링크를 한 번에 한 페이지씩 적용하세요. 사이트 전체에 같은 앵커를 추가하는 스크립트를 실행하지 마세요. 맵이 누락된 역할을 드러내면 missing proof 또는 missing decision page로 기록하세요. 자동으로 만들지 마세요.

검토 가능한 링크 시트 만들기

맵을 승인한 후 Codex에 작은 변경 시트를 요청하세요:

승인된 토픽 시스템 맵을 읽어주세요. 승인된 각 링크에 대해 소스 URL 또는 파일,
현재 소스 문장, 제안된 수정 문장, 앵커 텍스트, 목적지, 독자 이유, 목적지가
라이브인지 확인을 제공하세요. 파일을 편집하지 말고, 링크를 삽입하지 말고,
내비게이션을 변경하지 말고, 페이지를 만들지 말고, 아무것도 게시하지 마세요.

한 번에 하나의 소스 페이지를 검토하세요. 독자처럼 목적지를 여세요. 암시된 다음 질문에 답하지 않으면 링크를 거부하세요. 목적지가 존재하지 않으면 소스 문장을 링크 없이 유지하고 누락된 페이지를 빈 URL이 아닌 향후 결정으로 기록하세요.

흔한 맵 실패 문제 해결하기

모든 것이 홈페이지를 가리킴. 인벤토리에 명확한 서비스, 제품 또는 결정 페이지가 없을 것입니다. 링크를 강요하기 전에 누락된 역할을 추가하세요.

모든 글이 모든 글에 링크. 각 특정 섹션 후에 독자가 어떤 링크를 선택할지 물어보세요. 그것을 유지하고 나머지를 제거하세요.

같은 앵커가 어디서나 반복됨. 독자가 클릭하는 이유를 중심으로 문장을 다시 쓰세요. 자연스러운 변형은 동의어 회전이 아닌 다른 맥락에서 나옵니다.

맵을 작은 독자 경로로 전환하기

편집을 요청하기 전에 화살표로 첫 버전을 그리세요:

체크리스트 질문
  -> 독자가 도움이 필요할 때 서비스 적합성 페이지
  -> 독자가 프로세스 세부 사항이 필요할 때 how-it-works 페이지
  -> 행동할 준비가 되었을 때만 연락 페이지

화살표는 사이트 계층이 아닌 독자 선택을 설명합니다. 서비스 적합성 페이지의 독자는 준비되지 않았다면 체크리스트로 돌아가야 할 수 있습니다. 그 링크는 유용합니다. 연락 페이지에서 모든 가이드로의 링크는 보통 그렇지 않습니다.

각 화살표에 대해 중단 조건을 쓰세요. 체크리스트→서비스 화살표는 서비스 페이지가 범위를 진술하지 않거나 예약 액션이 고장났을 때 중단합니다. how-it-works 화살표는 페이지가 계획에만 있을 때 중단합니다. 이것은 독자가 오늘 실제로 사용할 수 있는 것에 대해 맵을 정직하게 만듭니다.

스프레드시트뿐만 아니라 릴리스 후 링크 확인하기

승인된 편집자나 개발자가 링크를 추가한 후 데스크톱과 모바일에서 소스와 목적지를 여세요. 목적지가 로드되는지, 앵커가 문장에서 의미가 있는지, 목적지가 암시된 질문에 답하는지 확인하세요. topic-map-links.md에 소스 URL, 목적지 URL, 날짜, 검토자를 기록하세요. 내부 링크가 오래된 페이지를 가리키면 같은 검토 프로세스로 제거하세요. 기본적으로 홈페이지로 대체하지 마세요.

새 사이트와 기존 사이트가 같은 방법을 사용하는 방법

새 사이트는 계획된 페이지 경로로 맵을 만들 수 있습니다. 미구축 경로를 모두 PLANNED로 표시하고 라이브로 표시하지 마세요. 실제로 게시된 페이지 사이에서만 링크하고, 목적지가 준비될 때까지 미래 화살표를 맵에 유지하세요. 이것은 청사진이 야심 찼다는 이유만으로 새 사이트가 고장난 내부 링크로 출시되는 것을 방지합니다.

기존 사이트는 내비게이션이 올바르다고 가정하지 않고 현재 페이지를 나열하는 것부터 시작합니다. 서비스 페이지에 이미 20개의 링크가 있지만 페이지의 질문에 독자를 돕는 것은 하나도 없을 수 있습니다. 같은 인벤토리 열을 사용하고 한 번에 하나의 나쁜 링크를 교체하거나 제거하세요. 단일 토픽 맵 연습에서 전역 메뉴를 재설계하지 마세요.

승인 후에만 파일 또는 CMS 특정 인계 요청하기

소스와 목적지가 명확해지면 Codex가 정확한 구현 요청을 준비하게 할 수 있습니다:

승인된 링크 시트를 사용하세요. 리포지토리라면 무엇이든 변경하기 전에 정확한 페이지 파일과
제안된 줄 수준 편집을 나열하세요. CMS라면 소스 문장과 목적지 URL이 포함된 복사/붙여넣기
지침을 준비하세요. 링크를 문맥적으로 유지하고 문장이 작은 재작성을 필요로 하지 않는 한
기존 독자 대상 문구를 보존하세요. 편집, 게시, 배포, 전역 내비게이션 변경을 하지 마세요.

결과 차이 또는 CMS 변경 시트를 승인된 맵과 대조해 검토하세요. 링크는 콘텐츠 변경이며 새 문단과 같은 승인을 받을 자격이 있습니다.

완료 체크리스트

• [ ] 인벤토리에 제목과 URL뿐만 아니라 페이지 역할이 포함된다.
• [ ] 모든 제안 링크에 소스 문장과 독자 이유가 있다.
• [ ] 누락되었거나 무관한 목적지로의 링크를 거부했다.
• [ ] 사이트 전체 링크 스크립트가 아닌 승인된 변경 시트를 저장했다.
• [ ] 미구축 목적지를 조기 링크하는 대신 계획됨으로 표시했다.
• [ ] 각 승인된 링크 변경 후 라이브 소스와 목적지를 확인했다.

링크 변경 릴리스 노트 사용하기

사람이 작은 링크 변경을 승인한 후 다른 페이지 변경처럼 기록하세요. 간결한 노트는 앵커가 선택 사항처럼 보인다는 이유로 이후 편집자가 유용한 경로를 제거하는 것을 방지합니다:

링크 변경 날짜: [날짜]
소스 URL 및 문장: [정확한 맥락]
목적지 URL 및 독자 질문: [URL 및 암시된 다음 질문]
승인된 이유: [이 경로가 독자를 돕는 이유]
검증: [데스크톱/모바일 확인, 검토자, 결과]
롤백: [목적지가 변경되면 원래 문장 제거 또는 복원]

목적지가 나중에 리디렉션되거나, 부정확해지거나, 암시된 질문에 더 이상 답하지 않으면 노트를 다시 열고 의도적으로 링크를 교체하거나 제거하세요. 이것이 사이트가 성장해도 토픽 시스템이 읽기 쉽게 유지되고 상속된 앵커 더미가 되지 않는 방법입니다.

계획된 독자 경로에 아직 목적지가 없을 때 복구하기

맵에 빈 화살표가 있다고 링크를 지어내지 마세요. 소스 문장을 링크 없이 유용하게 유지하고, 목적지를 PLANNED로 표시하며, 누락된 페이지 질문을 다음 승인된 작업 큐에 추가하세요. 목적지가 결국 게시되면 맵을 다시 열고 실제로 암시된 다음 질문에 답하는지 테스트한 후에만 링크 변경 시트를 준비하세요. 이것은 방문자가 도달할 수 없는 도움을 약속하는 내비게이션이라는 새 사이트의 일반적인 실수를 방지합니다.

코스 맵

다음: Codex에 안전한 게시 체크리스트 제공하기.

저자: David Sinclair, Auspia 500개 이상 토픽 클러스터 담당 토픽 권위 전략가. David는 독자와 검색 엔진이 유용한 증거를 탐색하도록 돕는 토픽 시스템에 대해 씁니다.

![토픽 시스템 작업 패킷 워크플로우 다이어그램]()

이 과제에는 이 순서를 사용하세요: 실제 입력으로 시작하고, 증거를 확인하고, 검토 가능한 출력을 준비한 다음, 독자의 다음 단계를 선택하세요.