미국 남동부의 중형 정형외과 진료소가 우리에게 찾아왔습니다. 의료 업계에서 흔히 볼 수 있는 문제를 안고 있었습니다. WordPress 사이트가 느렸고, 환자 접수 프로세스는 PDF 다운로드와 팩스 송수신의 악몽이었으며, HIPAA 노출 위험으로 인해 IT 규정 준수 담당자가 밤을 새고 있었습니다. 6개월 후, 그들은 Next.js 프론트엔드, Payload CMS 백엔드, HIPAA-안전 환자 접수 양식, 그리고 경쟁사의 사이트를 구식 다이얼업처럼 보이게 하는 Lighthouse 점수를 갖게 되었습니다. 정확히 어떻게 했는지 설명하겠습니다.

목차

Healthcare Practice: WordPress to Next.js + Payload CMS Migration

출발점: 우리가 작업한 것

그 진료소를 남동부 정형외과(NDA, 아시다시피)라고 부르겠습니다. 기술적 감독 없이 유기적으로 성장한 2017년부터 WordPress를 운영해 왔습니다. 그들의 설정은 의료 진료소의 전형적인 사례였습니다:

  • WordPress 6.2 (플러그인 34개, 그 중 11개는 1년 이상 업데이트되지 않음)
  • 공유 호스팅 (월 $29 요금제)
  • Contact Form 7 (환자 문의 처리 - 암호화 없음, 호스팅 제공자와의 BAA 없음)
  • PDF 접수 양식 (환자가 다운로드하여 인쇄하고, 손으로 작성한 후 팩스하거나 약속 시간에 가져와야 함)
  • 평균 페이지 로드 시간 (모바일 6.8초)
  • Lighthouse 모바일 점수: 38

그 Lighthouse 점수는 오타가 아닙니다. 38점입니다. 사이트에는 최적화되지 않은 영웅 이미지(하나는 4.2MB PNG), 5개의 서로 다른 플러그인의 렌더링 차단 CSS, 플러그인 충돌로 인해 3번 로드되는 jQuery가 있었습니다.

그러나 실제 문제는 성능이 아니었습니다. 위험이었습니다.

그들의 연락처 양식은 환자 이름, 전화번호, 때로는 의료 불만 설명을 수집하고 있었습니다. 이 데이터는 암호화되지 않은 양식 플러그인을 통해 흘러가고 있었고, 공유 호스팅의 WordPress 데이터베이스에 저장되었으며, BAA(사업 파트너 계약)가 없는 서비스에 백업되고 있었습니다. 그들의 규정 준수 담당자가 이를 지적했고, 그들의 의료 과오 보험 담당자가 날카로운 질문을 하고 있었습니다.

요구사항

그 진료소는 다음이 필요했습니다:

  1. 자신들의 의료 수준을 반영하는 빠르고 현대적인 웹사이트
  2. 종이 프로세스를 대체하는 HIPAA-안전 환자 접수 양식
  3. 개발자를 부를 필요 없이 사무실 관리자가 업데이트할 수 있는 CMS
  4. 더 나은 SEO 성능 (새로운 진료소에 지역 검색 순위를 잃고 있었음)
  5. 모두 예산 친화적으로 - 그들은 기술 스타트업이 아니라 의료 진료소입니다

Next.js와 Payload CMS를 선택한 이유

우리는 여러 아키텍처 옵션을 평가했습니다. 다음은 클라이언트에게 제시한 정직한 비교입니다:

옵션 장점 단점 예상 비용
WordPress 재구축 (새 테마 + 플러그인) 스태프가 익숙함, 낮은 초기 비용 동일한 HIPAA 위험, 성능 한계, 플러그인 의존성 $15-25K
Webflow + 타사 양식 빠른 빌드, 좋은 성능 HIPAA 준수 옵션 제한, 지속적인 사용자당 비용, 공급업체 종속성 $20-30K
Next.js + Payload CMS 완전한 제어, HIPAA-안전 아키텍처, 최고 성능 높은 초기 투자, 호스팅 관리 필요 $35-50K
Next.js + Sanity 훌륭한 편집 경험, 좋은 생태계 Sanity의 가격은 사용량에 따라 증가, PHI 처리의 클라우드 호스팅 CMS 우려사항 $30-45K

우리는 Payload CMS와 함께 Next.js를 권장했으며, 그 이유는 다음과 같습니다.

Next.js는 올바른 프론트엔드였습니다

Next.js 14(이 프로젝트는 2024년 말에 시작되었으며, 현재는 15에서 실행 중입니다)는 의료 사이트가 필요로 하는 것을 정확히 제공했습니다:

  • 콘텐츠 페이지의 정적 생성 — 의사 약력, 서비스 설명, 위치 정보. 이러한 페이지는 거의 변경되지 않으므로 빌드 시간에 미리 렌더링합니다. 요청 시간에 서버 계산이 없음은 빠른 TTFB를 의미합니다.
  • 동적 콘텐츠용 서버 컴포넌트 — 약속 가능성, 블로그 게시물, 접수 양식 로직 모두 클라이언트에 불필요한 JavaScript를 보내지 않고 서버 측 렌더링의 이점을 얻습니다.
  • 기본 이미지 최적화 — next/image는 자동 WebP/AVIF 변환으로 4MB PNG를 적절히 크기가 지정되고 지연 로드된 이미지로 대체했습니다.
  • 보안 헤더용 미들웨어 — 우리는 Next.js 미들웨어를 사용하여 엄격한 CSP 헤더, HSTS 및 HIPAA 감사자가 좋아하는 기타 보안 헤더를 설정합니다.

궁금하신 분들을 위해 우리는 Next.js 개발 능력을 더 자세히 문서화했습니다.

Payload CMS는 올바른 백엔드였습니다

우리는 의료에 특정한 여러 이유로 다른 헤드리스 옵션보다 Payload CMS 3.0을 선택했습니다:

기본 설계로 자체 호스팅됩니다. Payload는 자신의 인프라에서 실행됩니다. 이는 HIPAA에 필수 불가결합니다. 보호된 건강 정보(PHI)를 처리할 때, 데이터가 정확히 어디에 있는지, 누가 액세스할 수 있는지 알아야 하며, 인프라 제공자와 BAA에 서명할 수 있어야 합니다. Contentful이나 Sanity와 같은 클라우드 호스팅 CMS 플랫폼은 자신의 서버에 데이터를 저장합니다. 일부는 엔터프라이즈 계층에서 HIPAA 준수를 제공하지만, 비용은 일반적으로 Payload를 HIPAA-적격 제공자에서 자체 호스팅하는 데 드는 비용의 3-5배입니다.

TypeScript-네이티브. Payload의 설정은 단순히 TypeScript입니다. 이는 우리의 콘텐츠 모델, API 응답, 프론트엔드 타입이 모두 동일한 정보 소스를 공유함을 의미합니다. 사무실 관리자가 접수 양식에 "보험 사전 승인 번호"에 대한 새로운 필드를 추가하면, 우리의 프론트엔드는 생성된 타입을 통해 즉시 이에 대해 알게 됩니다.

기본 제공 접근 제어. Payload의 필드 수준 접근 제어는 마케팅 담당자가 블로그 게시물과 서비스 페이지를 편집할 수 있지만 환자 접수 데이터에는 접촉할 수 없는 역할을 만들 수 있음을 의미합니다. 사무실 관리자는 접수 제출을 볼 수 있지만 양식 구조를 수정할 수 없습니다. 이 세분성은 규정 준수를 위해 접근 제어를 문서화할 때 중요합니다.

제대로 된 리치 텍스트. Payload는 리치 텍스트를 위해 Lexical(이전 Slate)을 사용하며, 편집 경험은 정말 좋습니다. WordPress를 수년간 사용해온 우리 클라이언트의 사무실 관리자는 단 한 번의 45분 교육 세션 내에 Payload의 관리 패널에서 편안했습니다.

우리는 정기적으로 Payload 및 다른 헤드리스 CMS 플랫폼과 함께 작업합니다. 우리의 헤드리스 CMS 개발 접근 방식에 대해 더 알아볼 수 있습니다.

헤드리스 아키텍처의 HIPAA 고려사항

명확히 하고 싶은 것이 있습니다: 기술 스택 자체로는 "HIPAA 준수"될 수 없습니다. HIPAA 준수는 소프트웨어 기능이 아니라 조직 관행입니다. 기술 스택이 될 수 있는 것은 "HIPAA-안전" - 즉, 불필요한 위험을 도입하지 않고 HIPAA가 요구하는 관리, 물리, 기술 보호조치를 지원한다는 의미입니다.

다음이 우리가 구현한 것입니다:

인프라

  • 호스팅: BAA가 서명된 AWS. 우리는 Payload CMS 컨테이너를 위해 ECS Fargate를 사용했으고 Next.js 프론트엔드를 Vercel에 배포했습니다(PHI를 처리하지 않음 - 중요한 구분입니다).
  • 데이터베이스: Amazon RDS PostgreSQL (휴지 중 AES-256 암호화 및 전송 중 TLS 1.2+ 암호화 포함). Payload 3.0은 기본적으로 Postgres를 지원하며, 이것이 우리가 v3을 기다린 큰 이유였습니다.
  • 파일 저장소: 서버 측 암호화, 액세스를 제한하는 버킷 정책, 감사 추적을 위한 버전 관리가 있는 S3.

환자 접수를 위한 데이터 흐름

이것이 아키텍처가 흥미로워지는 곳입니다. 환자 접수 양식은 Next.js 프론트엔드에 있지만, 우리는 절대 PHI를 Vercel의 인프라를 통해 전송하지 않습니다.

Patient Browser → HTTPS → API Route (Next.js on Vercel) → NO PHI stored here
                                    ↓
                           AWS API Gateway (with WAF)
                                    ↓
                           Lambda function (validates, encrypts)
                                    ↓
                           Payload CMS API (on ECS Fargate)
                                    ↓
                           RDS PostgreSQL (encrypted at rest)

Next.js API 경로는 얇은 프록시 역할을 합니다. 요청 구조(CSRF 토큰, 속도 제한, 기본 필드 검증)를 검증하지만 PHI를 기록하거나 저장하지 않습니다. 실제 데이터 처리는 AWS의 HIPAA-적격 서비스 내에서 완전히 발생합니다.

암호화 상세 정보

우리는 가장 민감한 데이터에 대해 필드 수준 암호화를 구현했습니다. 환자 SSN 단편(마지막 4자리), 보험 ID, 의료 불만 설명은 데이터베이스에 도달하기 전에 AES-256-GCM을 사용하여 애플리케이션 계층에서 암호화됩니다. 이는 누군가가 데이터베이스 액세스를 얻더라도 민감한 필드에 대해 암호화된 블롭을 볼 것임을 의미합니다.

// Payload의 필드 수준 암호화 훅의 단순화된 버전
import { encrypt } from '../lib/crypto';

const PatientIntake: CollectionConfig = {
  slug: 'patient-intake',
  hooks: {
    beforeChange: [
      async ({ data }) => {
        if (data.ssnLastFour) {
          data.ssnLastFour = await encrypt(data.ssnLastFour);
        }
        if (data.medicalComplaint) {
          data.medicalComplaint = await encrypt(data.medicalComplaint);
        }
        return data;
      },
    ],
  },
  access: {
    read: ({ req: { user } }) => {
      return user?.role === 'office-admin' || user?.role === 'provider';
    },
    create: () => true, // Public form submission
    update: ({ req: { user } }) => user?.role === 'office-admin',
    delete: () => false, // Retention policy - no deletions through CMS
  },
  fields: [
    // ... field definitions
  ],
};

감사 로깅

환자 접수 데이터에 대한 모든 액세스는 기록됩니다 - 누가, 언제, 어느 IP에서 본 것인지. 우리는 별도의 감사 로그 테이블에 쓰는 커스텀 Payload 플러그인을 구축했습니다. 이 테이블은 추가 전용입니다. 관리자 사용자도 항목을 수정하거나 삭제할 수 없습니다. 그 진료소의 연간 HIPAA 위험 평가 중에 이 감사 추적이 강점으로 특별히 언급되었습니다.

Healthcare Practice: WordPress to Next.js + Payload CMS Migration - architecture

환자 접수 프로세스 재설계

이전 프로세스: 환자가 6페이지 PDF를 다운로드하고, 인쇄하고, 펜으로 작성하고(종종 읽기 어려움), 사무실에 가져가며, 스태프 구성원이 이를 EHR 시스템에 수동으로 입력합니다. 다운로드에서 EHR 입력까지의 평균 시간: 3-5영업일.

새로운 프로세스: 환자가 약속 48시간 전에 문자 메시지 또는 이메일 링크를 받고, 약 8분 동안 휴대폰에서 다단계 양식을 완성하며, 데이터는 그들이 문을 통과하기 전에 그 진료소의 시스템에서 사용할 수 있습니다.

양식 UX 결정

우리는 접수 양식을 7단계로 나누었습니다:

  1. 신원 확인 (이름, 생년월일, 연락처)
  2. 보험 정보 (보험자, ID, 그룹 번호, 카드 사진 업로드)
  3. 의료 병력 (상태 체크리스트, 수술 병력)
  4. 현재 약물 (개방형 의약품 데이터베이스에서 자동완성 포함)
  5. 방문 이유 (자유 텍스트 + 통증 위치용 신체 다이어그램)
  6. 동의 및 계약 (전자 서명 캡처)
  7. 검토 및 제출

실제로 큰 차이를 만든 몇 가지 UX 세부사항:

  • "3단계 중 7단계"를 보여주는 진행 지표는 모든 필드를 한 번에 보여주는 우리의 초기 프로토타입에 비해 포기율을 대략 40% 감소시켰습니다. 우리는 소프트 출시 중에 이를 A/B 테스트했습니다.
  • 보험 카드 사진 업로드 (자동 자르기 및 미리보기 포함). 환자는 카드의 앞면과 뒷면을 촬영합니다. 이것만으로도 약 60%의 프론트 데스크 데이터 입력이 제거되었습니다.
  • RxNorm API를 사용한 약물 자동완성. 환자가 "hydroxychloroquine" 철자를 시도하는 대신 "hydro"를 입력하고 필터링된 목록에서 선택합니다. 이는 약물 입력 오류를 크게 줄였습니다.
  • 세션 지속성 — 환자가 양식을 시작했다가 중단되면, 그들의 진행 상황이 저장됩니다(sessionStorage에서 암호화됨, localStorage가 아님) 30분 동안. 그들은 중단된 곳에서 재개할 수 있습니다.
// RxNorm API를 사용한 약물 자동완성
const useMedicationSearch = (query: string) => {
  return useQuery({
    queryKey: ['medications', query],
    queryFn: async () => {
      if (query.length < 3) return [];
      const res = await fetch(
        `/api/medications/search?q=${encodeURIComponent(query)}`
      );
      return res.json();
    },
    staleTime: 1000 * 60 * 5, // Cache for 5 minutes
    enabled: query.length >= 3,
  });
};

서버 측 약물 검색 엔드포인트는 우리의 AWS 백엔드를 통해 RxNorm을 쿼리하여 외부 API 호출을 클라이언트에서 멀리 유지하고 결과를 캐시할 수 있도록 합니다.

성능 결과 및 Lighthouse 점수

이전과 이후는 다음과 같습니다:

측정 항목 WordPress (이전) Next.js + Payload (이후) 개선
Lighthouse 모바일 38 94 +147%
Lighthouse 데스크톱 61 99 +62%
First Contentful Paint (모바일) 4.2s 0.8s -81%
Largest Contentful Paint (모바일) 8.1s 1.4s -83%
Total Blocking Time 1,840ms 45ms -98%
Cumulative Layout Shift 0.34 0.01 -97%
Time to Interactive 9.3s 1.2s -87%
페이지 가중치 (홈페이지) 4.8MB 340KB -93%
Core Web Vitals 통과 No Yes (all green) —

모바일 Lighthouse 점수 94(100이 아님, 그 이유는 잠시 후 설명하겠습니다)는 사이트에서 가장 JavaScript가 많은 페이지인 환자 접수 페이지에서 측정되었습니다. 홈페이지 및 서비스 페이지와 같은 콘텐츠 페이지는 모바일과 데스크톱 모두에서 일관되게 98-100점을 기록합니다.

모바일에서 완벽한 100이 아닌 이유는? 두 가지 이유:

  1. 약물 자동완성 위젯은 접수 양식 페이지에 약 12KB gzipped를 추가하는 클라이언트 측 JavaScript가 필요합니다.
  2. 우리는 봇 방지 계층으로서 접수 양식에 reCAPTCHA v3을 사용하며, Google의 reCAPTCHA 스크립트는 정확히 가벼운 것이 아닙니다. 우리는 이를 지연 로드하지만, 여전히 몇 점을 잃습니다.

Lighthouse 100을 치기 위해 reCAPTCHA을 제거하는 것을 고려했지만, 보안 이점이 허영 측정을 능가합니다. 봇 보호가 없는 의료 접수 양식은 실제 환자 데이터와 혼합된 스팸 제출을 요청하는 것입니다.

마이그레이션 전략: 무중단, 순위 손실 없음

의료 진료소 웹사이트 마이그레이션은 중단이 문자 그대로 놓친 환자 약속을 의미하기 때문에 스트레스가 많습니다. 우리는 이를 어떻게 처리했는지:

콘텐츠 마이그레이션

우리는 WordPress REST API에서 콘텐츠를 가져오고 이를 Payload CMS 문서로 변환하는 마이그레이션 스크립트를 작성했습니다. 스크립트는 다음을 처리했습니다:

  • 47개의 서비스 페이지
  • 12명의 의사/제공자 프로필
  • 89개의 블로그 게시물 (이미지 재호스팅 포함)
  • 6개의 위치 페이지
  • 모든 SEO 메타데이터 (제목, 설명, 표준 URL)

URL 매핑

모든 WordPress URL은 해당하는 Next.js 페이지로 매핑되었습니다. 가능한 경우 동일한 URL 구조를 유지했으며 변경된 소수의 URL에 대해 next.config.js에서 301 리다이렉트를 설정했습니다:

// next.config.js
const redirects = async () => [
  {
    source: '/services/:slug',
    destination: '/orthopedic-services/:slug',
    permanent: true,
  },
  {
    source: '/team/:slug',
    destination: '/providers/:slug',
    permanent: true,
  },
  // ... 23 more redirects
];

DNS 전환

우리는 블루-그린 배포 전략을 사용했습니다. 새 사이트는 우리가 테스트하는 동안 2주 동안 병렬로 실행되었습니다. 전환 날에 일요일 저녁 유지보수 기간 동안 DNS 레코드를 업데이트했습니다. 총 가시적 다운타임: 약 3분 (DNS 전파는 빠르게 진행되었습니다. 우리가 일주일 전에 TTL을 60초로 미리 낮췄기 때문입니다).

SEO 결과

출시 후 3개월:

  • 유기 트래픽 34% 증가
  • "orthopedic doctor near me"의 평균 위치는 14위에서 5위로 개선
  • Google의 클릭률은 28% 증가 (더 나은 Core Web Vitals = 더 나은 모바일 SERP 경험)
  • 이전에 인덱싱된 URL에 대한 Search Console의 404 오류 0개

기술 아키텍처 심층 분석

전체 그림을 원하는 사람들을 위해:

┌─────────────────────────────────────────────┐
│                  Vercel                       │
│  ┌─────────────────────────────────────────┐ │
│  │  Next.js 15 App Router                  │ │
│  │  - Static pages (ISR, 60s revalidation) │ │
│  │  - Server Components                    │ │
│  │  - API routes (proxy only, no PHI)      │ │
│  └─────────────────────────────────────────┘ │
└──────────────────┬──────────────────────────┘
                   │ HTTPS
┌──────────────────▼──────────────────────────┐
│              AWS (HIPAA BAA)                 │
│  ┌──────────────┐  ┌─────────────────────┐  │
│  │  API Gateway  │  │  CloudFront (assets)│  │
│  │  + WAF        │  └─────────────────────┘  │
│  └──────┬───────┘                            │
│         │                                    │
│  ┌──────▼───────┐  ┌─────────────────────┐  │
│  │  ECS Fargate  │──│  RDS PostgreSQL     │  │
│  │  (Payload 3)  │  │  (encrypted)        │  │
│  └──────┬───────┘  └─────────────────────┘  │
│         │                                    │
│  ┌──────▼───────┐  ┌─────────────────────┐  │
│  │  S3 (uploads) │  │  CloudWatch (logs)  │  │
│  │  (encrypted)  │  │  (audit trail)      │  │
│  └──────────────┘  └─────────────────────┘  │
└─────────────────────────────────────────────┘

월 인프라 비용: AWS(ECS Fargate는 이 규모에서 놀랍도록 저렴함)에서 대략 $180-220/월 + Vercel Pro에서 $20/월. 이전에 있던 $29/월 공유 호스팅과 비교하면 - 네, 더 비싸지만, 그들은 HIPAA-적격 인프라, 자동 확장, 그리고 진정한 보안을 얻습니다.

배운 교훈

1. HIPAA 대화를 일찍 시작하세요. 우리는 한 줄의 코드도 쓰기 전에 3주를 건축 계획에 보냈습니다. 이는 우리를 최소 두 가지 잠재적 재설계에서 구했습니다.

2. Payload CMS v3은 기다릴 가치가 있었습니다. 우리는 Payload 3.0이 베타에 있을 때 이 프로젝트를 시작했습니다. 거친 모서리가 있었습니다 - 마이그레이션 문서가 불완전했고, 일부 플러그인이 아직 업데이트되지 않았습니다. 그러나 기본 Postgres 지원과 개선된 관리 UI는 올바른 선택을 만들었습니다.

3. 접수 양식을 과도하게 엔지니어링하지 마세요. 우리의 첫 번째 프로토타입은 6단계 깊이의 조건부 로직을 가지고 있었습니다. 사무실 관리자는 이를 보고 말했습니다: "순서대로 질문을 할 수 없을까요?" 그녀가 맞았습니다. 우리는 단순화했고, 완성율이 올랐습니다.

4. 의료 클라이언트는 CMS 교육에 대한 손을 필요로 합니다. 우리는 우리의 일반적인 하나의 교육 세션 대신 3번의 교육 세션과 공통 작업을 위한 녹음된 Loom 비디오를 제공했습니다. 교육에 대한 투자는 사무실 관리자가 지원 티켓을 제출하지 않고 새로운 제공자 페이지를 추가할 수 있게 된 첫 달에 자신을 보상했습니다.

5. 성능 예산은 협상 불가능합니다. 우리는 프로젝트 시작 시 성능 예산을 <400KB 페이지 가중치 및 <100ms Total Blocking Time으로 설정했습니다. 모든 PR은 CI에서 이 예산에 대해 확인되었습니다. 우리가 애니메이션 그림 라이브러리를 추가하려고 한 유일한 시간은 예산을 부풀렸고, 우리는 배포되기 전에 이를 포착했습니다.

유사한 의료 또는 규제 산업 사이트 마이그레이션을 고려 중이라면, 우리는 구체적인 사항을 논의하는 것을 기꺼이 도와드립니다. 직접 우리에게 연락하거나 프로젝트 범위에 대해 가격 페이지를 확인할 수 있습니다.

자주 묻는 질문

Next.js 및 Payload CMS를 사용하는 것이 자동으로 사이트를 HIPAA 준수하게 만드나요? 아니요. 기술 스택 자체로는 본질적으로 HIPAA 준수될 수 없습니다. HIPAA 준수는 관리 보호조치(정책, 교육, 위험 평가), 물리적 보호조치(시설 접근 제어), 기술 보호조치(암호화, 접근 제어, 감사 로그)가 필요합니다. Next.js와 Payload CMS가 제공하는 것은 기술 보호조치를 적절하게 구현할 수 있는 유연한 아키텍처입니다 - 특히 Payload의 자체 호스팅 특성으로, PHI가 있는 곳을 제어할 수 있습니다.

Jotform 또는 FormStack과 같은 HIPAA-준수 양식 서비스를 사용하지 않는 이유는? 절대 할 수 있으며, 더 간단한 사용 사례의 경우 합리적인 선택입니다. 우리는 Jotform의 HIPAA 계획($99/월)과 FormStack($83/월)을 평가했습니다. 이 클라이언트의 문제는 통합 깊이 - 그들은 접수 데이터가 실시간으로 보험 적격성을 확인하고 자신의 EHR 시스템을 미리 채우는 커스텀 워크플로우로 흘러들어가기를 원했습니다. 기성 양식 도구는 상당한 미들웨어 없이 그것을 처리할 수 없었으며, 그 시점에서 당신은 어차피 커스텀 인프라를 구축하고 있습니다.

총 프로젝트 비용과 타임라인은? 프로젝트는 14주에 걸쳐 약 $42,000으로 마무리되었습니다. 여기에는 발견 및 아키텍처 계획(3주), 디자인(2주), 개발(7주), 테스트/마이그레이션(2주)이 포함됩니다. 지속적인 호스팅 및 유지보수는 인프라 비용 및 소규모 지원 보유료를 포함하여 월 약 $250입니다.

Payload CMS가 의료 그룹의 여러 위치를 처리할 수 있나요? 네. 우리는 주소, 시간, 제공자, 허용된 보험, 위치별 콘텐츠에 대한 필드가 있는 "위치" 컬렉션을 Payload에 구축했습니다. 각 위치는 지역 SEO를 위한 구조화된 데이터 마크업(LocalBusiness 스키마)과 함께 Next.js에 의해 생성된 자신의 페이지를 얻습니다. 새로운 위치를 추가하는 것은 Payload의 관리 패널에서 새로운 항목을 만드는 것만큼 간단합니다.

Payload CMS 서버가 중단되면 어떻게 되나요? Next.js 프론트엔드는 Vercel의 CDN에서 정적으로 생성된 페이지를 제공하므로 Payload 백엔드가 완전히 중단되어도 주 웹사이트는 계속 실행됩니다. 환자 접수 양식은 백엔드 중단 중에 사용할 수 없지만, 우리는 자동 재시작 정책, 30초마다 상태 확인, CloudWatch 알람을 설정하여 우리 팀과 진료소의 IT 담당자에게 알립니다. 6개월의 생산 중에 계획되지 않은 다운타임이 0시간입니다.

작은 진료소가 한 위치인 경우 이 아키텍처가 과도한가요? 그것은 환자 데이터로 무엇을 하고 있는지에 달려 있습니다. 전화 번호와 주소만 있으면 되는 브로슈어 사이트라면, 좋은 테마가 있는 WordPress는 괜찮습니다 - 이 중 아무것도 필요하지 않습니다. 그러나 웹사이트를 통해 PHI를 수집하는 순간(접수 양식, 의료 설문지, 의료 세부 정보가 있는 약속 요청), 적절한 보안 제어를 지원하는 인프라가 필요합니다. 우리가 구축한 아키텍처는 잘 축소됩니다 - 단일 위치 진료소는 더 낮은 트래픽으로 인해 인프라에서 더 적게 지불합니다.

마이그레이션이 Google 순위에 어떤 영향을 미쳤나요? 마이그레이션 직후에 우리는 짧은(약 10일) 순위 변동을 경험했으며, 이는 정상입니다. 3주차까지 순위가 안정화되었고 상향 추세를 보였습니다. 3개월 후, 유기 트래픽은 34% 증가했으며 진료소의 주요 키워드는 평균 4위 개선했습니다. Core Web Vitals 개선이 가장 큰 요인이었습니다 - Google이 검색 결과에서 그들의 이전 사이트의 나쁜 모바일 성능에 페널티를 가하고 있었습니다.