Bubble.io 멀티 랜딩 페이지 SEO 전략｜Dynamic Meta Tag 설정 가이드

2026년 10월 4일 읽는 시간 약 18분

Bubble.io로 SaaS나 플랫폼을 만들다 보면 업종, 지역, 고객 유형에 따라 여러 랜딩 페이지가 필요해진다. 이때 페이지를 하나씩 복제하면 제작은 쉬워 보이지만, 수정 사항을 모든 페이지에 반복 적용해야 하고 제목과 설명이 겹치면서 검색엔진에 유사한 페이지로 인식될 가능성도 커진다.

보다 관리하기 쉬운 방법은 하나의 동적 페이지 템플릿과 데이터베이스를 연결해 여러 랜딩 페이지를 생성하는 것이다. 다만 화면에 표시되는 문구만 바꾸는 것으로는 충분하지 않다. 검색엔진이 각 URL을 서로 다른 문서로 이해하려면 페이지 제목, 메타 설명, Open Graph 이미지, 본문, canonical URL, 내부 링크까지 같은 기준으로 설계해야 한다.

이 글에서는 Bubble.io에서 멀티 랜딩 페이지를 구현할 때 필요한 데이터 구조와 Dynamic Meta Tag 설정 방법, 중복 콘텐츠를 줄이는 기준, 배포 후 색인 점검 절차를 실무 관점에서 정리한다.

멀티 랜딩 페이지란 무엇인가

멀티 랜딩 페이지는 동일한 서비스라도 검색 의도나 방문자 조건에 맞춰 별도의 URL과 콘텐츠를 제공하는 구조다. 예를 들어 예약 관리 서비스를 운영한다면 다음과 같이 페이지를 나눌 수 있다.

/landing/hospital-reservation
/landing/beauty-shop-reservation
/landing/academy-reservation

세 페이지는 같은 제품을 소개하지만 대상 업종과 해결하려는 문제가 다르다. 병원 페이지에서는 진료 예약과 노쇼 관리가 중요하고, 미용실 페이지에서는 디자이너별 일정과 재방문 관리가 중요하다. 학원 페이지라면 수업 일정과 상담 예약이 핵심이 된다.

URL 끝부분만 달라지고 제목과 본문이 거의 같다면 검색 노출을 위한 독립적인 페이지로 보기 어렵다. 반대로 각 방문자의 문제와 사용 사례가 분명하게 구분된다면 하나의 템플릿을 사용하더라도 각 URL은 고유한 가치를 가질 수 있다.

페이지 복제보다 동적 템플릿이 유리한 이유

페이지를 업종별로 복제하는 방식은 초기에는 빠르지만 운영 단계에서 문제가 나타난다. 가격 정책이나 CTA 문구가 바뀔 때 모든 페이지를 수정해야 하며, 일부 페이지만 예전 정보가 남을 수 있다. SEO 태그를 복사한 뒤 수정하지 않아 서로 다른 URL에 같은 제목과 설명이 들어가는 실수도 흔하다.

동적 템플릿 방식은 랜딩 페이지 정보를 데이터베이스에 저장하고 URL에 해당하는 레코드를 불러온다. 레이아웃은 하나만 관리하고, 콘텐츠와 메타 정보만 레코드별로 변경한다. 새 랜딩 페이지를 만들 때도 페이지를 복제하는 대신 데이터 한 건을 추가하면 된다.

중요한 점은 템플릿 수를 줄이는 것이 SEO의 목적은 아니라는 사실이다. 검색엔진이 보는 최종 결과물에서는 각 URL마다 고유한 정보가 렌더링되어야 한다.

1. LandingPage 데이터 타입 설계하기

먼저 Bubble의 Data 탭에서 LandingPage 데이터 타입을 만든다. 최소한 다음 필드를 준비하는 것이 좋다.

필드	형식	용도
`name`	text	관리자용 페이지 이름
`slug`	text 또는 Bubble slug	URL 식별값
`seo_title`	text	검색 결과와 브라우저 탭 제목
`meta_description`	text	검색 결과 설명 후보 문구
`og_title`	text	SNS 공유 제목
`og_description`	text	SNS 공유 설명
`og_image`	image	공유용 대표 이미지
`h1`	text	화면의 주제 제목
`intro`	text	첫 화면 또는 도입 설명
`problem_section`	text	대상 고객의 문제
`solution_section`	text	서비스 해결 방식
`faq`	list 또는 별도 타입	페이지별 질문과 답변
`indexable`	yes/no	색인 허용 여부 관리
`published`	yes/no	공개 상태 관리

seo_title과 h1을 별도 필드로 두면 검색 결과용 제목과 화면용 제목을 각각 자연스럽게 조정할 수 있다. 두 문구의 주제는 일치해야 하지만 완전히 동일할 필요는 없다. published와 indexable도 분리해 두면 작성 중인 페이지와 공개는 되었지만 검색 노출이 필요 없는 캠페인 페이지를 구분하기 쉽다.

2. 동적 페이지와 URL 구조 연결하기

랜딩 템플릿 페이지의 Type of content를 LandingPage로 지정한다. 이후 내부 링크나 목록에서 Go to page 액션을 사용할 때 Data to send에 해당 LandingPage 레코드를 전달한다.

URL은 숫자나 무작위 ID보다 페이지 주제를 알 수 있는 영문 slug를 사용하는 편이 낫다.

좋은 예:

example.com/landing/hospital-reservation

피해야 할 예:

example.com/landing/1674893021x445812

slug는 짧고 읽기 쉬우며 장기간 유지할 수 있게 정한다. 광고 추적용 파라미터, 사용자 세션값, 날짜처럼 자주 바뀌는 값을 기본 URL에 포함하면 같은 콘텐츠를 가리키는 주소가 불필요하게 늘어날 수 있다.

슬러그를 변경해야 한다면 이전 주소를 방치하지 말고 Bubble의 SEO/Meta tags 설정에서 301 redirect를 구성해 새 주소로 연결한다. 외부 링크와 기존 검색 신호가 끊기는 것을 줄이기 위한 조치다.

3. Dynamic Page Title 설정하기

Bubble 편집기에서 랜딩 템플릿 페이지 자체를 선택하면 페이지 속성에 Page title 항목이 표시된다. 이 항목은 최종 HTML의 <title> 요소에 해당하며 동적 데이터를 넣을 수 있다.

예시는 다음과 같다.

Current Page LandingPage's seo_title

데이터에는 페이지별로 다음과 같이 저장한다.

병원 예약 관리 프로그램｜노쇼와 전화 예약을 줄이는 방법
미용실 예약 시스템｜디자이너 일정과 재방문 고객 관리
학원 상담 예약 솔루션｜수업 일정과 신규 상담을 한곳에서

모든 페이지 뒤에 동일한 브랜드명을 붙이고 싶다면 동적 제목과 고정 문구를 조합할 수 있다.

Current Page LandingPage's seo_title | 브랜드명

제목은 핵심 검색어를 억지로 반복하기보다 페이지 내용을 명확하게 설명해야 한다. 서비스, 상세 페이지, 홈처럼 구체성이 없는 표현은 피한다. 또한 화면의 H1과 전혀 다른 제목을 넣으면 검색엔진이 페이지의 다른 문구를 참고해 검색 결과 제목을 다시 작성할 수 있다.

4. Dynamic Meta Description 설정하기

페이지 속성의 SEO 관련 영역에서 description을 동적 데이터로 연결한다.

Current Page LandingPage's meta_description

좋은 설명은 서비스 이름만 반복하지 않고 다음 내용을 포함한다.

누구를 위한 페이지인지
어떤 문제를 해결하는지
페이지에서 무엇을 확인할 수 있는지

예를 들어 병원용 랜딩 페이지라면 다음처럼 작성할 수 있다.

전화 예약과 반복되는 노쇼 관리가 부담스러운 병원을 위한 예약 시스템입니다. 환자 예약 접수, 일정 확인, 자동 알림과 운영 흐름을 살펴보고 우리 병원에 맞는 도입 방법을 확인해 보세요.

메타 설명은 순위 상승을 보장하는 문구가 아니라 검색 결과에서 사용자가 페이지 내용을 판단하도록 돕는 요약이다. 실제 본문과 관계없는 할인 문구나 과장된 표현을 넣으면 클릭 후 이탈이 늘 수 있다. 검색엔진이 입력한 설명 대신 본문 일부를 노출할 수도 있으므로, 첫 문단 역시 페이지의 핵심 내용을 분명히 전달해야 한다.

5. Open Graph 태그와 대표 이미지 구분하기

Open Graph 태그는 카카오톡, 페이스북, 링크드인 등에서 URL을 공유할 때 보이는 제목, 설명, 이미지를 결정하는 데 사용된다. 검색용 title과 description만 설정하고 공유 이미지를 비워 두면 여러 랜딩 페이지가 모두 같은 기본 이미지로 표시될 수 있다.

페이지별로 다음 값을 연결한다.

Open Graph title → Current Page LandingPage's og_title
Open Graph description → Current Page LandingPage's og_description
Open Graph image → Current Page LandingPage's og_image

공유용 제목은 검색 제목보다 조금 더 이해하기 쉽게 써도 되지만 본문 주제와 일치해야 한다. 대표 이미지는 업종명만 바꾼 동일 배너를 반복하기보다, 각 페이지의 사용 상황을 구분할 수 있는 이미지와 간결한 문구를 사용하는 편이 좋다.

앱 전체의 기본 공유 정보는 Settings → SEO/Meta tags에서 설정하고, 동적 랜딩 페이지에서는 페이지별 값으로 덮어쓰는 구조가 관리하기 쉽다. 개별 레코드의 이미지나 설명이 비어 있을 때 기본값이 노출되도록 fallback 규칙도 준비한다.

6. Canonical URL로 대표 주소 통일하기

같은 페이지가 Bubble 기본 도메인과 사용자 정의 도메인, 또는 여러 파라미터 주소로 접근된다면 검색엔진은 어느 URL을 대표 주소로 삼아야 할지 판단해야 한다. Bubble의 Settings → SEO/Meta tags에는 canonical URL 관련 설정이 있으며, 사용자 정의 도메인을 운영한다면 기본 Bubble 도메인보다 실제 서비스 도메인을 대표 주소로 일관되게 사용하는 것이 중요하다.

canonical은 중복 페이지를 삭제하거나 사용자를 강제로 이동시키는 기능이 아니다. 검색엔진에 선호하는 대표 URL을 알려주는 신호다. 따라서 내부 링크, 사이트맵, canonical이 서로 다른 주소를 가리키지 않도록 맞춰야 한다.

다음 상황을 특히 확인한다.

개발용 Bubble 주소가 검색 가능한 상태인지
www 포함 주소와 미포함 주소가 혼재하는지
UTM 파라미터가 붙은 주소가 내부 링크에 사용되는지
동일 레코드를 여러 slug로 열 수 있는지
canonical 대상이 오류 페이지나 noindex 페이지인지

단지 키워드만 바꾼 유사 페이지를 canonical로 각각 선언한다고 해서 고유 콘텐츠가 되는 것은 아니다. canonical 설정 이전에 본문의 독립적인 가치가 먼저 확보되어야 한다.

7. 중복 콘텐츠를 줄이는 페이지 작성 기준

멀티 랜딩 페이지에서 가장 흔한 실수는 제목의 업종명만 바꾸고 나머지 본문을 그대로 사용하는 것이다. 예를 들어 세 페이지의 90%가 같고 병원, 미용실, 학원만 교체되어 있다면 방문자에게도 새로운 정보가 거의 없다.

각 페이지에는 최소한 다음 요소가 달라야 한다.

대상 고객의 실제 문제

병원은 노쇼, 개인정보, 진료 일정이 중요하고 미용실은 디자이너별 시간표, 시술 시간, 재방문이 중요하다. 첫 화면부터 해당 방문자의 문제를 구체적으로 설명한다.

기능을 사용하는 과정

기능 목록을 공통으로 복사하지 말고 업종별 이용 흐름을 보여준다. 예를 들어 병원은 환자 예약 → 사전 알림 → 방문 확인, 학원은 상담 신청 → 담당자 배정 → 등록 안내처럼 구성할 수 있다.

사례와 수치의 근거

실제 고객 사례가 없다면 임의의 성과 수치를 만들지 않는다. 대신 적용 시나리오, 체크리스트, 도입 전 확인 사항처럼 직접 검증할 수 있는 정보를 제공한다.

업종별 FAQ

가격, 권한, 알림 방식, 기존 데이터 이전 등 대상 고객이 실제로 묻는 질문을 정리한다. FAQ는 페이지의 정보 밀도를 높이는 데 도움이 되지만, 접었다 펼치는 문구만 대량으로 추가하거나 본문과 관계없는 질문을 넣는 방식은 피한다.

8. 공개 여부와 noindex 관리하기

작성 중인 페이지, 내부 테스트 페이지, 광고 전용 A/B 테스트 페이지까지 모두 색인되면 품질이 낮거나 유사한 URL이 늘어난다. published와 indexable 필드를 기준으로 공개 정책을 구분한다.

완성된 핵심 랜딩 페이지: 공개 및 색인 허용
작성 중인 페이지: 외부 접근 제한 또는 noindex
짧은 기간만 쓰는 광고 변형 페이지: 검색 목적이 없다면 noindex 검토
삭제된 페이지: 관련 새 페이지가 있으면 301 redirect, 대체 페이지가 없으면 적절한 오류 상태 유지

robots.txt에서 크롤링을 막는 것과 noindex는 목적이 다르다. 검색 결과 제외가 목적이라면 검색로봇이 noindex 지시를 확인할 수 있어야 하므로, 무조건 robots.txt에서 먼저 차단하는 방식은 주의해야 한다.

9. 사이트맵과 내부 링크 설계하기

동적 랜딩 페이지는 단순히 데이터베이스에 존재한다고 해서 검색로봇이 자동으로 모두 발견하는 것은 아니다. 공개하고 색인할 페이지를 사이트맵에 포함하고, 서비스 소개나 업종별 솔루션 허브 페이지에서 일반 링크로 연결한다.

내부 링크의 앵커 텍스트도 자세히 보기만 반복하기보다 목적지를 설명하도록 작성한다.

병원 예약 시스템 기능 보기
미용실 고객 예약 관리 방법
학원 상담 일정 자동화 살펴보기

사이트맵에는 공개된 대표 URL만 포함한다. noindex 페이지, 리디렉션되는 이전 주소, 중복 파라미터 주소를 함께 넣으면 사이트가 전달하는 신호가 서로 충돌할 수 있다.

10. 구조화 데이터는 실제 콘텐츠와 일치시킨다

필요하다면 페이지 종류에 맞는 JSON-LD 구조화 데이터를 추가할 수 있다. 소프트웨어 서비스라면 SoftwareApplication, 실제 질문과 답변이 표시되는 페이지라면 FAQ 관련 마크업을 검토할 수 있다. 다만 구조화 데이터는 화면에 없는 정보를 검색엔진에만 보여주는 수단이 아니다.

가격, 평점, 후기 수를 데이터베이스에서 가져온다면 화면의 정보와 JSON-LD의 값이 항상 함께 갱신되어야 한다. 존재하지 않는 리뷰나 검증되지 않은 평점을 넣어 리치 결과를 노리는 방식은 피한다. 또한 구조화 데이터를 넣는다고 리치 결과 노출이 보장되는 것은 아니다.

11. 배포 전후 SEO 점검 절차

동적 태그는 편집 화면에서 올바르게 연결되어 보여도 실제 배포 페이지의 HTML 결과를 확인해야 한다. 다음 순서로 점검한다.

서로 다른 랜딩 URL 세 개 이상을 시크릿 창에서 연다.
브라우저 탭의 제목이 레코드별로 달라지는지 확인한다.
페이지 소스 또는 SEO 검사 도구로 title, description, canonical, Open Graph 값을 확인한다.
H1과 본문 첫 문단이 해당 랜딩 페이지의 검색 의도와 일치하는지 확인한다.
잘못된 slug로 접근했을 때 빈 템플릿이 노출되지 않는지 확인한다.
사이트맵에 공개 URL만 포함되었는지 확인한다.
Google Search Console의 URL 검사에서 크롤링 허용, 색인 가능 여부, 사용자가 선언한 canonical과 Google이 선택한 canonical을 확인한다.
수정 후 재크롤링에는 시간이 걸릴 수 있으므로 즉시 결과가 바뀌지 않아도 일정 기간 추적한다.

특히 데이터가 없는 URL에서 제목만 브랜드명으로 남고 본문이 비어 있는 페이지가 생성되지 않도록 처리해야 한다. 해당 레코드가 없거나 비공개라면 유효한 안내 페이지로 보내거나 적절한 오류 응답을 제공하는 흐름을 설계한다.

자주 발생하는 실수

모든 랜딩 페이지에 같은 meta description 사용

페이지의 차이를 검색 결과에서 설명하지 못한다. 각 대상 고객의 문제와 페이지 내용을 반영해 별도로 작성한다.

H1만 바꾸고 본문은 그대로 복제

페이지 수는 늘지만 정보 가치는 늘지 않는다. 사례, 흐름, FAQ, 도입 기준까지 검색 의도별로 작성한다.

메타 태그를 워크플로로 늦게 변경

페이지가 열린 뒤 클라이언트 측 작업으로 제목을 바꾸는 방식은 초기 HTML에서 원하는 값이 보이지 않을 수 있다. 가능한 한 페이지 속성과 Current Page 데이터에 직접 연결해 처음부터 올바른 태그가 생성되도록 한다.

테스트용 URL을 사이트맵에 포함

미완성 문서와 유사 페이지가 함께 발견될 수 있다. 공개 여부 필드를 기준으로 사이트맵 대상을 관리한다.

canonical만 설정하면 중복 문제가 해결된다고 생각

canonical은 대표 URL 선택을 돕는 신호일 뿐이다. 내부 링크, 사이트맵, 리디렉션, 본문 차별화가 함께 맞아야 한다.

마무리

Bubble.io의 멀티 랜딩 페이지 SEO는 메타 태그 몇 개를 동적으로 연결하는 작업으로 끝나지 않는다. 먼저 LandingPage 데이터 타입에 SEO 정보와 본문 구성 요소를 분리해 저장하고, 사람이 이해할 수 있는 slug로 URL을 만든 뒤, 페이지 속성의 title과 description을 해당 레코드에 직접 연결해야 한다.

그다음 Open Graph 이미지, canonical, 사이트맵, 내부 링크, 공개 상태를 같은 기준으로 관리해야 한다. 무엇보다 중요한 것은 URL마다 실제 방문자가 얻을 수 있는 정보가 달라야 한다는 점이다. 업종명만 교체한 대량 페이지보다 대상 고객의 문제와 사용 과정, 도입 판단 기준을 구체적으로 담은 소수의 페이지가 더 안정적인 구조가 된다.

이 원칙을 지키면 하나의 Bubble 템플릿으로 여러 랜딩 페이지를 효율적으로 운영하면서도 검색엔진과 사용자에게 각 페이지의 목적을 명확하게 전달할 수 있다.