Drupal SEO에는 실력에 비해 과한 평판이 따라붙습니다. 주변에 물어보면 Drupal은 설치만 해도 검색에 강하다는 답이 돌아오는데, 대개는 다른 플랫폼에 대한 십오 년 전 기억과 비교하면서 하는 이야기입니다. 기본 상태의 Drupal 11 설치본에는 메타 디스크립션 필드가 없고, XML 사이트맵도 없으며, URL이 바뀔 때 자동으로 걸리는 리다이렉트도 없습니다. 그리고 편집자가 직접 별칭을 입력하기 전까지 콘텐츠는 /node/123에서 응답합니다.

이것은 프로젝트에 대한 비판이 아닙니다. 코어는 의도적으로 자기 영역을 좁게 유지하고, 견해가 갈리는 것은 모두 컨트리뷰트 모듈로 밀어냅니다. 규모가 큰 Drupal 사이트를 대부분의 플랫폼보다 정밀하게 다듬을 수 있는 이유가 바로 그것입니다. 다만 그 말은 기본 상태라는 표현이 아주 많은 것을 떠안고 있다는 뜻이기도 합니다. Drupal 사이트의 검색 성과는 첫날 어떤 모듈을 설치했고 누가 그것을 어떻게 설정했는지에 따라 거의 전부 결정됩니다.

아래는 2026년 9월 기준으로 그 스택을 정리한 기록입니다. 코어가 무엇을 해주는지, 다른 시스템이 공짜로 얹어주는 기능을 어떤 컨트리뷰트 모듈이 대신하는지, Drupal에만 존재하는 실패 유형은 무엇인지, 그리고 처음에 이 작업이 하나도 되지 않은 사이트를 되살리는 데 얼마가 드는지에 대한 이야기입니다.

Drupal은 설치 직후 상태로 SEO에 강한가요? 아닙니다. 코어는 경로 별칭, canonical 링크 태그, 그리고 튼튼한 다국어 라우팅 계층을 제공하지만 메타 디스크립션, XML 사이트맵, 리다이렉트 처리, 구조화된 데이터는 제공하지 않습니다. 그 네 가지는 Pathauto, Metatag, Simple XML Sitemap, Redirect라는 네 개의 컨트리뷰트 모듈에서 옵니다. 이들이 빠진 Drupal 사이트는 최적화가 서툰 것이 아니라 아예 최적화되지 않은 상태입니다.

Drupal 코어가 실제로 해주는 것

코어가 주는 것 중 중요한 것은 세 가지이고, 세 가지 모두 정말 잘 만들어져 있습니다.

코어의 Path 모듈은 어떤 경로에든 사람이 읽을 수 있는 별칭을 붙일 수 있게 해줍니다. 덕분에 노드는 내부 경로 대신 /services/tax-advice에서 응답할 수 있습니다. 코어는 그 별칭을 저장하고 요청을 그 별칭으로 해석합니다. 코어가 하지 않는 일은 별칭을 만들어내는 것입니다. 그래서 노드가 2,000개인 사이트에서는 누군가 별칭 2,000개를 직접 입력해야 하고, 현실에서 그 일을 끝까지 하는 사람은 없습니다.

코어는 엔티티 페이지에 링크 관계도 출력합니다. 노드를 보면 별칭이 붙은 URL을 가리키는 rel="canonical"과 별칭이 없는 URL을 가리키는 rel="shortlink"가 생성되는데, 플러그인 없이는 이것을 해내지 못하는 상용 플랫폼이 여럿이라는 점을 생각하면 충분하고도 남습니다. 아래에서 설명할 중복 경로 문제가 치명상이 아니라 그럭저럭 견딜 만한 수준에 머무는 것도 바로 이 동작 덕분입니다.

세 번째는 언어입니다. 코어의 다국어 스택은 경로 접두사, 언어별 별칭, 번역된 엔티티의 대체 언어 링크를 처리하며, Drupal의 검색 이야기에서 가장 강한 부분입니다.

나머지는 전부 컨트리뷰트입니다. 콘텐츠 타입에 메타 디스크립션 필드는 직접 추가하기 전까지 존재하지 않고, 사이트맵도 리다이렉트 테이블도 없으며, 노드를 삭제하면 404만 남고 그것으로 끝입니다.

사실상 필수인 네 개의 모듈

drupal.org에는 SEO 라벨을 단 모듈이 수십 개 있습니다. 그중 네 개는 선택 사항이 아니며, 하나라도 건너뛴 Drupal 구축물은 경쟁 사이트에는 없는 구멍을 안게 됩니다.

Pathauto

Pathauto는 토큰 패턴으로 별칭을 생성합니다. 예를 들어 blog/[node:title] 같은 패턴을 두면 노드를 저장하는 순간 별칭이 자동으로 만들어집니다. Drupal에서 사실상 모든 사이트에 깔려 있는 모듈에 가장 가까운 존재로, 464,471개 사이트가 사용을 보고하고 있습니다. 현재 안정 릴리스는 2026년 5월 4일자 8.x-1.15이며 Drupal 10.2와 11을 지원합니다. Token 모듈에 의존합니다.

Pathauto가 도움이 될지 해가 될지를 가르는 설정은 업데이트 액션입니다. 제목이 바뀌어 패턴이 다른 별칭을 만들어낼 때 무슨 일이 벌어질지를 이 설정이 정합니다. Pathauto는 아무것도 하지 않을 수도, 별칭을 그대로 교체할 수도, 새 별칭을 만들면서 옛 별칭에서 오는 리다이렉트를 함께 남길 수도 있습니다. 원하는 것은 세 번째이고, 이 선택지는 Redirect 모듈이 설치되어 있을 때만 나타납니다. 약한 기본값에 방치된 사이트는 노드마다 살아 있는 별칭을 여러 개씩 조용히 쌓아갑니다.

Metatag

Metatag은 Drupal 페이지가 메타 디스크립션을 갖게 되는 유일한 경로이며, Open Graph와 Twitter Card 출력도 함께 담당합니다. Damien McKenna가 2012년부터 유지보수해 왔고 332,868개 사이트가 사용을 보고하며, 2025년 9월에 나온 2.2.0 릴리스는 Drupal 10.3 또는 11을 요구합니다.

작동 방식은 엔티티 타입과 번들별로 토큰 패턴 형태의 기본값을 두고 그 위에 노드 단위 재정의를 얹는 구조입니다. 흔한 실패는 콘텐츠 타입 전체에서 똑같이 해석되는 패턴이고, 그 결과 수백 개의 페이지가 하나의 디스크립션을 공유하게 됩니다. 이것은 디스크립션이 아예 없는 것보다 나쁩니다. 그 페이지들이 서로 바꿔 써도 되는 것이라고 크롤러에게 알려주는 셈이기 때문입니다.

Simple XML Sitemap

코어는 어떤 종류의 사이트맵도 만들어주지 않습니다. Simple XML Sitemap이 표준적인 답이며 137,418개 사이트가 사용하고, 2025년 11월 26일자 4.2.3 릴리스는 Drupal 10.3 또는 11을 요구합니다. 엔티티와 뷰, 임의의 링크를 색인하고 hreflang과 이미지 항목도 출력하는데, 이는 다국어 구축에서 대단히 중요합니다.

설정은 전체가 아니라 번들별로 하십시오. 전부 넣고 싶어지는 것이 기본적인 유혹이지만, 그렇게 하면 택소노미 용어 페이지와 사용자 프로필, 필터가 걸리지 않은 뷰 목록까지 사이트맵으로 들어가고, 가장 얇은 페이지가 우선순위라고 검색 엔진에 말하게 됩니다.

Redirect

Redirect는 수동 리다이렉트를 제공하고, 더 중요하게는 canonical URL 강제를 제공합니다. 어떤 콘텐츠에 대한 canonical이 아닌 요청을 모두 canonical 경로로 돌려보낼 수 있습니다. 265,749개 사이트가 사용하며 2026년 4월 24일자 8.x-1.13이 Drupal 10과 11을 지원합니다.

분명히 짚어둘 주의점이 하나 있습니다. 프로젝트 페이지에는 현재 공동 관리자를 찾는다는 안내가 걸려 있는데, 이만큼 비중이 큰 모듈이라면 이는 피할 이유라기보다 지켜봐야 할 유지보수 리스크입니다. 여전히 Drupal 보안 권고 정책의 적용 대상이라는 사실은 변하지 않습니다.

다른 플랫폼에는 없는 Drupal SEO 함정

모든 노드는 살아 있는 URL을 최소 두 개 갖는다

다른 시스템에서 넘어온 사람들이 가장 놀라는 지점입니다. Drupal에서 별칭을 추가해도 내부 경로는 은퇴하지 않습니다. /node/123은 200과 함께 완전한 페이지를 계속 반환하고, 업데이트 액션이 그것을 허용했다면 그 노드가 지금까지 받은 모든 별칭도 마찬가지로 계속 응답합니다.

코어의 canonical 태그가 피해를 줄여주고, Google은 canonical 표기를 지시가 아니라 강한 신호로 취급하며 리다이렉트와 나란히, 사이트맵 포함보다는 위에 둡니다. 그러나 강한 신호는 보장이 아닙니다. 견고한 해법은 Redirect 모듈의 canonical 강제이며, 중복을 영구 리다이렉트로 바꿔버리기 때문에 통합할 것 자체가 남지 않습니다.

택소노미 용어 페이지가 불어난다

코어는 택소노미 용어마다 목록 페이지를 만듭니다. 자유 태그 어휘가 있는 사이트라면 태그 하나당 페이지 하나라는 뜻이고, 그 대부분은 노드를 한두 개만 담은 채 템플릿 제목만 있고 설명은 없습니다. 이런 페이지가 수백 개 있다는 것은 아무도 일부러 만들지 않은 얇은 콘텐츠 문제입니다.

사이트 전체가 아니라 어휘별로 판단하십시오. 편집상 실질적 가치가 있는 카테고리는 색인되게 하고 직접 쓴 설명을 붙입니다. 자유 태그 어휘는 사이트맵에서 제외하고, 대부분의 경우 noindex를 붙입니다.

뷰 페이지네이션과 ?page= 흔적

코어의 모든 뷰 목록은 ?page= 파라미터로 페이지를 나누고, 그 하나하나가 별개의 URL입니다. Google의 안내는 연속된 각 페이지가 고유한 URL과 고유한 canonical을 가져야 한다는 것이고, 첫 페이지로 canonical을 되돌리지 말라는 것이며, rel next와 rel prev는 더 이상 쓰이지 않는다는 것입니다.

Drupal에 특유한 부분은 같은 뷰의 노출 필터와 정렬이 페이저와 곱해진다는 점입니다. 노출 필터가 세 개이고 결과가 마흔 페이지인 목록은 자기가 가진 콘텐츠보다 훨씬 많은 주소를 만들어내고, 그 전부가 실제로 렌더링됩니다.

패싯과 파라미터 폭발

패싯 검색, 보통 Search API 위에 올린 Facets 모듈이 여기서 문제를 어수선함에서 크롤링 예산 문제로 바꿔놓습니다. 2026년 9월 1일에 릴리스된 Facets 3.0.6은 Drupal 10.1과 11을 지원하며 56,746개 사이트가 사용합니다. 이 모듈도 공동 관리자를 찾는다는 안내를 달고 있습니다.

Google은 크롤러가 패싯 내비게이션 URL을 엄청나게 많이 훑고 나서야 그 URL들이 쓸모 있는 곳으로 이어지지 않는다는 것을 알 수 있고, 그 과정이 여러분의 크롤링 예산과 구글의 연산 자원을 함께 소모한다고 경고합니다. 어떤 패싯 조합을 색인 대상으로 삼을지 일찍 정하고 나머지는 차단하며, 같은 필터 집합이 언제나 같은 URL을 만들도록 파라미터 순서를 고정하십시오.

게시 상태의 흔들림

비공개로 만들어져 임시 제목을 달았다가 일주일 뒤 다른 제목으로 공개된 노드는 생성 시점에 별칭 하나, 공개 시점에 또 하나를 만듭니다. 업데이트 액션을 잘못 두면 둘 다 살아 있고 둘 다 계속 크롤링됩니다. 여기에 편집팀과 일 년치 작업량을 곱하면 별칭 테이블이 노드 테이블보다 커집니다. SEO 감사가 게시된 노드 수와 살아 있는 URL 수를 대조할 때 찾는 것이 바로 이 패턴입니다.

Drupal의 구조화된 데이터

길은 두 갈래이고, 그 선택은 보기보다 중요합니다.

Schema.org Metatag은 Metatag을 확장해 페이지 head에 JSON-LD를 출력하며 스물다섯 가지가 넘는 스키마 타입을 다룹니다. 2026년 2월 19일자 3.0.4 버전은 Drupal 9, 10, 11을 지원하고 66,363개 사이트가 사용합니다. Redirect나 Facets과 마찬가지로 이 모듈도 공동 관리자를 찾고 있습니다.

장점은 Metatag의 상속 모델을 통째로 물려받는다는 것입니다. 번들별 기본값, 필드 값을 끌어오는 토큰, 노드 단위 재정의, 그리고 원시 JSON을 볼 일이 없는 편집자까지 그대로입니다. 한계는 모듈이 모델링한 것만 표현할 수 있다는 점입니다. 깊게 중첩된 스키마, 이를테면 상품에 오퍼와 리뷰와 반품 정책이 얽히면 필요해지는 종류는 토큰 필드로 조립하기가 까다롭습니다.

Twig 템플릿에 JSON-LD를 직접 쓰면 완전한 제어권을 얻는 대신 편집 인터페이스를 잃습니다. 템플릿이 몇 개 안 되고 개발자가 곁에 있는 사이트라면 대개 그쪽이 더 나은 거래입니다. 콘텐츠 타입이 예순 개이고 콘텐츠 팀이 있는 사이트에서는 그렇지 않습니다. 스키마를 바꿀 때마다 배포가 필요해지기 때문입니다.

한 가지 길만 고르십시오. 저희가 가장 자주 보는 실패는 둘이 나란히 돌면서 게시 날짜가 서로 어긋나는 Article 블록 두 개를 내보내는 상태입니다.

다국어 Drupal과 hreflang

여기가 Drupal이 평판값을 제대로 하는 지점이고, 이 글의 나머지가 빈틈 이야기인 만큼 분명히 적어둘 가치가 있습니다.

코어는 언어 모듈을 함께 제공하며, 콘텐츠 번역을 켜면 Drupal은 컨트리뷰트의 도움 없이 번역된 엔티티에 대체 언어 링크를 출력합니다. 경로 접두사, 언어별 별칭, 언어별 메뉴가 모두 배송 상태 그대로 동작합니다.

현지화 버전에 대한 Google의 요구 사항은 모든 버전이 자기 자신과 나머지 전부를 함께 나열할 것, 표기가 양방향일 것, 그리고 대체 수단으로 x-default가 있을 것입니다. Drupal의 번역 모델은 앞의 두 가지를 자동으로 충족합니다. 대체 항목이 편집자가 입력하는 값이 아니라 번역 세트에서 생성되기 때문입니다. hreflang이 누군가 잊어버릴 수 있는 플러그인 필드인 플랫폼들에 비하면 진짜 우위입니다.

그래도 두 가지는 여전히 어긋납니다. x-default 값은 자동으로 설정되지 않으므로 Metatag이나 템플릿으로 추가해야 합니다. 그리고 번역이 일부만 있는 세트는 원본 언어로 되돌아가는 페이지를 가리키는 대체 항목을 만들어내는데, 이는 표기를 아예 넣지 않는 것보다 나쁜 신호입니다.

성능과 코어 웹 바이탈

Drupal의 캐시 계층은 코어 기능이고 잘 만들어져 있으며, 아무도 끝내는 것을 기억하지 못한 디버깅 세션 때문에 꺼진 채로 남아 있는 일이 잦습니다.

렌더 캐시는 캐시 가능성 메타데이터와 함께 조각을 저장합니다. 조각이 의존하는 데이터를 나타내는 캐시 태그, 무엇에 따라 출력이 달라지는지를 나타내는 캐시 컨텍스트, 그리고 최대 유효 시간입니다. 태그는 바탕이 되는 엔티티가 바뀌면 자동으로 무효화됩니다. 메타데이터를 잘못 두면 오래된 페이지를 내보내거나 아무것도 캐시하지 못하게 됩니다.

Internal Page Cache는 익명 방문자에게 완성된 페이지를 내보냅니다. Dynamic Page Cache는 개인화된 부분만 빼고 전부 캐시해 어떤 사용자에게든 페이지를 내보냅니다. 그리고 Drupal 8.1부터 코어에 들어왔고 8.5부터 표준 설치 프로필에 포함된 BigPipe는 최초 응답을 이미 내보낸 뒤에 그 개인화된 자리표시자를 스트리밍합니다.

코어 웹 바이탈과 관련해서는 짚을 점이 좁습니다. BigPipe는 체감 로딩을 개선하지만, 채워 넣을 자리표시자에 공간을 잡아두지 않으면 Cumulative Layout Shift를 악화시킬 수 있습니다. Drupal 사이트의 Largest Contentful Paint는 보통 렌더 캐시가 아니라 히어로 이미지와 합쳐진 CSS 번들이 결정합니다. Drupal 11.4는 PHP 확장을 쓸 수 있을 때 Brotli로 압축한 CSS와 JavaScript 자산을 생성하는 기능을 추가했는데, 자산을 직접 서빙하는 사이트라면 명확한 이득입니다.

메이저 버전 업그레이드가 깨뜨리는 것

Drupal 메이저 업그레이드는 플랫폼 교체가 아니지만, 검색 노출을 특정하고 반복되는 방식으로 깨뜨립니다.

보통은 컨트리뷰트 모듈이 원인입니다. Metatag이 목표 버전에 대응하지 못한 상태로 사이트가 그것 없이 오픈되면 사이트의 모든 메타 디스크립션이 한꺼번에 사라지고, 두 주쯤 뒤 노출수가 떨어질 때까지 아무도 알아채지 못합니다. 사이트맵 모듈도 마찬가지이고, Redirect는 더 나쁩니다. Redirect를 잃으면 canonical 강제가 멈추고 옛 별칭이 전부 되살아나기 때문입니다.

두 번째 원인은 이동을 견디지 못하는 설정입니다. Metatag 기본값, Pathauto 패턴, 사이트맵 번들 설정은 모두 구성으로 저장되며, 콘텐츠는 가져왔지만 구성은 가져오지 않은 재구축 사이트는 기본 패턴으로 돌아와 같은 콘텐츠에 다른 URL을 붙입니다.

시작하기 전에 전체 크롤을 떠서 모든 페이지의 URL, 상태 코드, 제목, 디스크립션, canonical을 기록하고, 작업 후 같은 크롤과 비교하십시오. 저희 Drupal 마이그레이션 가이드가 버전 경로와 거기에 걸린 기한을 다룹니다.

Drupal 버전들의 현재 위치

시기에 따라 무엇을 먼저 하는 것이 합리적인지가 달라집니다. Drupal 11.4.0은 2026년 7월 1일에 나왔고 11.4.x 브랜치는 2027년 6월까지 보안 지원을 받습니다. 2022년 12월 15일에 나온 Drupal 10은 2026년 12월 9일에 지원이 종료되고, Drupal 12는 2026년 12월 7일이 있는 주로 예정되어 있으며 베타는 2026년 9월 중순에 나올 예정입니다.

실질적인 결론은 이 글을 쓰는 시점에 Drupal 10 사이트에 남은 보안 지원이 대략 석 달이라는 것입니다. Drupal 10 사이트에 발주하는 SEO 작업은 업그레이드 전이 아니라 후로 배치해야 합니다. 순서를 반대로 하면 두 번 지불하게 되기 때문입니다. 한 번은 메타데이터를 고치느라, 또 한 번은 모듈 버전이 올라가면서 출력이 바뀔 때 말입니다.

Drupal 11.1부터 11.4까지는 PHP 8.3과 8.4에서 돌아가고, Drupal 10은 최소 PHP 8.1을 요구합니다. 공유 호스팅에서 실제 걸림돌이 되는 것은 Drupal 작업 자체가 아니라 이 PHP 하한선인 경우가 아주 많습니다.

Drupal SEO 프로젝트 비용

먼저 범위를 제대로 잡으십시오. Drupal SEO 프로젝트는 보고서가 아니라 특정 코드베이스 안에서 하는 설정 작업과 템플릿 작업이며, 산출물은 문서가 아니라 바뀐 사이트입니다.

기본 감사는 네 개 모듈 구성과 그 설정 상태, 별칭과 리다이렉트 테이블, 택소노미와 뷰 노출, 사이트맵 내용, 구조화된 데이터 출력, 캐시 계층을 다룹니다. 노드가 수백 개인 사이트라면 사흘에서 닷새 작업입니다. 영국의 테크니컬 SEO 일당은 보통 600에서 1,200파운드 사이이므로, 이런 형태의 테크니컬 SEO 감사는 담당자 연차와 사이트 규모에 따라 대략 2,000에서 5,000파운드에 자리합니다.

구현은 별개이며 대체로 더 큽니다. 콘텐츠가 이미 있는 운영 사이트에 Pathauto, Metatag, Simple XML Sitemap, Redirect를 설치하고 설정한다는 것은 별칭을 일괄 생성하고, 바뀌는 별칭 전부에 대한 리다이렉트 매핑을 만들고, 중복으로 무너지지 않는 디스크립션 패턴을 쓴다는 뜻입니다. 이 단계에는 감사 비용의 한 배에서 두 배를 잡으십시오.

패싯 검색이 있는 다국어 Drupal 사이트는 이 구간 위에 있습니다. 영국 에이전시는 Drupal 작업에 하루 대략 600에서 900파운드를 청구하며, 이는 Drupal 개발자 요율에 관한 저희 가이드에서 다룹니다. 번역 세트가 여럿이고 패싯 거버넌스까지 포함하는 프로젝트라면 현실적으로 열흘에서 스무 날입니다.

작업 전후 크롤 비교를 명시된 산출물로 요구하십시오. 그것이 없으면 실제로 무엇이 바뀌었다는 증거가 없습니다.

순서를 제대로 잡기

통하는 순서는 화려하지 않습니다. 무엇보다 먼저 네 개 모듈을 설치하고 설정하십시오. 그것들 없이 내린 콘텐츠 결정은 나중에 재작업을 낳습니다. 다음으로 중복 URL 표면을 닫습니다. 사이트의 모든 페이지에 닿는 문제이기 때문입니다. 그다음이 택소노미와 뷰 노출, 이어서 구조화된 데이터, 그리고 성능입니다. 콘텐츠와 링크는 기술 계층이 안정된 뒤에 오고, 결코 그 전에 오지 않습니다.

Mecanik은 이 순서를 크롤 결과만이 아니라 Drupal 코드베이스와 그 구성을 대상으로 수행하는 테크니컬 SEO 감사로 진행하며, 뒤따르는 구현은 SEO 감사 서비스가 맡습니다. Drupal이 애초에 맞는 플랫폼인지 아직 정하지 못했다면, 저희 Drupal 개발 가이드와 헤드리스 CMS와 전통적 CMS 아키텍처 비교가 이 글보다 나은 출발점입니다.

자주 묻는 질문

Drupal은 설치 직후 상태로 SEO에 강한가요? 아닙니다. Drupal 코어는 경로 별칭, canonical 링크 태그, 다국어 라우팅을 제공하지만 메타 디스크립션, XML 사이트맵, 리다이렉트 처리, 구조화된 데이터는 제공하지 않습니다. 그것들에는 Pathauto, Metatag, Simple XML Sitemap, Redirect 모듈이 필요하며 모두 코어가 아니라 컨트리뷰트입니다. 기본 설치본은 최적화가 서툰 것이 아니라 최적화되지 않은 상태입니다.

Drupal 사이트에 실제로 필요한 SEO 모듈은 무엇인가요? 사실상 필수는 네 개입니다. URL 별칭을 자동 생성하는 Pathauto, 메타 디스크립션과 소셜 태그를 위한 Metatag, 사이트맵 자체를 위한 Simple XML Sitemap, 그리고 리다이렉트와 canonical URL 강제를 위한 Redirect입니다. Twig 템플릿에 JSON-LD를 직접 쓰지 않고 구조화된 데이터를 내보내고 싶다면 다섯 번째는 보통 Schema.org Metatag입니다.

URL 별칭을 추가했는데 /node/123이 계속 열리는 이유는 무엇인가요? Drupal 별칭은 내부 경로를 은퇴시키지 않기 때문입니다. 두 주소 모두 200 상태로 완전한 페이지를 반환합니다. 코어는 별칭을 가리키는 canonical 태그를 내보내지만 Google은 이를 지시가 아니라 강한 신호로 취급하므로, 확실한 해법은 Redirect 모듈의 canonical URL 강제이며 중복을 영구 리다이렉트로 바꿉니다.

Pathauto, Metatag, Simple XML Sitemap은 Drupal 11과 호환되나요? 네, 그리고 핵심 네 개 모두 활발히 유지보수되고 있습니다. Pathauto 8.x-1.15는 Drupal 10.2와 11을 지원하고, Metatag 2.2.0은 Drupal 10.3 또는 11을 요구하며, Simple XML Sitemap 4.2.3도 Drupal 10.3 또는 11을 요구하고, Redirect 8.x-1.13은 Drupal 10과 11을 지원합니다. 네 개 모두 Drupal 보안 권고 정책의 적용을 받습니다.

영국에서 Drupal SEO 프로젝트 비용은 얼마인가요? 모듈 구성, 별칭과 리다이렉트 테이블, 택소노미 노출, 사이트맵, 구조화된 데이터를 다루는 설정 감사는 중간 규모 사이트에서 사흘에서 닷새가 걸립니다. 영국 테크니컬 SEO 일당 600에서 1,200파운드로 계산하면 대략 2,000에서 5,000파운드입니다. 구현에는 보통 감사 비용의 한 배에서 두 배가 더 듭니다.