Facebook Open Graph 캐시 강제 새로고침

Facebook — 주요 플랫폼 중 유일하게 — 프로그래밍 방식으로 캐시 새로고침을 요청할 수 있는 방법을 제공합니다. 단일 링크에 대해서는 Sharing Debugger의 다시 스크래핑(Scrape Again) 버튼을 사용하거나, 앱 액세스 토큰을 사용하여 Graph API의 스크래핑 엔드포인트를 호출하세요. WhatsApp, LinkedIn, X에 대해서는 강제 새로고침할 방법이 없습니다. 이러한 플랫폼은 누구에게도 해당 API를 제공하지 않습니다.

모든 사람이 막히는 부분

Meta는 링크 미리보기 페이지 URL을 키로 사용하여 캐싱하며, 이미지 자체의 사본을 보관합니다. Meta는 og:image이 다른 곳을 가리키고 있음을 알기 위해 페이지를 다시 읽지 않습니다.

따라서 다음 워크플로는 실패하며, 이는 가장 많은 사람들이 시도하는 방식입니다:

커버 이미지 변경 → og:image URL이 새로 생성됨 → Facebook이 이를 인식할 것이라고 가정 → 하지만 인식하지 않음.

새로운 이미지 URL은 이미지 CDN의 캐시를 무효화할 뿐입니다. Meta의 페이지 기반 캐시에는 아무런 영향을 미치지 않습니다. Facebook의 캐시를 업데이트하려면 Meta에게 페이지가 변경되었음을 알려야 합니다.

캐시	키 기준	삭제 방법
페이지 캐시 / CDN	페이지 URL	캐시 삭제(purging)
Meta의 링크 미리보기 캐시	페이지 URL	스크랩 엔드포인트 또는 Sharing Debugger
Meta의 이미지 사본	이미지 URL	새로운 이미지 URL
이미지 CDN	이미지 URL	새로운 이미지 URL

developers.facebook.com/tools/debug를 열고 페이지 URL을 붙여넣은 후 Scrape Again을 누르세요. Meta가 페이지를 다시 가져와 캐시된 미리보기를 재생성합니다.

이것은 Meta가 실제로 발견한 내용을 보고하므로, 기대했던 내용이 아닌 실제 상태를 확인할 수 있는 가장 좋은 무료 검증 도구입니다: 누락되거나 중복된 og:image, 접근 불가능한 이미지, 지원되지 않는 형식 등. 두 가지 제한 사항이 있습니다: WhatsApp은 별도의 캐시를 사용하므로(수신자 앱 내) 영향을 줄 수 없으며, 카탈로그 도구가 아닙니다. URL마다 하나씩 처리하며, 속도 제한이 있고 사람이 직접 수행합니다.

옵션 2 — Graph API (플러그인이 호출하는 방식)

FastOG가 사용하는 프로그래밍적 접근 방식은 scrape=true를 사용하여 Graph API로 POST 요청을 보내는 것입니다:

bash

curl -X POST \
  "https://graph.facebook.com/v21.0/?id=$(python3 -c 'import urllib.parse,sys;print(urllib.parse.quote(sys.argv[1],safe=""))' 'https://your-store.com/product/example')&scrape=true&access_token=${APP_ID}|${APP_SECRET}"

주의해야 할 네 가지 세부 사항:

id는 이미지 URL이 아닌 페이지 URL입니다. Meta는 페이지를 기준으로 캐시를 키(Key)로 사용하므로, 이미지 주소에 요청을 보내도 캐시가 새로고침되지 않습니다.
토큰이 필요합니다. — 2017년 10월부터 Meta는 이 엔드포인트에 토큰을 필수로 요구해 왔습니다. {app_id}|{app_secret} 형태의 앱 액세스 토큰(App Access Token)이면 충분하며, 사용자 로그인이 필요하지 않아 백그라운드 작업에서 호출이 가능합니다.
Graph API 버전이 변경됩니다. FastOG는 테스트된 Graph API 버전을 고정(Pin)하여 사용합니다. 자체 코드에서 버전을 고정하기 전에 Meta의 최신 문서와 변경 로그를 확인하세요.
최선의 노력을 다하는 방식(Best-effort)으로 처리하세요. Meta는 스크래핑 호출에 대해 속도 제한(Rate-limit)을 적용하며, 요청이 거부되더라도 Facebook이 자체 일정대로 새로고침할 뿐 페이지의 태그는 이미 정확합니다.

속도 제한이 적용되므로, 대용량 카탈로그를 저장할 때마다 인라인(동기식)으로 호출하지 마세요. 큐에 등록하고 URL 기준으로 중복을 제거하여, 동일한 변경되지 않은 제품의 반복 저장 시 속도 제한 리소스를 낭비하지 않도록 하세요.

옵션 3 — 자동으로 처리하는 플러그인

"Open Graph 캐시 갱신"을 표방하는 플러그인은 크게 두 가지 유형으로 나뉘며, 그중 하나만 Facebook 문제를 해결할 수 있습니다.

메커니즘	삭제 대상	낡은 Facebook 미리보기 해결 여부
이미지 URL에 변경되는 쿼리 문자열을 추가함 (`?v=timestamp`)	이미지 CDN	No — Meta의 캐시는 페이지를 키로 사용함
페이지 URL에 대한 스크랩 엔드포인트를 호출함	Meta의 미리보기 캐시	Yes

플러그인을 설치하기 전에 어떤 유형인지 확인하십시오. 타임스탬프 파라미터는 낡은 이미지에는 효과적인 해결책이지만, 낡은 Facebook 카드에는 효과가 없습니다.

FastOG for WooCommerce는 두 번째 방식을 사용하며, 별도의 설정이 필요 없습니다. 이 플러그인은 WooCommerce의 기본 제품 웹훅을 등록하므로, 제품을 저장하면 해당 제품의 permalink에 대해 Meta 재스크랩이 트리거됩니다. 이 작업은 큐에 쌓이며 짧은 시간 창 내에서 중복이 제거되고, 설계상 best-effort 방식으로 동작하므로 거절이더라도 저장 작업이 실패하지는 않습니다. 이 기능은 제품 페이지(product.created / product.updated)에 적용되며, 카테고리 및 블로그 수정은 포함되지 않습니다.

이미지 측면은 별도로 처리되며, 모든 경쟁사와는 다른 방식으로 동작합니다. FastOG 커버 URL에는 해당 URL을 생성한 값들이 포함되어 있으므로, 가격이나 사진을 수정하면 새로운 커버 URL이 생성됩니다. 더 이상 존재하지 않는 주소의 picture는 Meta가 다시 제공할 수 없습니다.

페이스북이 충분하지 않은 경우

플랫폼	강제 새로 고침 가능 여부	실제 동작
페이스북	예 — 디버거 또는 `scrape=true`	재스크래핑(re-scrape) 요청; 전파 시간에는 차이가 있음
WhatsApp	불가	미리보기가 수신자 앱에 캐시됨; API가 존재하지 않음
LinkedIn	문서화된 프로그래밍 방식 API 없음	자체 일정으로 다시 읽음; 공개적인 타이밍 보장은 제공되지 않음
X / Twitter	문서화된 프로그래밍 방식 API 없음	자체 일정으로 다시 읽음; 공개적인 타이밍 보장은 제공되지 않음
Slack, Discord	불가	수분에서 시간 단위 내에 자체적으로 정리되는 단기 캐시

WhatsApp에서 미리보기가 오래된 경우, 해결책은 페이스북 도구를 사용하는 것이 아니라 스토어 측을 올바르게 설정하여 다음 읽기 시점에 정확한 데이터를 제공하는 것입니다.

스크래핑이 성공했음에도 불구하고 이전 이미지가 여전히 표시되는 경우

다음 목록을 순서대로 확인하세요:

페이지가 여전히 이전 태그를 제공하고 있나요? curl -s https://your-store.com/product/example | grep -i 'og:image' — 만료된 og:image를 포함하는 캐시된 HTML 페이지는 스크래핑을 완전히 무효화합니다. 페이지 캐시를 비워주세요.
페이지에 og:image가 하나 이상 출력되나요? 두 플러그인이 각각 하나씩 생성하면 크롤러는 읽은 첫 번째 태그를 사용합니다. 개수를 세어보세요.
이미지에 접근할 수 있고 차단되지 않았나요? curl -I <image-url>는 이미지 Content-Type와 함께 200를 반환해야 합니다. 소셜 크롤러는 robots.txt를 존중하므로, Disallow: 경로에 있는 이미지는 손상된 파일처럼 보이는 방식으로 실패합니다. 또한 curl는 curl가 robots.txt를 무시하기 때문에 이를 재현하지 못합니다.
이미지 URL이 실제로 변경되었나요? 변경되지 않았다면 콘텐츠도 변경되지 않은 것입니다. 가격/사진 수정이 카드가 참조하는 소스에 제대로 반영되었는지 확인하세요.
디버거를 다시 확인하세요. 이제 새 이미지를 보고하고 있음에도 불구하고 Facebook에서 여전히 이전 카드를 표시한다면, 이는 태그 문제가 아니라 Facebook 자체의 전파 과정입니다.

자주 묻는 질문

Facebook의 Open Graph 캐시를 지우는 공식 API가 있나요?

FastOG는 scrape 엔드포인트(POST https://graph.facebook.com/{version}/?id={page-url}&scrape=true&access_token={token})를 사용합니다. Meta는 Sharing Debugger와 프로그래밍 방식 크롤링 흐름을 문서화하고 있습니다. 정확한 엔드포인트 형태와 Graph API 버전은 변경될 수 있으므로, 직접 구현하기 전에 Meta의 최신 문서를 통해 이를 확인해야 합니다.

아니요. 이는 공개된 도구이며 모든 공개 URL에서 작동합니다. 다만, 정기적으로 실행하거나 카탈로그 전체를 커버하는 작업은 수행할 수 없습니다.

다시 스크래핑하면 FastOG 렌더링 비용이 발생하나요?

일반적으로 그렇지 않습니다. 커버 URL은 콘텐츠에 기반하므로, 콘텐츠가 변경되지 않았다면 URL도 변경되지 않았으며, 이 경우 가져오기는 캐시 히트로 처리되어 렌더링 비용이 발생하지 않습니다. 가격이 변경되면 URL도 변경되므로, 이는 하나의 새로운 렌더링을 의미하며这正是 원하는 렌더링입니다.

Facebook을 다시 스크래핑하면 WhatsApp 미리보기가 수정되나요?

아니요. 두 캐시는 서로 독립적입니다. Facebook의 디버거는 여전히 검증자로서 유용합니다. WhatsApp이 페이지를 가져오는 방식과 동일하게 페이지를 가져와서 발견한 내용을 보고하지만, WhatsApp 캐시를 새로 고칠 수는 없습니다.

Facebook은 미리보기를 얼마나 오래 유지하나요? (핑을 보내지 않을 경우)

Meta는 약 24시간의 표준 재스크래핑 주기를 문서화하고 있지만, 정확한 전파 시간에는 변동이 있을 수 있습니다. 이것이 디버거와 프로그래밍 방식 크롤링 경로가 존재하는 이유입니다.

카탈로그 가져오기 후 모든 제품에 대해 핑을 보내야 하나요?

그것이 큐의 역할입니다. 각 제품에 대해 인라인으로 하나의 요청을 보내면 Meta의 속도 제한에 도달하여 상점의 요청 속도가 느려질 수 있습니다. 큐에 쌓이고 중복이 제거된 상태라면, 카탈로그 전체 스윕은 안전하게 처리됩니다.

Meta가 요청을 거부하면 어떻게 되나요?

시스템이 중단되지 않습니다. 거부되거나 속도 제한된 핑은 Facebook이 즉시가 아닌 자체 일정에 따라 새로 고침한다는 것을 의미합니다. 페이지의 태그는 이미 정확하므로, 이 호출은 최선의 노력을 다하는(best-effort) 방식이며 하드 의존성(hard dependency)이 아닙니다.