정보
도메인 전략 스킬은 개발자가 도메인 포트폴리오, DNS 설정, 리디렉션 전략을 설계하고 관리하는 데 도움을 줍니다. www 대신 애펙스 도메인 사용 여부, 등록기관 선택, 서브도메인 구조, 다중 사이트 통합 또는 분리와 같은 의사결정에 대한 지침을 제공합니다. 새로운 사이트를 계획하거나 기존 도메인 인프라를 최적화할 때 활용하세요.
빠른 설치
Claude Code
추천npx skills add rampstackco/claude-skills -a claude-code/plugin add https://github.com/rampstackco/claude-skillsgit clone https://github.com/rampstackco/claude-skills.git ~/.claude/skills/domain-strategyClaude Code에서 이 명령을 복사하여 붙여넣어 스킬을 설치하세요
문서
Domain Strategy
Decide how domains, subdomains, and DNS work across a portfolio. Stack-agnostic. Works for one site or one hundred.
When to use
- Setting up DNS for a new site (apex vs www, primary vs aliases)
- Choosing or switching registrars
- Planning redirects across multiple domains (parked, retired, consolidated)
- Deciding subdomain vs subfolder vs separate domain for a new product line
- Consolidating multiple sites into one
- Splitting one site into multiple
- Setting up DNS for email, security records, third-party services
When NOT to use
- Migrating content between platforms with URL changes (use
content-migration) - Email authentication setup specifically (use
email-deliverability) - Security headers or HTTPS config (use
security-baseline) - Internationalization domain choices (use
internationalization)
Required inputs
- Current domain inventory (every domain you own or operate)
- Status of each (live, parked, redirected, retired)
- Strategic role of each (primary brand, sub-brand, defensive registration, campaign)
- Current DNS provider and registrar for each
- Email and third-party service dependencies
The framework: 5 decisions
Every domain decision falls into one of these buckets. Address them in order.
Decision 1: Apex vs www as canonical
Pick one. Redirect the other to it. Pick before launch. Changing later is painful.
- Apex (example.com): cleaner, more memorable, the modern default.
- www (www.example.com): historically standard, easier to add CDN-level CNAME records (apex CNAME is technically forbidden but most providers offer ALIAS or ANAME).
Whichever you pick, the other must 301 to it. Both serving content is duplicate content and a soft signal of poor setup.
Decision 2: Subdomain vs subfolder vs separate domain
For a new product, blog, or content section:
| Pattern | Use when |
|---|---|
Subfolder (example.com/blog) | Same brand, want SEO equity to flow, default choice |
Subdomain (blog.example.com) | Different stack or platform, organizationally separate but related |
Separate domain (exampleblog.com) | Different brand, different audience, intentional separation |
Default to subfolder. The case for subdomain or separate domain has to be made.
Decision 3: Registrar strategy
The registrar is where the domain is registered. The DNS provider is where DNS records live. They can be the same or different.
Decisions:
- Single registrar vs multiple: single is simpler. Multiple makes sense for redundancy at scale.
- Lock and 2FA: non-negotiable. Domain hijacking is real and costly.
- Auto-renew: on for everything you care about. Off only for intentional drops.
- WHOIS privacy: on by default. Free at most modern registrars.
- Transfer lock: on except during planned transfers.
Decision 4: DNS provider
The DNS provider controls how domains resolve. Critical for performance, reliability, and security.
Pick a provider that gives you:
- Fast global resolution (anycast network)
- DNSSEC support
- API access for automation
- Reasonable record limits
- Good audit logs
Default DNS records every domain needs:
- A or AAAA records (or CNAME) for the apex and www
- MX records (even just nullified if no email)
- TXT for domain verification, SPF
- CAA records (locks down which certificate authorities can issue certs for the domain)
Decision 5: Parked domain strategy
Domains you own but aren't actively using. Three valid strategies:
- Redirect to a primary site. Best for defensively registered domains close to your main brand. 301 every path to the primary's homepage or matching path.
- Hold blank. A simple page or DNS NXDOMAIN. Acceptable for domains you may use later.
- Park with a landing page. Generic "coming soon" page. Lowest value. Avoid registrar default parking pages (often serve ads against your brand).
Anti-pattern: letting parked domains serve duplicate or near-duplicate content from your main site. This is an SEO liability.
Workflow
Step 1: Inventory
Pull every domain you own from every registrar. Build a single sheet:
| Domain | Registrar | DNS provider | Status | Role | Renewal date | Notes |
|---|
If you can't account for every domain, the strategy can't be accurate.
Step 2: Classify by role
Each domain gets one role:
- Primary (the main site for a brand)
- Alias (redirects to a primary)
- Defensive (registered to prevent others from getting it; usually parked)
- Campaign (short-term, specific use)
- Retired (no longer active; either drop at expiry or redirect permanently)
The classification drives the configuration.
Step 3: Audit current configuration
For each domain check:
- Is the canonical (apex vs www) consistent with the strategy?
- Are redirects 301 (permanent) where intended?
- Is HTTPS enforced on every variant?
- Are DNS records minimal and intentional?
- Is the registrar locked?
- Is auto-renew on?
- Is 2FA on the registrar account?
Document gaps. Each gap is a ticket.
Step 4: Set the canonical pattern
For new domains and any that need fixing:
- Pick apex or www as canonical
- Configure 301 redirect for the non-canonical
- Force HTTPS for both
- Verify with curl:
curl -I http://example.com,curl -I http://www.example.com,curl -I https://www.example.com. All should chain to a single 200 on the canonical.
Step 5: Document the redirect map
Across the portfolio, document every redirect:
| Source | Destination | Type | Reason | Date set |
|---|
This is invaluable when something breaks or when planning consolidations.
Step 6: Set up monitoring
Monitor:
- DNS resolution (alert on NXDOMAIN or wrong IP)
- HTTPS certificate expiration (alert at 30, 14, 7 days out)
- Redirect chains (alert if a 301 starts returning 200 or 404)
- Renewal dates (alert at 90, 30, 7 days out)
This is the bridge between domain strategy and monitoring-and-alerting.
Step 7: Document and revisit
Domain strategy is a quarterly review topic. Renewals, consolidations, and new launches change the picture. Without scheduled review, the portfolio drifts.
Failure patterns
Both apex and www serve content. Duplicate content. Pick one, redirect the other.
302 redirects where 301 was intended. 302 is temporary. 301 is permanent. SEO equity passes through 301, not (reliably) through 302.
HTTPS not enforced. HTTP variant serving content alongside HTTPS. Force HTTPS at the edge or the load balancer.
Registrar default parking pages. Parked domains serving registrar ads. Free for the registrar, bad for you. Replace with a redirect or your own page.
Domains in multiple registrars by accident. Migrations that didn't fully complete. Consolidate.
No CAA records. Anyone with a misconfigured ACME client can issue a cert for your domain. CAA limits which CAs can issue. Add it.
Auto-renew off "to save money." Domain accidentally drops, gets snapped up, costs ten times more (or is unrecoverable). Auto-renew is cheap insurance.
Subdomains used where subfolders would have been better. SEO equity gets fragmented across hostnames. The case for a subdomain has to be made; the default is subfolder.
Parked domains with thin content "for SEO." Search engines don't reward this. They penalize doorway pages. Either redirect or leave blank.
Output format
A domain strategy document includes:
- Inventory: the spreadsheet of every domain
- Classification: the role of each
- Canonical decisions: apex vs www, locked
- Redirect map: every redirect in the portfolio
- DNS standards: the default record set
- Registrar standards: locked, 2FA, auto-renew
- Monitoring: what's watched, where alerts go
- Renewal calendar: the next 12 months
- Review cadence: when this gets revisited
Reference files
references/dns-record-reference.md: Common DNS records explained, with the syntax for the most useful ones (A, AAAA, CNAME, MX, TXT, CAA, SRV, etc.) and when each is needed.
GitHub 저장소
자주 묻는 질문
domain-strategy Skill이란 무엇인가요?
domain-strategy은(는) rampstackco이(가) 만든 Claude Skill입니다. Skill은 Claude가 필요할 때 불러오는 지침과 리소스를 묶어 추가 프롬프트 없이 domain-strategy 관련 작업을 수행할 수 있게 합니다.
domain-strategy은(는) 어떻게 설치하나요?
이 페이지의 설치 명령을 사용하세요. domain-strategy을(를) Claude Code 플러그인으로 추가하거나 저장소를 skills 디렉터리에 복제한 다음 Claude를 다시 시작해 Skill을 불러옵니다.
domain-strategy은(는) 어떤 카테고리에 속하나요?
domain-strategy은(는) 메타 카테고리에 속합니다.
domain-strategy은(는) 무료로 사용할 수 있나요?
네. domain-strategy은(는) AIMCP에 등록되어 있으며 무료로 설치할 수 있습니다.
연관 스킬
이 스킬은 콘텐츠 콜렉션(Content Collections)을 위한 프로덕션 검증된 설정을 제공합니다. 콘텐츠 콜렉션은 Markdown/MDX 파일을 Zod 검증이 포함된 타입 안전한 데이터 콜렉션으로 변환해주는 TypeScript 최우선 도구입니다. 블로그, 문서 사이트 또는 콘텐츠 중심의 Vite + React 애플리케이션을 구축할 때 타입 안전성과 자동 콘텐츠 검증을 보장하기 위해 사용하세요. Vite 플러그인 구성과 MDX 컴파일부터 배포 최적화 및 스키마 검증에 이르기까지 모든 것을 다룹니다.
이 스킬은 개발자들이 Polymarket 예측 시장 플랫폼을 활용한 애플리케이션을 구축할 수 있도록 지원하며, 거래 및 시장 데이터를 위한 API 통합 기능을 포함합니다. 또한 WebSocket을 통한 실시간 데이터 스트리밍을 제공하여 실시간 거래와 시장 활동을 모니터링할 수 있습니다. 이를 통해 거래 전략을 구현하거나 실시간 시장 업데이트를 처리하는 도구를 생성하는 데 활용할 수 있습니다.
이 스킬은 개발자들이 명령어, 파일, LSP 작업 등 25개 이상의 이벤트 유형에 연결되는 OpenCode 플러그인을 만들 수 있도록 돕습니다. JavaScript/TypeScript 모듈을 위한 플러그인 구조, 이벤트 API 명세, 구현 패턴을 제공합니다. OpenCode AI 어시스턴트의 라이프사이클을 사용자 정의 이벤트 기반 로직으로 가로채거나, 모니터링하거나, 확장해야 할 때 사용하세요.
SGLang은 RadixAttention 프리픽스 캐싱을 활용하여 JSON, 정규식, 에이전트 워크플로우를 위한 고속 구조화 생성에 특화된 고성능 LLM 서빙 프레임워크입니다. 특히 반복되는 프리픽스가 있는 작업에서 상당히 빠른 추론 속도를 제공하여 복잡한 구조화 출력 및 다중 턴 대화에 이상적입니다. 제약 디코딩이 필요하거나 광범위한 프리픽스 공유가 있는 애플리케이션을 구축할 때는 vLLM과 같은 대안보다 SGLang을 선택하십시오.
