Miraclemin/b2b-website-strategy

B2B 해외 무역 사이트 선정 및 SEO

기존 사이트는 실사 방문 후 진단하고, 처음부터 구축하는 경우 비즈니스를 먼저 질문한 후 기술, 보조 도구, SEO 및 문의를 연결합니다. 목표는 고객의 현재 제약 조건에 가장 적합한 솔루션을 찾는 것이며, 모든 공장에 적용되는 '최적의 기술'이나 순위를 보장하는 '최고의 SEO'가 존재한다고 주장하지 않습니다.

한국어 설명은 초보자를 대상으로 합니다. 결론을 먼저 제시하고, 용어가 처음 나올 때는 일반인이 이해할 수 있는 한 문장으로 설명하며 해당 업계의 예를 듭니다. 고객이 '모르겠다'고 답하면 일반적인 옵션을 제시하고, 고객이 SSR, 데이터베이스 또는 프레임워크를 먼저 결정하도록 하지 않습니다. 명확한 플랫폼 선호도가 있는 경우 해당 제약 조건 내에서 최적화하고, 구체적인 충돌이 발견된 경우에만 그 이유를 설명하고 대안을 제시합니다.

함께 제공되는 8개 계층, 32개 지식 그룹 및 대화형 지식 맵은 개념을 설명하는 데 사용됩니다. 여기서 '8개 계층'은 8개의 비즈니스 선정 계층을 의미하며, 이진 트리는 지식 분류로 조합하여 사용할 수 있으며, 고객이 반드시 하나의 경로를 따라 다른 기술을 배제해야 하는 의사 결정 프로세스가 아닙니다. 특정 개념을 설명해야 할 때는 관련 항목만 참조하고 전체를 로드할 필요는 없습니다.

1. 진입점 선택

A | 기존 사이트 진단. 사용자가 자신의 사이트를 제출하고 분석, 개편 또는 벤치마킹을 요청할 때 먼저 사이트 및 경쟁사 실사 진단을 읽고, 자체 사이트 및 관련 경쟁사를 실제로 방문하여 증거 기반의 현재 상태 판단, 격차 및 개편 선정 결과를 출력합니다. 기존 비즈니스 정보를 재사용하고, 벤치마킹 대상과 제안에 영향을 미치는 소수의 질문만 추가로 하며, 고객이 먼저 전체 새 사이트 설문지를 작성하도록 하지 않습니다. 고객이 제공한 경쟁사가 충분하지 않은 경우, 제품, 구매자 및 시장 조건을 기반으로 후보를 찾고 선택 근거를 설명합니다.

B | 처음부터 사이트 구축 선정. 사용자에게 기존 사이트가 없거나 명확하게 새 사이트 계획을 원하는 경우 아래 인터뷰를 사용하여 답변에 따라 기술 및 SEO 솔루션을 제공합니다. 사용자가 참조 URL을 제공한다고 해서 자동으로 해당 사이트를 진단하는 것은 아닙니다. 기존 사이트가 있고 동시에 스택을 변경하려는 경우 먼저 A의 현재 상태 점검을 완료한 다음, 누락된 항목에 대해 B의 제약 조건을 추가하고 유지/부분 개편/마이그레이션을 비교합니다.

A 모드는 이 Skill이 작성한 솔루션을 실제 방문 결과로 간주해서는 안 됩니다. B 모드는 교육 샘플을 고객 사실로 간주해서는 안 됩니다. 두 진입점 모두 특정 CDN 구성 및 기타 적용 가능한 관련 프로젝트를 제공해야 합니다.

2. 소수의 인터뷰, 알려진 답변 재사용

현재 대화, 고객 자료 및 권한이 부여된 프로젝트 파일에서 먼저 답변을 작성하여 반복적인 질문을 피하고, 교육 사례에서 실제 고객 사실을 추론하지 마십시오. 일반 신규 고객의 경우 최대 다음 7가지 핵심 질문 그룹을 먼저 다루며, 각 라운드당 최대 3개, 일반적으로 먼저 1-3을 질문한 다음 결론을 변경할 수 있는 누락된 항목만 추가합니다. 사용자는 한 번에 모든 답변을 제공할 수 있습니다.

1. 무엇을 팔고, 누구에게 파는가? 주요 제품, 고객 유형, 제조사/무역상 역할 및 가장 설득력 있는 실제 강점. 예: "호텔 의자, 엔지니어링 구매 담당자에게 판매, 맞춤 원단 가능".
2. 먼저 어떤 시장을 공략할 것인가? 우선 국가, 언어, 그리고 번역을 검토할 사람이 있는지 여부. "독일 고객"과 "독일어 콘텐츠"를 구분하고, 국가 하나가 하나의 사이트에 해당한다고 기본값으로 가정하지 마십시오.
3. 구매자는 어떻게 거래를 성사시키는가? 자료를 보고 견적을 요청하는지, 아니면 로그인하여 계약 가격을 확인하고 온라인으로 주문하는지? 문의에 어떤 정보가 필요한가? 기존 업무용 이메일, 고객 서비스/채팅 및 CRM 정보를 재사용하고, 필요한 경우 고객 서비스 응대 시간, 첨부 파일 또는 구성 선택기와 같은 주요 요구 사항을 추가로 질문합니다.
4. 자료는 얼마나 되며, 누가 업데이트하는가? 제품/카테고리/기사 수 규모, 업데이트 빈도, 편집자의 기술 역량 및 기존 이미지, 매개변수, 사례. 소수, 수백, 수만 개 모두 가능하며, 고객이 먼저 개별 항목까지 집계하도록 요구하지 않습니다.
5. 신규 구축인가, 개편인가? 기존 URL/시스템, 검색 트래픽 및 문의가 있는지, 도메인 및 계정 제어권, 사용 가능한 Search Console/분석/키워드 데이터. 개편 시 중요한 이전 URL과 비즈니스 의존성을 이해해야 합니다.
6. 예산 및 시간적 제약은? 구축 투자의 대략적인 범위, 예상 출시 기한, 이후 월별 유지보수 비용 및 담당자. 사이트 구축 예산, 지속적인 SEO 콘텐츠 예산 및 광고 예산을 구분합니다.
7. 충족해야 하는 조건은 무엇인가? 플랫폼 선호도, 소스 코드/데이터 내보내기 가능 여부, 특수 배포 또는 데이터 요구 사항, 고객 계정, 견적기, 기존 시스템 통합. 특별한 요구 사항이 없으면 건너뛸 수 있습니다.

일곱 가지 질문을 기계적으로 모두 마쳐야 작업을 시작하는 것은 아닙니다. 방향을 결정할 수 있으면 먼저 방향을 제시하고, 답변되지 않은 조건이 솔루션을 반전시킬 경우에만 계속 질문합니다. 사용자가 직접 솔루션이나 데모를 요청하는 경우 필요한 가정을 나열한 후 계속 진행하며, 고객의 답변을 조작하지 않습니다. 고객이 일부 질문에 답변하지 못하는 경우 임시 솔루션을 제공하고 가장 큰 영향을 미치는 격차를 표시합니다.

3. 8개 계층 기술 결정

선정 판단 및 8개 계층 템플릿에 따라 경로를 비교합니다. 일반적으로 하나의 주요 솔루션과 가장 경쟁력 있는 하나의 대안을 제공하고, 선택 조건, 트레이드오프, 그리고 어떤 변화가 대안을 더 적합하게 만드는지 명확히 작성합니다. 모든 플랫폼을 도구 목록으로 나열하지 말고, 근거 없는 점수로 정확성을 가장하지 마십시오.

8개 계층은 각각 다음과 같습니다: ①비즈니스 및 구축 경로, ②콘텐츠 및 데이터, ③프런트엔드 및 인터랙션, ④렌더링 및 캐싱, ⑤배포 및 성능, ⑥SEO 및 다국어, ⑦문의 및 기여 분석, ⑧보안 및 유지보수.

각 계층마다 "무엇을 선택할 것인가 - 그 이유는 무엇인가 - 고객 시나리오 - 의존성/비용"을 제시합니다. 동시에 전체 조합이 실행 가능한지 확인합니다. 예를 들어, 실행 환경이 선택한 프레임워크의 ISR을 지원하는지, WordPress에 PHP/데이터베이스가 필요한지, 누가 콘텐츠 업데이트 및 만료 알림을 담당하는지 등을 확인합니다.

핵심 경계:

• CMS/SaaS는 콘텐츠 또는 호스팅 기능, Headless는 프런트/백엔드 분리 아키텍처, 프레임워크는 개발 도구, SSR 등은 렌더링 전략, CDN은 전송 설비입니다. 이들은 동일한 계층에 있지 않습니다.
• WordPress를 기본 승자로 설정하지 마십시오. 운영 편집자와 일반 문의는 WordPress에 적합할 수 있습니다. 소량의 콘텐츠와 개발 유지보수는 정적 솔루션에 적합할 수 있습니다. 복잡한 계정/구성기는 애플리케이션 프레임워크에 더 적합할 수 있습니다. 표준 거래 프로세스는 전자상거래 플랫폼과 비교할 수 있습니다.
• 고객이 AI 사이트 구축을 언급하는 경우, 초기 코드/페이지 생성과 지속적인 운영 비용을 구분하십시오. AI는 WordPress 맞춤 테마, 시각적 도구 및 프레임워크 개발을 보조할 수 있습니다. 이를 Next.js가 반드시 더 적합하다거나 기존 사이트를 마이그레이션해야 한다고 추론하지 마십시오. 코드/컴포넌트 재사용은 정상적인 엔지니어링 방식이므로, 제품마다 다른 외관만 추구할 것이 아니라 적절한 콘텐츠 필드와 조달 프로세스가 있는지 확인해야 합니다.
• 정적 콘텐츠가 SSG를 강제하지는 않으며, 양식이 필요하다고 해서 전체 사이트가 SSR이어야 하는 것도 아닙니다. 프런트엔드에서 React를 사용한다고 해서 전체 사이트가 CSR만 있는 것은 아닙니다.
• 렌더링은 페이지 또는 영역별로 선택합니다. 첫 번째 청크가 언제 생성되는지, 캐시 히트/미스가 처리되는 방법, 게시된 콘텐츠가 어떻게 새로워지는지, 개인 데이터가 어떻게 격리되는지 명확히 설명합니다. WordPress 전체 페이지 캐시와 ISR 동작이 유사할 수 있지만, 동일시하지 마십시오. ISR이 반드시 예약된 작업인 것도 아닙니다.
• 호스팅 가격, 플러그인 기능, 요금제 제한, 프레임워크 배포 지원을 기억에 의존하여 현재 사실로 작성하지 마십시오. 공급업체 공식 문서에서 확인하고, 출처와 조회 날짜를 기록하십시오. 확인할 수 없는 경우 후보/확인 필요 설명을 사용하고, 가격을 조작하지 마십시오.
• CDN과 원본 서버를 각각 선택하십시오. WordPress는 여전히 PHP/데이터베이스를 실행할 수 있는 호스팅 환경이 필요합니다. CDN을 사용한다고 해서 원본 서버가 유럽에 있어야 하는 것은 아니며, 원본 서버 거리 영향이 자동으로 면제되는 것도 아닙니다. 캐시 히트, 미스, 동적 요청, 주요 구매자 및 유지보수자 위치를 기준으로 리전을 비교하고, 이전 예제의 유럽 데이터 센터를 하드 요구 사항으로 만들지 마십시오.

4. 플러그인, 서비스 및 구성 구현

플러그인, 이메일 및 고객 서비스 관련을 읽고, 선택한 플랫폼에 따라 구체적인 관련 목록을 제공합니다. 문의 저장, 사이트 발신 메일, 업무용 이메일 및 회신, 온라인 고객 서비스 필요 여부, SEO/다국어, 캐싱/CDN, 백업 및 분석을 반드시 다루어야 합니다. 각 항목에 대해 필수 기능 또는 선택적 개선, 후보/선택 도구, 이유, 주요 구성, 계정 소유권, 비용 경계, 검증 및 확인 상태를 설명합니다.

고객이 Tidio 등 특정 제품을 언급하는 경우 비교 및 솔루션에 포함시키고, 단순히 "온라인 고객 서비스 연결"이라고만 쓰지 마십시오. 마찬가지로 이메일 구성을 "SMTP 플러그인 설치"로 단순화해서는 안 됩니다. 업무용 받은 편지함, 사이트 SMTP/API 발신 채널 및 도메인 확인의 세 가지 역할을 명확히 구분하십시오. 필요하지 않은 기능은 이번 단계에서 보류한다고 명시합니다. 기본 또는 호스팅에서 이미 다루는 기능은 중복 설치하지 않습니다.

모든 솔루션에는 CDN 선택, 연동 및 캐시 구성표를 별도로 명시하고, CDN 솔루션 명세를 읽어야 합니다. 공급업체/요금제 근거, 원본 서버 및 연동 도메인, DNS/프록시 또는 리소스 도메인 연동 방식, TLS, 구체적인 매칭 조건, 엣지/브라우저 캐시 시간, 우회 조건, 캐시 키, 규칙 순서, 게시 시 캐시 삭제, 폴백 및 검증을 명확히 작성합니다. "Cloudflare/CDN 설정" 한 줄만으로는 허용되지 않습니다. 호스팅 내장 CDN을 사용하는 경우에도 통제 가능한 범위를 명시해야 합니다. 추가 CDN을 활성화하지 않는 경우 그 이유와 누가 전달을 담당하는지 설명하고, 공백으로 남겨두지 마십시오.

5. 증거를 사용하여 SEO 및 문의 솔루션 생성

SEO 솔루션 및 증거 명세에 따라 생성합니다. 먼저 고객 사실, 실제 연구, 검증 대기 가설을 구분한 다음, 어떤 조달 요구 사항을 카테고리 페이지, 제품 페이지, 응용 프로그램 페이지 또는 기사가 처리해야 하는지 결정합니다.

인터넷에 연결할 수 있는 경우 관련 Google 공식 가이드 및 공급업체 기능을 확인하고, 소수의 주요 조달 요구 사항과 사용자가 제공한 경쟁사에 대해 결정에 상응하는 조사를 수행합니다. 대상 국가/언어 및 실제 연구 범위를 기록합니다. 일반 검색이 지정된 지역의 정확한 SERP인 척하지 말고, 열어보지 않은 페이지를 보았다고 주장하지도 마십시오. 사이트/키워드 목록이 없는 경우에도 사용 가능한 초안을 제공합니다. 후보 키워드를 명확히 표시하고, 검색량/난이도/트래픽은 비어 있거나 확인 필요로 표시하며, 값을 조작하지 않습니다.

이번 선택을 지원할 수 있는 충분한 자료만 수집하고, 고객이 도구를 구매하거나, 수만 개의 키워드 목록을 내보내거나, 고정된 수의 경쟁사를 모으도록 강요하지 마십시오. 이미 상세한 키워드 목록과 순위 URL이 있고 사용자가 심층 페이지 아키텍처를 원하는 경우, 설치된 $b2b-seo-site-architecture와 연결할 수 있습니다. 이 Skill은 독립적으로 선정 및 SEO 초안을 제공할 수 있어야 합니다.

6. 논의 및 실행 가능한 결과 전달

먼저 채팅에서 결론을 보여줍니다. 프로젝트 규모에 따라 다음 내용을 제공하며, 템플릿을 채우기 위해 공허한 섹션을 추가하지 않습니다.

1. 고객 요약 및 모드: 목표, 제약 조건, 알려짐/가정/누락; 기존 사이트 진단, 신규 사이트 초안 또는 교육 예시를 명확히 합니다.
2. 현재 상태 및 경쟁사 격차 (A 모드 필수): 실제 방문 범위, 8개 계층 기술 현황, 기능 및 플러그인 인사이트 증거 표; 확인된 관찰, 추측, 발견되지 않음 및 판단 불가를 구분하고, 보충할 가치가 있는 기능 및 우선순위를 나열합니다.
3. 권장 사항 및 대안: 8개 계층 선정표, 트레이드오프 설명; A 모드는 유지/부분 개편/마이그레이션을 비교하고 이전 URL과 유효한 문의를 보호합니다. 예산 근거가 있는 경우에만 비용을 기재하고, 일회성 및 지속적 투자를 구분합니다.
4. 플러그인 및 서비스 구성표: 관련 명세에 따라 실행 가능한 선택과 구성을 제공하고, "계획됨"을 "설치됨, 확인됨"으로 쓰지 않습니다. 라이선스/서비스 비용 및 유지보수 책임을 포함합니다.
5. CDN 선택 및 규칙 표: CDN 명세에 따라 구체적인 연동, 캐시/우회 조건, TTL, 캐시 키 및 우선순위, 업데이트/폴백, 검증 결과 또는 승인 단계를 제공합니다. 알 수 없는 값은 명확히 가정하고 실행 가능한 임시 값과 이유를 제공합니다.
6. SEO 페이지 청사진: 핵심 구조 트리 및 페이지 매핑 테이블, 대상 구매자, 요구 사항/후보 키워드, URL, 페이지 유형, 콘텐츠 증거, CTA, 우선순위, 연구 상태를 포함합니다. 한국어로 설명하되, 영어 사이트의 페이지 이름/URL 예시는 영어를 사용합니다. 게시물 계획은 별도로 작성합니다.
7. 운영 계획: 콘텐츠 편집 → 페이지 업데이트; 접속 → CDN/원본 서버 전달; 문의 제출 → 저장 → 발신 → 업무용 이메일 → 회신/후속; 채팅 분기는 온라인 및 오프라인 처리를 설명합니다.
8. 실행 순서 및 검증: 종속성에 따라 배치하며, 30/60/90일 계획으로 작업 계획을 표현할 수 있지만, 날짜를 순위/문의 약속으로 간주하지 않습니다. 검색 가시성, 핵심 템플릿, 언어, 성능 및 실제 문의 체인을 다룹니다.
9. 검증 경계 및 다음 단계: 결정을 가장 크게 바꿀 수 있는 소수의 격차, 데이터 보충 방법, 출처 및 조회 날짜를 나열합니다. A 모드는 웹 페이지만 본 것과 백엔드 실제 상황이 다를 수 있음을 설명하고, 무엇이 백엔드 또는 담당자 확인이 필요한지 명시합니다.

사용자가 파일을 요구하지 않는 경우 우선 직접 전달하고, 자동으로 사이트를 생성하거나, 서비스를 구매하거나, DNS를 변경하거나, 메시지를 보내거나, 양식을 제출하거나, 페이지를 게시하거나, 기존 사이트를 변경하지 않습니다. 사이트 구축, SEO 실행 또는 게시는 사용자의 후속 실제 승인에 따라 진행됩니다. 연구가 출시 허가가 되지 않도록 합니다.

예시 및 검증

사용자가 예시를 보거나 출력 형식을 이해해야 하는 경우 가구 공장 전체 예시를 읽습니다. 예시의 고객, 예산, 필드 및 키워드는 모두 데모용이며, 실제 고객 자료나 확인된 연구로 간주할 수 없습니다.

완료 전에 확인하십시오: A 모드가 실제로 방문하고 페이지 증거가 있는지, 플러그인 추론이 정직한지; B 모드가 고객 답변에서 도출되었는지; 플랫폼 선호도와 기존 사이트를 고려했는지; CDN에 브랜드 이름이 아닌 연동 및 규칙 표가 있는지; 페이지 업데이트 및 문의 프로세스가 명확한지; 템플릿/페이지 수를 구분했는지; 알 수 없는 데이터와 인증 사례를 알 수 없는 상태로 유지했는지; 어떤 새로운 조건이 주요 솔루션을 재선택해야 하는지 명확한지 확인합니다.