yan-skills
SEO와 독립 개발(independent development)을 하는 사람들을 위한 Agent Skills입니다. 웹사이트 구축, 키워드 선정, 외부 링크 발행, 데이터 조회, 복기 및 반복 개선에 이르는 전체 프로세스가 이 저장소 안에 있으며, 설치만 하면 바로 실행할 수 있습니다.
저자 Yan이 개인적으로 다듬고 실제 테스트하여 작동하는 스킬입니다. Claude Code, Codex CLI, Cursor뿐만 아니라 SKILL.md를 읽을 수 있는 모든 플랫폼과 호환됩니다. MIT 라이선스로 누구나 자유롭게 사용할 수 있습니다.
npx skills add yan-labs/yan-skills -g --all
이 스킬 모음이 해결하는 문제점
독립 웹사이트를 운영하는 사람들은 하루 일과가 대략 다음과 같습니다:
오전에는 새로운 방향을 구상하며, 먼저 해당 키워드가 트래픽 양이 있는지, 난이도가 높지 않은지 확인합니다. 전문 도구 사이트는 월 200달러에 달해 구매하기 어려워, 여러 개의 브라우저 탭을 열어 수동으로 비교 분석해야 합니다. 정오에는 키워드를 확정하고 웹사이트 구축을 시작합니다. 스캐폴딩(scaffolding), Cloudflare, 도메인, GA (Google Analytics), GSC (Google Search Console) 등 일련의 프로세스를 거치는데, 다음 번에 사이트를 만들 때도 똑같은 과정을 밟다 보면 같은 실수를 반복하게 됩니다. 오후에는 외부 링크를 발행해야 해서, 남들이 공유한 '무료 외부 링크 웹사이트 500개' 목록을 뒤지다가 처음 20개를 클릭해 보니 17개는 접속이 안 되거나, 2개는 가입 후 승인이 필요하고, 1개는 먼저 해당 사이트에 링크를 걸어야만 합니다. 저녁에는 GSC에 접속하여 '크롤링되었으나 색인에 포함되지 않음'이라는 메시지를 보고, 내용을 수정해야 할지 아니면 다시 제출해야 할지 알 수 없습니다.
3개월 후 다른 프로젝트로 넘어갔을 때, 위 모든 과정을 처음부터 다시 시작해야 합니다.
이 저장소가 없애고자 하는 것은 바로 '처음부터 다시 시작하는 과정'입니다. 이 스킬 모음은 위의 각 단계를 스크립트, 데이터 파일, 판단 규칙으로 고정화하여 AI Agent가 그대로 실행할 수 있도록 만듭니다.
세 가지 핵심 Skill과 하나의 보조 이미지 생성(生图) Skill로 구성되어 있으며, 역할 분담이 명확합니다:
| 관리 범위 | 한 줄 요약 |
|---|
rankup | 웹사이트의 전 생애 주기 | 키워드 선정부터 웹사이트 구축, 결제 시스템(Stripe / Anyway / PayPal) 연동 및 출시 후 성장까지; Anyway 스크립트와 Worker 검증 참고 포함 |
| ... | | |
소규모 게임의 일일 자동화는 game-opportunity의 collect-checklist와 decision-checklist 두 가지 모드를 통해 각각 10가지 수집 및 의사 결정 검증을 수행합니다; 상세 규칙은 모두 game-opportunity에 통합 관리됩니다. | | |
어떤 Skill을 사용해야 할까요?
이 스킬들 안에 무엇이 들어있는지 알 필요가 없습니다. 단순히 하고 싶은 일을 말하면 됩니다. 아래 표가 분배 역할을 합니다. 왼쪽 열은 실제로 입으로 내뱉는 말이며, 오른쪽 열은 로드해야 할 Skill입니다. 각 Skill 내부에는 또 한 겹의 '한 문장 → 어떤 능력 사용' 인덱스가 있어 들어가서도 추측할 필요가 없습니다.
| 당신이 아마 이렇게 말할 것입니다 | 이것을 사용하세요 |
|---|
| 「새 웹사이트를 만들고 싶다」「이 키워드로 할 수 있을까」「키워드를 골라줘」「요구사항을 파헤쳐 줘」 | rankup |
| ... | |
| 세 가지 혼동하기 쉬운 경계선: | |
- 데이터 조회하고 싶음 ≠ 브라우저를 직접 열기. 키워드, 트렌드, 경쟁사 데이터는 먼저
rankup / backlink에 이미 존재하는 스크립트가 있는지 확인해야 합니다. 정말로 로그인 상태(login state)가 필요하고, 스크립트나 어댑터(adapter)가 없을 때만 opencli를 사용합니다.
opencli는 기반 기술이지, 비즈니스가 아닙니다. 이것은
npx @yan-labs/rankup catalog semrush --json
npx @yan-labs/rankup capture semrush keyword-overview --keyword "photo signature resizer" --db us --out-dir .rankup/provider-audit/keyword-us
npx @yan-labs/rankup audit similarweb --manifest .rankup/provider-audit/similarweb.json --out-dir .rankup/provider-audit/live/similarweb --resume
3.31 변경 사항
SKILL.md의 설명(description)과 시작 정의를 재작성했습니다 (프로젝트 계획, 진행, 유지보수, .rankup/ 디렉토리 모두 로드됨). 첫 화면에 「강제 프로세스」 테이블이 추가되었습니다: 착수(开工), 진행(继续), 마일스톤(里程碑), 각 유형의 작업 전 필수 읽기 자료, 마무리 유지보수, 스킬 유지보수, .rankup/ 정리.- 진입 단계 섹션
references/playbooks/entry.md이 추가되었습니다: Trends에서 gpts 기본값으로 연결 → 사람이 수행 (지원) → AI 탐지(探针) → GEO / SEO 경로; gpts 판독표는 trends.md의 「〇·六」에 대한 유일한 판단 기준입니다 (임계값은 시작 값).
- 「유지보수」 섹션
references/maintenance.md과 /rankup doctor가 추가되었습니다; 새로운 스크립트 scripts/maintain/: doc-lint.mjs (링크 끊김 및 초과 검사), ref-scan.mjs (전체 스캔), split-doc.mjs (분할 및 링크 수정), rankup-doctor.mjs (.rankup/ 읽기 전용 진단).
- 초과 문서 분할 (메인 파일은 진입점과 판단 기준을 유지하고, 이전 파일명은 모두 진입점으로 보존):
lifecycle.md → lifecycle/stage-1…7, 그리고 provider-capabilities/, demand-sources/, playbooks/research/, playbooks/selection/, integrations/, cloudflare/ 하위 디렉토리가 추가되었습니다. 프로젝트 기록에 작성된 「lifecycle.md 단 N」은 새로운 인덱스를 통해 바로 접근할 수 있으며, 마이그레이션이 필요 없습니다.
- 기준 통일: KD는 검토 순서만 나열하고, 결제(支付)는 배포 방식에 따라 주 채널과 백업 채널을 선택하며,
rejected.md는 복구되어 테이블에서 제외되었고, journal/은 압축 가능한 흐름으로 변경되었습니다; 삭제된 game-opportunity와 skillsmp 참조를 제거했습니다.
3.0 변경 사항
- 메인 파일
rankup/SKILL.md의 길이가 979행에서 300행 이내로 축소되었습니다: 총 라우팅 테이블, 7개 단계별 각 하나의 하드 규칙, 레드라인 빠른 참조 및 세 가지 명령만 남았습니다; 실행 규율(执行纪律), 레드라인 세부 지침(红线细则), 사고 복기(事故复盘)는 모두 references/discipline.md로 이동되었습니다.
- 조사 방식이 어근 확장 트리로 변경되었습니다: 사용자가 제공하는 모든 단어는 어근이며, 먼저 직접 검색한 후 트리를 확장합니다 (최대 2단계); 기존 P2 「이 단어로 작업 가능한가」와 P3 「단어 확장」은 하나의 파이프라인으로 통합되었으며,
references/playbooks/research.md에서 확인할 수 있습니다.
- 도메인 연결(接入) 단계가 상장 전 마지막 단계(섹션 5)로 이동했습니다. 최종 확정 전에 블랙 히스토리 심사 게이트가 추가되었습니다; 플랫폼 연결은 「도메인 비관련 / 도메인 관련」 두 그룹으로 분리되었습니다.
references/monetization.md가 추가되었습니다: Stripe / PayPal / 광고 / 구독 / 스토어 등록에 대한 라우팅과 판단 기준만 작성했습니다.scripts/demand/suggest.mjs가 추가되었습니다: Google / Bing / DuckDuckGo의 드롭다운 자동 완성 기능을 제공하며, 순수 HTTP 기반으로 할당량(quota)이 없고 언어별로 --hl / --gl을 사용합니다.- 새로운 레드라인 규칙: 어떤 페이지에도 자리 표시자 링크 / 자리 표시자 문안 / 자리 표시자 이미지가 있어서는 안 됩니다 — Google은 이를 스팸 사이트로 판단합니다.
이 시스템이 커버하는 7단계 생명 주기
3.0 버전에서는 기존의 '0, 1, 2, 3, 4, 5, 6, 7, 7.5, 8, 9, 10' 총 12개 단계를 7단계로 재배열했습니다. 구(舊) 단계와 신(新) 단계의 비교표는 references/lifecycle.md 상단에 있으며, 프로젝트 내 기존의 .rankup/checks.md 파일은 이를 기준으로 변환하여 사용하므로 다시 작성할 필요가 없습니다.
| 단계 | 이름 | 출구 판정 기준 (한 문장) |
|---|
| 1 | 조사(Research) | 모든 키워드는 루트(root)입니다: 직접 검색 → 트리 확장 → 볼륨 측정 → 커뮤니티 검증 (Reddit / X / YouTube / B站 최근 14일) → SERP를 통해 의도 확인 → 수익화 가능성 산정; 각 키워드에 대해 진행 여부/중단 여부를 결정합니다. |
| ... | | |
flowchart LR
S1["1 조사"] --> S2["2 프로젝트 설정 및 포지셔닝"] --> S3["3 웹사이트 구축 및 개발"] --> S4["4 출시 전 SEO/GEO"]
S4 --> S5["5 출시 및 연동"] --> S6["6 외부 링크(Backlink)"] --> S7["7 수익화 및 모니터링"]
...
단계별 상세 내용:
1 조사: 키워드 루트 확장, 볼륨 측정 및 KD (Keyword Difficulty), 커뮤니티 검증, SERP 의도 확인, 경쟁사 수익화 분석, 수익화 가능성 산정
2 프로젝트 설정 및 포지셔닝: 트래픽 최우선 고려, 언어권 결정, 의도 → 형태 → 수익화 연결, '1'의 정의와 중단 조건을 명확히 작성
3 웹사이트 구축 및 개발: shadcn monorepo 초기화, 프라이빗 저장소 사용, Cloudflare 온디맨드 활성화, 도메인 예약, hello@ 이메일 주소 확보, 플레이스홀더 없음
...
모든 단계의 시작에는 '대조(對帳)'라는 고정된 활동이 있습니다 (원래 단계 0): "프로젝트가 현재 실제로 어디에 있는지"를 답변해야 하며, 답할 수 없다면 어떤 단계로도 진입할 수 없습니다. 이미 운영 중인 웹사이트는 현재 단계부터 연결하면 되며, 강제로 1단계부터 다시 시작할 필요는 없습니다.
각 단계에서 다음 단계로 넘겨야 할 것
7단계는 7개의 고립된 활동이 아니라, 하나의 인계 체인(handover chain)입니다. 1단계가 정한 목표 키워드 트리는 2단계로 넘어가 언어권과 형태를 결정하고, 3단계로 넘어가 페이지 템플릿에 맞춥니다. 4단계는 이를 기반으로 페이지별 볼륨 밀도와 TDK(Title, Description, Keywords)를 측정하며, 6단계의 외부 링크는 이를 목표로 삼고, 7단계는 순위 및 수익을 다시 이 체인에 귀속시킵니다. 어느 한 부분이라도 이 인계 과정을 놓치면 연결 고리가 끊어지고, 이후 단계들은 맞지 않는 목록을 가지고 계속 진행하게 됩니다.
flowchart TD
R["1 조사<br/>산출물: 키워드 루트 확장 + 의도 확인 + 커뮤니티 검증 + 링크 예산"] --> P["2 프로젝트 설정 및 포지셔닝<br/>트래픽에 따라 언어권과 형태 결정"]
P --> B["3 웹사이트 구축 및 개발<br/>페이지 템플릿을 각 키워드의 의도에 맞추고, 도메인 예약"]
...
각 단계의 끝에는 '다음 단계로 넘겨야 할 것' 표가 있습니다. 여기에는 전달물(deliverables), 다음 단계에서의 사용법, 누락 시 발생할 문제점 등이 명확히 적혀 있습니다. 이것은 장식이 아니며, references/lifecycle.md의 1단계부터 7단계까지 각 단계에 모두 존재합니다.
이 규칙에는 또 다른 절반이 파일들 사이에 숨어 있습니다: .rankup/keywords.md와 같이 여러 곳에서 참조되는 목록이 수정될 경우, 누가 이를 참조하고 있는지 먼저 찾아내야 합니다. 특히 판정 조건과 중단 조건 내의 참조를 주의해야 합니다. 실제로 발생했던 실수 사례는 다음과 같습니다: 목표 키워드 목록이 8개에서 4개로 축소되었지만, 다른 세 개의 파일의 통과/중단 판정 기준은 여전히 '이 8개 키워드'에 고정되어 있었습니다. 그 결과, 이미 제외된 키워드가 스스로 상위 20위에 진입하면 단계 목표 달성으로 오판되는 일이 발생했습니다. 참조되는 목록을 수정하기 전에는 반드시 누가 이를 참조하고 있는지 grep 명령어로 확인해야 합니다.
출시 전 필수 관문 (4단계, 미리보기 도메인 noindex)
4단계에서 가장 중요한 것은 이 9가지 항목(관문 0–6 + 4b + 4c)이며, 모두 미리보기 도메인(preview domain) 상에서 완료되어야 합니다. 각 항목마다 증거가 필요하며, 단순히 도구 목록을 확인하는 것으로는 안 됩니다. 도메인이 아직 확정되지 않았으므로 이 점검들은 도메인과 무관합니다:
| # | 점검 항목 | 입증할 것 |
|---|
| 0 | 사이트 식별자(Site Identity) | OG 메타데이터, 아이콘 세트, manifest.json 참조가 모두 실제 파일에 매칭됨 |
| ... | | |
명령을 실행했더라도 증거가 .rankup/ 폴더에 기록되지 않으면 통과로 간주하지 않습니다. 구두로 "문제없을 것 같다"거나 콘솔의 녹색 아이콘 하나는 증거가 될 수 없습니다. references/lifecycle.md 4단계 C 섹션 및 references/checklists.md 4단계를 참고하십시오. 페이지가 수정될 때마다 이 9가지 항목 전체를 다시 실행해야 하며, 수정된 두 줄만 재실행해서는 안 됩니다. | | |
일상 업무의 90%를 커버하는 세 가지 명령어
rankup check — '지금 무엇을 해야 하는지', '단계별로 진행하기'에 사용되는 유일한 액션입니다. references/checklists.md와 프로젝트의 .rankup/checks.md를 읽고, 통과하지 못한 첫 번째 단계를 찾아 실제 코드, 온라인 응답, 백엔드 데이터를 순차적으로 교차 확인하고 그에 따라 직접 수행합니다. 이 명령어는 가볍고 할당량(quota)이 없습니다. 업그레이드 판정 기준(이미 배포되었으나 audit.md가 없거나, 온라인 URL을 변경했음에도 검사를 거치지 않은 경우)에 해당하면 '이것은 더 이상 check가 아니라 review입니다'라고 명확히 알려줍니다.
rankup init — 프로젝트를 연결합니다. 신규 프로젝트에 적합하며, 오랫동안 진행되었지만 아직 프로젝트 메모리가 구축되지 않은 프로젝트(이것이 일반적인 경우입니다)에 더욱 적합합니다.
이 명령어는 package.json, 라우팅 목록, 배포 설정, git log를 읽고, 도메인 해석 가능 여부, Cloudflare 작동 여부, GSC 연결 여부, 결제 시스템 유무 등을 모두 실시간으로 조회하며, 어떤 문서에 적힌 내용도 신뢰하지 않습니다. 이후 .rankup/ 프로젝트 메모리 디렉토리를 구축하고, 이미 배포된 사이트의 트래픽, 색인(index), 성능, 수익 기준선을 한 번 보완하여 기술 점검 보고서를 작성한 후, 최종적으로 로드맵과 P0–P2 계획을 수립합니다. 그린필드 프로젝트는 스캐폴딩(scaffolding)이 통과된 즉시 원격 저장소에 배포하며, 원격 저장소는 기본적으로 비공개입니다. 이는 미배포 프로젝트의 레포지토리에 주제 선정 및 경쟁사 조사 내용이 포함되어 있어 공개할 경우 아이디어를 넘겨주는 것과 같기 때문입니다.
rankup review — 정기적인 검토에 사용합니다.
먼저 읽기 전용 점검 스크립트를 실행하여 다음과 같은 기계적 결론을 얻습니다: 어떤 파일이 누락되었는지, 어떤 기록이 만료되었는지, 스크립트의 검증 날짜가 지나지 않았는지, 경험 라이브러리에 중복 항목이 있는지 등을 확인합니다. 그리고 다른 곳에서는 거의 하지 않는 일을 수행합니다: 자신의 대화 기록을 분석하는 것입니다.
node scripts/sessions.mjs --project-root . --days 14 --new-only --dump
가장 가치 있는 경험은 종종 문서로 남지 않고 대화 속에 남아 있습니다. 이 스크립트는 Claude Code와 Codex의 세션을 사람이 말한 내용과 결론만 압축하여, 바이트 오프셋으로 수위선을 기록합니다. 지난번에 어디까지 읽었는지 이번에는 거기서부터 이어 읽습니다. 여기서 네 가지 종류의 내용을 찾아야 합니다: 사용자의 수정 사항, 검증된 결론, 겪었던 문제점 및 근본 원인, 그리고 이미 폐기된 이전 기록에 대한 사실입니다.
즉시 사용 가능한 키워드 및 데이터 분석 능력
哥飞 공식 Skill 패키지 — 공식 API 페이지에서 gefei, gefei-keywords, gefei-competitor, gefei-domain, gefei-page를 설치하고, seo-webcafe.md에 따라 진입점을 선택합니다. 공식 패키지는 도구 호출을 담당하며, Rankup은 증거 기준과 프로젝트 판단을 담당합니다. 레포지토리는 공식 Skill이나 CLI를 복사하지 않습니다.
scripts/webcafe-forum.mjs (및 webcafe-transport.mjs / webcafe-rsc.mjs) — 哥飞 커뮤니티 포럼 전체 데이터를 수집합니다.
get <임의 사이트 URL> 한 줄 명령어로 내용을 가져오며, 인식할 수 없는 URL은 일반 크롤링으로 대체됩니다. 혜자 질문 답변(모금형 공모 목록 및 제출 이유 포함), 경험 91개 / 게시물 722개 / 튜토리얼 40개 카테고리, 사이트 내 검색, 그리고 '哥飞의 친구들' 14개 위챗 그룹 아카이브 검색을 커버합니다.
— 이 아카이브는 사이트 내 AI 어시스턴트의 지식 기반이며, 직접 검색하면 원문 그대로 가져오므로 어떤 AI 할당량도 소모하지 않습니다.
인터페이스 맵과 주의사항은 references/webcafe-forum.md에 있습니다.
이 사이트는 익명으로 401 에러가 발생하지 않습니다: 동일한 엔드포인트라도 익명으로 접근하면 여전히 200과 전체 항목을 반환하며, 본문만 빈 문자열로 바꾸고 투표 수를 0으로 만듭니다.
따라서 '데이터를 가져왔는지'는 상태 코드를 볼 것이 아니라 본문의 공백 여부를 봐야 합니다. 스크립트는 access 필드로 구분합니다.
'로그인 안 함 / 문제 풀이 기간 봉쇄 / 비용 지불 필요로 잠금 해제 / 전체 확보' 네 가지 경우이며, 절대 자동으로 잠금 해제를 하지 않습니다 (그것은 돈을 들여야 합니다).
scripts/gt.py — Google Trends입니다. 관심도 비교, 지역 분포, 관련 급상승 키워드, 일일 실시간 검색어 네 가지 하위 명령어가 있으며, 기본 브라우저 라우팅(구동 시 Chrome 로그인 필수)을 사용하고 --via pytrends는 scripts/archive/gt-v1/로 변경되었습니다. 관련 references/trends.md에는 세 가지 워크플로우가 있습니다: 소수 언어 시장 탐색, 모호한 방향성을 실제 구축 가능한 키워드로 수렴시키기, 신흥 트렌드 포착입니다.
scripts/demand/ 전체 세트(24개 스크립트, 3.0 버전에서 추가된 suggest.mjs 삼 엔진 드롭다운 연상 포함) — 수요 발굴 데이터 수집을 담당하며, references/demand-sources.md의 소스 자료와 연결되어 스크립트 라우팅 테이블을 구성합니다. 또한 스크립트가 없는 10여 개의 수동 소스 (별점 낮은 리뷰 마이닝, 사용자 원문 발언, CT 서브도메인 모니터링 등)가 있으며, 상세 내역은 references/capability-map.md를 참고하십시오.
사용자가 "키워드 몇 개 찾아줘", "수요를 발굴해줘", "최근에 뭘 할 수 있어?"라고 물을 때의 진입점입니다. 라우팅 테이블은 사이트 유형별이 아닌, "현재 어떤 종류의 신호가 부족한지"에 따라 구성됩니다: 돈을 받은 사람 / 트래픽 구매에 비용을 지출하는 사람 / 실행했지만 제대로 하지 못한 사람 / 이 일에 외주비를 지불하는 사람 / 새롭게 등장하는 제품 / 지속적으로 새로운 단어가 쏟아지는 플랫폼 / 사용자의 원문 발언 / 경쟁사가 어디에 베팅하고 있는지. 후보를 확보한 후에는 모두 동일한 검증 경로(도메인 프로필 → KD → SERP 화면 → 트래픽 패널 → 트렌드)를 거칩니다.
출처는 커뮤니티의 보상 게시물에 언급된 전체 사이트(23개)이며, 각 데이터 수집 경로는 문서대로 복사한 것이 아니라 2026-08-23에 개별적으로 실제 요청을 보내 검증되었습니다. 따라서 라우팅 테이블에는 "전체 테스트 과정을 절약해 주는" 실측 결론들이 함께 기록되어 있습니다. 예를 들어, 특정 게임 플랫폼의 공식 앱 목록 인터페이스가 이미 폐쇄되었거나, 특정 댓글 플랫폼의 .json 엔드포인트가 현재 일괄적으로 403 에러를 반환하는 경우, 또는 특정 AI 네비게이션 사이트가 환경 수준에서 접근 불가능한 경우(실제 브라우저로도 복구 불가), 혹은 특정 "수익 순위"가 사실 수익 데이터를 제공하지 않는 경우 등입니다. "얻을 수 없음" 역시 결론이며, 필드를 꾸며내지 않습니다.
이 스크립트 세트를 관통하는 경계선은 따로 기록할 가치가 있습니다: "실제 브라우저가 필수인 경우"와 "로그인 상태가 필수인 경우"는 별개의 문제입니다. 대부분의 사이트는 단순히 봇 방지 질문을 우회하기만 하면 되므로 계정이 필요하지 않습니다. 실제로 로그인 상태가 필요한 경우는 극히 드뭅니다. 이 둘을 혼동하면 불필요한 인증 정보(credentials)를 많이 준비하게 되거나, 반대로 — 로그인 상태가 아닌 환경으로 로그인해야 하는 패널을 조회하여 겉보기에는 정상적이지만 내용이 다른 결과를 얻게 됩니다.
scripts/indexnow-submit.mjs + scripts/webmaster-sitemap.mjs — 검색 플랫폼 연동 전체 섹션이며, references/search-platforms.md와 함께 사용됩니다.
새 사이트가 매번 똑같이 해야 하는 일들: IndexNow 키 배포, 전체 데이터 한 번 전송(전체량), Bing과 GSC에서 소유권 검증, 양쪽에 sitemap 제출, 이후 버전 발행 시 증분 전송. 순서표에서는 IndexNow를 웹마스터 도구보다 앞에 배치해야 합니다. 이는 계정이 전혀 필요 없고 키 파일 하나가 모든 인증 정보이기 때문에, 뒤에 배치하는 것은 마치 계정 문제가 해결되기를 기다리는 며칠을 허비하는 것과 같습니다.
따로 언급할 만한 세 가지 사항:
-
전송 스크립트는 제출 전에 키 파일 유효성 검사를 먼저 수행해야 합니다. 키가 접근 불가능할 경우 전체 전송이 폐기되지만, 인터페이스는 여전히 200을 반환합니다. 이 단계가 없으면 "전송 성공"이라는 문구가 키 배포가 안 되었거나, 오타가 있거나, 정적 리소스에 의해 가로채졌을 때 글자 그대로 출력됩니다.
-
URL 목록은 온라인 sitemap에서 가져와야 하며, 스크립트 내부에 배열로 유지해서는 안 됩니다. 하드코딩된 배열은 실제 발행되는 페이지와 반드시 어긋나게 되며, 그 오차 방향은 항상 "새 페이지가 전송되지 않음"입니다.
-
두 가지는 사용자가 직접 클릭해야 하는 과정입니다: 웹마스터 도구의 "DNS 서비스 제공업체 계정 접근 권한 부여"와 Bing의 "GSC에서 가져오기". 후자는 몇 분을 절약해 주지만, 그 대가로 Bing은 사용자 Google 계정에 대한 장기 OAuth를 얻게 되며
-
experiences/demand-discovery.md — 초기 조사: '누가 이미 돈을 벌고 있는지'를 역추적하는 6가지 채널(결제 게이트웨이 추천 트래픽의 유료 페이지 도달 비율, 롱테일 결제 게이트웨이, 광고 집행 데이터, 앱 스토어 유료 순위 및 부정적 리뷰 분석, 타오바오 씨엔유 판매량, 대기업 회원 기능표 등), 전적으로 자동화 가능한 필터링 파이프라인(순위 목록 → 트래픽 패널 → 임계값 설정 → 브랜드 키워드 제외, 실측 결과 약 300개 제품 중 1개를 선별), 수요 가치를 판단할 수 있는 5가지 인지적 기준.
-
experiences/zero-to-one.md — 0에서 1로 나아가는 기획 및 반복(Iteration) 규율: 먼저 '1'을 명확히 정의하고, 세 단계의 순서, 허영 지표(Vanity Metrics) vs 검증 신호(Validation Signal) (일정 인원 + 할인 없음 + 수동 설명 없음 + 자연스러운 결제 후 환불 없음, 네 가지가 동시에 충족되어야 함), 깔때기 병목 구간의 삼분법, 다듬기 > 재구성, 수작업으로 먼저 작동시킨 후 자동화하기, 충돌 해결이 포함된 출시 실행 체크리스트 한 장.
-
experiences/conversion.md — 전환 및 행동 데이터: 페이지를 수정하기 전에 상위 트래픽 의도를 먼저 확인하고, 가입 후에 사용하게 만들기(Sign up after use), CTA는 동작 대신 결과를 작성하기, 방문자당 수익 = 결제율 × 객단가, 가격 책정 페이지 기법을 수용 가능성 기준으로 세 단계로 분류(명확히 수용하지 않는 다크 패턴 포함), 저빈도 필수 제품에 '처음부터 유료 결제를 띄우는 것'의 비공통적 성격과 그 경계.
-
experiences/webcafe-experiences.md — 고펑(哥飞) 경험 글에서 가져온 15가지 실행 가능한 판단 기준들로, 에이전트가 직접 판단할 수 있는 형태로 번역됨:
-
오래된 웹사이트는 살리지 말고 도메인을 바꿔서 새로 시작하라.
-
동일한 템플릿을 브랜드 키워드와 함께 N개의 사이트에 사용하는 것은 자신을 N번 반복하는 것과 같다.
-
다국어는 원클릭 번역하지 말고, 각 언어별로 단어를 다시 찾아라.
-
웹사이트가 완성되지 않았다면 정식 도메인을 사용해 출시하지 마라.
-
구글이 도메인 대신 브랜드 이름을 표시하도록 하려면 6군데에 함께 작성하라.
-
KGR은 intitle 태그와 따옴표를 사용하고, 반드시 직접 검증하라.
-
트래픽이 전적으로 브랜드 키워드에서 오고 기능 키워드가 부족하면 홈 페이지는 수정할 필요가 없다.
-
큰 키워드를 목표로 하지만 작은 키워드만 다루는 것이 키워드 선택을 잘못했다는 의미는 아니다.
-
'크롤링되었으나 색인에 포함되지 않음'은 콘텐츠 문제이며, 반복적으로 제출해도 소용없다.
-
페이지의 기본 체력(Basic foundation)은 목표가 아니라 하한선이다.
-
GSC 데이터는 16개월만 보관하고 순환 삭제하라.
-
도메인은 외부 링크가 남아있는 한 계속 갱신하라.
-
빙(Bing)이 구글보다 만들기 쉽다는 것은 착각이며, 그 원인은 온페이지(On-Page) 진입 장벽 때문이다.
-
GEO: 추천되는 진입점은 더 이상 구글에만 국한되지 않는다.
-
도구 선택 시 가격 현실성을 포함하라.
프로젝트 메모: .rankup/ 은 로그가 아니라 위키이다
모든 웹사이트는 자체 저장소 안에 .rankup/ 폴더를 보관한다. 핵심 원칙은 단 하나이며, 나머지 규칙들은 이 원칙의 구체적인 적용 사례들이다: .rankup/ 안에서 journal/을 제외한 모든 것은 시간 순서대로 추가되는 기록(Log)이 아니라 지속적으로 수정되는 위키(Wiki)다.
- 로그는 '어느 날 무슨 일이 일어났는지'에 답한다 — 증설만 하고 변경하지 않으며, 영구 보존되며, 시간 순서로 읽는다.
.rankup/ 전체에서 이 유형은 journal/ 뿐이다.
- 위키는 '현재 무엇이 진실이며, 왜 그런지'에 답한다 — 제자리에서 수정하며, 주제별로 읽는다. 어떤 결론이 뒤집혔다면, 그것이 처음 등장했던 위치를 수정해야 하며, 나중에 반박하는 문장을 덧붙여서는 안 된다.
이 원칙을 지켜야 하는 구체적인 실패 시나리오가 있다: 독자가 어떤 확신에 찬 옛 결론을 보고 그대로 행동했는데, 사실 그 결론은 이미 뒤집힌 경우 — 독자는 이를 감지할 방법이 전혀 없다. 실제로 발생했던 예시: 특정 프로젝트 기록에서 '이 세 페이지 모두 색인에 포함됨'이라고 했는데, 며칠 후 이 중 두 개가 색인에서 사라졌음에도 불구하고 노트는 여전히 현재 시제에 머물러 있어, 이후 작업 지침을 그 이미 성립되지 않은 문장을 바탕으로 판단하게 만드는 경우. 비밀 키 파일은 이름, 용도, 환경 및 Secret 시스템 위치만 기록하며, 실제 값은 절대 Git에 넣지 않는다.
소유권(Ownership)은 세 계층으로 나뉘며, 서로 혼동되어서는 안 된다:
- Skill 레벨은 사이트를 분리한 후에도 여전히 유효한 일반적인 방법론만을 담는다.
scripts/validate-rankup.mjs는 기계적 단언(mechanical assertion)을 수행하며, 사이트 이름, 절대 경로, 로컬 프록시 또는 자격 증명 위치가 감지되면 실패로 간주한다.
- 프로젝트 레벨의 사실, 숫자, 판단 및 재사용 가능한 스크립트는 각자의
<project>/.rankup/에 보관된다.
- 로컬(Local) 레벨의
registry.md는 프로젝트 간 자산 인덱스이며, scripts/registry.mjs scan을 통해 생성된다. 이 파일은 프로젝트 경로를 포함하므로 gitignore 처리되며, 또한 git add -f 명령어로 접근하는 것을 단언적으로 막는다.
작업을 시작하기 전에 이 표를 먼저 확인하라: 다른 프로젝트에서 이미 작성된 스크립트는 해당 경로로 직접 가져가서 재작성하지 마라.
기본 웹사이트 구축 스택 (Default Build Stack)
pnpm dlx shadcn@latest init \
--preset b1D0eCA4 \
--template start \
...
Cloudflare 우선(Cloudflare-first): SSR 및 API는 Workers를 사용하고, 트랜잭션 데이터는 D1을 사용하며, 파일 및 내보내기 결과물은 R2를 사용한다. 읽기가 많고 쓰기가 적은 설정은 KV를 사용하고, 비동기 다단계 작업은 Queues/Workflows를 사용하며, 강한 일관성 조정(Strong consistency coordination)은 Durable Objects를 사용한다. 실제 키는 Worker Secrets 또는 CI Secrets에 보관한다. 자원은 실제로 필요한 만큼만 활성화하며, '나중에 필요할 수도 있다'는 이유로 미리 생성하지 않는다.
프레임워크의 네 가지 함정(four pitfalls)은 모두 실제로 겪어본 경험이며, references/lifecycle.md 섹션 3 · 3.1 '프레임워크의 네 가지 함정'에 작성되어 있습니다.
backlink — 백링크 및 로그인 상태 데이터
버전 3.3.1입니다.
SKILL.md는 XML 구조를 따르는 v3.0 버전입니다. 그 이유는 파일 시작 부분에 명시되어 있습니다: 이 Skill의 핵심은 규칙(rule)과 경로(route)이며, 쉽게 간과될 수 있는 하나의 규칙이 곧 위반되기 쉬운 규칙이기 때문입니다. 태그가 지정된 블록을 통해 '내가 방금 어떤 규칙을 위반했는지'라는 질문에 답할 이름표를 붙였습니다.
스크립트 34개 + 방법론 19가지 + 기계 판독 가능 데이터 파일 4개.
데이터 자산: 이 Skill에서 가장 가치 있는 부분
데이터 파일은 자산이며, 참고 문서는 '어떻게 사용하고, 어떻게 스스로를 속이지 않을지'에 대한 지침서입니다. 모든 것이 기계 판독 가능하며, PR 제출이 가능하고, JSON Schema와 로컬 검증 스크립트가 갖춰져 있습니다.
data/submission-targets.json — 492개의 제출 가능한 진입점(entry point)으로, 게이트별로 분류되어 있습니다:
| 게이트 | 수량 | 의미 |
|---|
account | 162 | 계정 등록 필요 |
| ... | | |
| 이 라이브러리의 출처 중 일부는 커뮤니티에서 전해지는 서드파티 목록이지만, 모든 항목은 실제 테스트를 거쳐 검증되었습니다. 예시로: 서드파티 목록을 중복 제거한 235개 디렉터리 중에서 세 번에 걸쳐 병렬 검증한 결과, '무료 + 회원가입 불필요 + 인증 코드 불필요' 조건으로 직접 제출 가능한 것은 단 13개였으며, 개방률은 5.5%였습니다. 또한 이미 사장된(dead) 항목이 48개 있었습니다 (20% 차지). 이 중 일부는 여전히 200을 반환하지만, 내용은 암호화폐 홍보 페이지로 변경되어 있습니다. 이러한 비율 자체가 가장 가치 있는 정보입니다. 이는 '무료 백링크 목록 743개'라는 자료 하나 때문에 오후 내내 시간을 낭비할 필요가 없게 만듭니다. | | |
data/free-channels.json — 링크를 직접 발행할 수 있는 채널 27개 중, 25개가 회원가입이 불필요합니다.
data/paid-platforms.json — 유료 광고 게재가 확인된 플랫폼 141개로, 독립적인 사이트가 몇 개를 사용하여 순위를 매기는지 기준으로 분류되어 있습니다. 경쟁사가 어떤 링크를 구매했는지에 대한 답을 이 표에서 얻을 수 있습니다.
data/index-submission.json — URL만 받고 실제 링크는 제공하지 않는 색인 제출 채널입니다. 이는 외링크 장부(backlink ledger)에 절대 포함되어서는 안 되기 때문에 별도의 테이블로 존재합니다. 또한 indexed가 반드시 검색 엔진을 지칭해야 한다는 규칙이 명시되어 있습니다. 즉, indexed@google 또는 indexed@brave와 같이 구체적으로 작성해야 하며, 단순히 '색인됨'이라는 빈 내용으로 작성할 수 없습니다.
브라우저 규칙 5가지
모든 브라우저 동작을 수행하기 전에 references/browser-runtime.md를 먼저 읽어야 합니다. 핵심적인 몇 가지 규칙은 다음과 같습니다: