본문으로 이동
SEOBlogBot$100 무료 받기

가상 사후 분석

40개의 예약된 게시물, 하나의 나쁜 링크 소스: 사후 분석

이 이야기는 실제 클라이언트가 아닌 실패 패턴을 보여주기 위해 고안된 것입니다. 이름, 수량 및 날짜는 모두 가상의 예시입니다. 여기서 언급된 실수는 매우 실제적이며, 우리가 경험한 모든 파이프라인에서 한 번씩 발생하는 실수입니다.

SEOBlogBot 연구팀 ·

먼 벽에 연결된 하나의 부러진 줄기를 가진 40개의 화분 식물
이것은 픽션으로 읽으세요

아래의 모든 내용은 숫자가 조작된 구성 예시입니다. 실패가 어떻게 전개되는지를 보여줌으로써, 여러분의 팀이 자체 로그에서 동일한 패턴을 식별할 수 있도록 합니다.

시간별 사건 경과

  1. 큐가 채워짐

    콘텐츠 스크립트가 40개의 초안을 워드프레스 스케줄러에 로드합니다. 하루에 두 개씩 20일 동안 배포됩니다. 각 초안에는 3~6개의 외부 출처가 인용되어 있습니다.

  2. 검수는 수동으로만 수행됨

    편집자는 이전에 Semrush 무료 백링크 체크기 박스에 5개의 도메인을 입력했고 이상한 점을 발견하지 못했습니다. 나머지 35개 도메인은 확인되지 않았습니다.

  3. 첫 번째 불만 접수

    한 독자가 인용된 "연구"가 정지된 페이지로 연결된다고 이메일을 보냅니다. 편집자가 한 게시물을 수동으로 수정합니다.

  4. 패턴이 드러남

    40개 초안 중 11개가 참조 도메인이 거의 없는 도메인에 호스팅된 출처를 인용합니다. 이들은 AI 기반 개요에서 생성된 것입니다.

  5. 정리 작업

    팀이 남은 큐를 중단하고 인용문 9개를 다시 작성한 후 다시 게시합니다. 6개 게시물은 이미 약한 출처와 함께 공개되었습니다.

근본 원인, 중요도 순

큐를 막는 장치가 없었고, 이것이 첫 번째 실패였습니다. 브라우저가 있는 사람은 5개 도메인만 확인할 수 있으므로, 35개 전체를 확인하는 검수는 불가능했습니다.

두 번째 원인은 규칙의 부재였습니다. 나쁜 출처의 기준이 문서화되지 않아 모든 편집자가 직관에 의존했고, 목요일에는 그 직관이 피로해졌습니다.

세 번째 원인은 앞의 두 가지 뒤에 숨어 있습니다. 스케줄링 후 결과에 대한 책임자가 없었습니다. 게시물들은 완료된 것처럼 보였지만, 이것이 가장 위험한 형태의 큐입니다.

세 가지 원인 모두 사람 자체의 문제는 아니었습니다. 각 원인은 보이지 않는 규칙의 부재였으며, 이는 기억에 의존해 작동했습니다. 이는 고의적인 실수가 아니기 때문에 수정하기 가장 어려운 유형의 실패입니다.

네 번째로 작은 원인은 배치의 로드 방식이었습니다. 40개의 게시물을 한 번에 로드하면 자연스럽게 멈춰서 확인할 기회가 주어지지 않아 큐가 단순히 늘어났습니다. 해결책은 간단합니다. 배치를 작은 단위로 나누어 로드하고, 다음 단위가 로드되기 전에 각 단위의 검수가 완료되도록 합니다.

시간과 크레딧을 나타내는 나무 작업대 위의 모래시계와 흩어진 돌

수치가 어떻게 나타났을지

이 이야기의 모든 숫자는 가상이지만, 산술은 실제입니다. 각 bulk_dr 호출당 40개의 초안은 40 크레딧, 즉 $0.004가 됩니다.

편집자의 5개 도메인 수동 확인에는 10분이 걸렸습니다. 스크립트는 그 시간의 일부분으로 나머지 35개를 처리할 수 있었을 것입니다.

돈은 이야기의 가장 작은 부분입니다. 실제 비용은 이미 독자가 확인할 수 있었던 6개의 게시物和, 검수가 몇 초 만에 잡아냈을 내용을 수정하는 데 보낸 시간입니다. 이 시간들은 보통 청구서에 포함되지 않습니다.

여기서는 구글이 게시물을 어떻게 처리했는지 예측하지 않습니다. 랭킹에 대한 주장은 없으며, 독자가 접하는 인용문의 질에 대해서만 언급합니다. 이 경계를 유지하세요.

이후 팀이 변경한 사항

네 가지 변경 사항, 모두 일주일 내에 완료할 수 있을 정도로 작음.

01

초안당 한 번 호출

모든 외부 호스트는 게시물이 스케줄링되기 전에 bulk_dr를 거칩니다. 비용은 초안당 1 크레딧입니다.

02

규칙 문서화

팀의 기준치보다 낮은 호스트가 3개 이상인 경우 게시물을 HOLD 상태로 보냅니다. 의사결정 트리에 정확한 규칙이 명시되어 있습니다.

03

게시 후 재검토

월간 감사는 사이트의 수치를 기록하고 하락 시 알림을 보냅니다.

04

책임자 지정

HOLD 알림을 담당할 특정 개인이 지정됩니다. 소유자가 없는 채널로 보내진 알림은 일주일 내에 무시됩니다.

큐가 확인되어야 하는 방식

수정은 큐가 가득 차기 전에 시작됩니다. 세 가지 결정으로 독자가 보기 전에 대부분의 게시물을 잡을 수 있었습니다. 새로운 소프트웨어가 필요하지 않습니다. 목록, 문장, 이름이 필요하며, 팀은 오후 한 시간 안에 이 세 가지를 모두 작성할 수 있습니다.

초안당 호스트 수 세기

누가 확인할지 결정하기 전에 모든 초안의 외부 호스트 수를 세십시오. 호스트가 6개인 초안은 스크립트가 필요하고, 호스트가 1개인 초안은 수동으로 빠르게 확인할 수 있습니다.

Semrush 무료 백링크 체크기 탭은 호스트가 1개인 경우에 적합합니다. 다른 40개의 초안을 감당할 수는 없습니다.

규칙을 문장으로 작성

낮은 호스트가 3개 이상인 경우 HOLD로 보낸다는 규칙은 테스트 가능합니다. "출처를 신중히 확인하라"는 모호한 지침은 테스트할 수 없으며, 피로한 편집자는 이를 적용할 수도 없습니다.

각 규칙에는 HOLD 또는 PASS와 같은 상태와 이를 확인하는 사람을 명시하십시오. 종료 조건이 없는 규칙은 편집자를 혼란스럽게 만듭니다.

출시 전 책임자 지정

첫 번째 게시물이 로드되는 날, HOLD 큐를 책임질 사람이 있어야 합니다. 그 이름이 없으면 첫 번째 알림이 공유 채널에 떨어지고 기다리게 됩니다.

책임자는 모든 초안을 읽을 필요가 없습니다. 매일 HOLD 목록을 확인하고 각 항목에 대한 결정을 내리면 됩니다.

너무 늦게 도착한 신호

정리 작업 전에 팀은 세 가지 신호를 가지고 있었지만, 각각이 제때 도착하지 않았습니다. 신호는 숨겨지지 않았습니다. 받은 편지함, 큐 뷰, 편집자의 메모에 있었지만, 한 곳에 모은 사람이 없었습니다.

독자 불만은 늦은 신호입니다

죽은 인용문을 발견한 독자는 이미 그것을 확인했습니다. 이 메시지는 유용하지만 피해가 발생한 후에 도착하므로 주요 경보가 될 수 없습니다.

유사한 소스의 클러스터는 더 이른 신호입니다

같은 개요에서 희소한 도메인을 인용하는 11개의 초안은 단순한 확인으로도 드러날 수 있는 패턴입니다. 호스트별 그룹화는 저렴하며, 독자가 발견하기 전에 패턴을 찾아냅니다.

조용한 큐가 건강한 큐는 아님

스케줄러가 40개의 게시물을 표시하고 알림이 없다면, 아무도 아무것도 확인하지 않은 것입니다. 침묵은 성공으로 읽히며, 이것이 완성된 것처럼 보이는 큐가 약한 출처를 숨기는 방식입니다.

간단한 카운터가 도움이 됩니다. 오늘 스케줄링된 게시물 수와 오늘 확인된 게시물 수를 세십시오. 이 두 숫자가 다르면 큐가 건강하지 않습니다.

자물쇠가 달린 닫힌 나무 문과 꽃을 조사하는 두 인물

편집자의 다음 조치

편집자의 첫 번째 조치는 남은 큐를 중단하고 스케줄러를 멈추는 것이었습니다. 이는 몇 분 만에 완료되었습니다. 이것이 그 주 동안 계획대로 진행된 유일한 부분입니다. 규칙이 문서화되고 책임자가 지정될 때까지 스케줄러는 새 초안을 위해 닫혀 있었습니다. 아무도 이를 조기에 재개하지 않았습니다.

다음으로 다시 작성이 이루어졌습니다. 영향받은 각 인용문은 편집자가 열고 읽을 수 있는 출처로 대체되었으며, 두 번째 사람이 확인한 후에만 게시물이 다시 스케줄링에 포함되었습니다. 속도가 목표가 아니었습니다. 동일한 실수를 반복하는 빠른 수정은 아무에게도 도움이 되지 않기 때문입니다.

이후 팀은 자신을 위한 짧은 메모를 작성했습니다. 규칙, 책임자, 검수 순으로 나열했습니다. 그 이상은 없었습니다. 이 메모는 비난을 위한 것이 아니며, 아무도 무료 도구를 신뢰했던 이유를 설명하라고 요구받지 않았습니다.

주말이 끝날 무렵 팀은 두 가지 새로운 습관과 하나의 기존 습관을 가졌습니다. 새로운 습관은 호스트 카운팅과 HOLD 목록이었습니다. 기존 습관은 편집자가 게시물이 나가기 전 모든 인용문을 읽는 것이었습니다. 이 부분은 효과가 있었습니다.

다음 검토를 위한 질문

  • 링크 검수 없이 게시물을 스케줄링할 수 있는 단계는 무엇입니까?
  • 스케줄링과 게시 사이에 큐를 확인한 사람은 누구입니까?
  • 마지막 배치에는 몇 개의 호스트가 포함되었으며, 사람이 몇 개를 확인했습니까?
  • 오늘 이름이 지정되지 않은 알림은 무엇입니까?
  • HOLD를 위한 일문장 규칙은 무엇입니까?

교훈

수동 검수는 5개 도메인까지 확장 가능하지만, 스크립트는 5000개까지 확장 가능

Semrush, Ahrefs 또는 Moz의 무료 도구는 사람의 눈으로 확인하기에 적합합니다. 스케줄에 따라 반복되는 작업은 코드에 포함되어야 하며, 호출당 가격과 실행당 로그 라인이 있어야 합니다.

  • 누가 확인할지 결정하기 전에 초안의 호스트 수를 세십시오.
  • 임계값을 문서화하고 자체 이력을 기반으로 조정하십시오.
  • 이러한 스위트들이 더 잘하는 부분에 대해 스위트 비교를 참조하십시오.

자체 검토 시 질문할 사항

솔직하게 답하십시오.

스케줄링과 게시 사이에 큐를 확인한 사람은 누구입니까? 실제로 무엇을 보았습니까? 동료들이 테스트할 수 있는 문장으로 작성된 규칙은 무엇입니까? 어깨를 으쓱하는 대답은 다음 40개의 게시물이 같은 방식으로 끝날 것임을 의미합니다. 이 주에 답변을 런북에 기록하십시오.

독자들이 이 실패에 대해 묻는 질문

이 이야기는 실제 클라이언트를 다루고 있습니까?

아니요. 이는 실패 패턴을 보여주는 가상의 예시입니다. 여기서의 실수는 흔하지만 이름, 수량 및 날짜는 모두 가짜입니다.

왜 팀은 더 빨리 눈치채지 못했습니까?

검사는 한 사람의 머릿속에 있었고 알림은 어디로도 전달되지 않았습니다. 규칙이 문서화되고 이름이 지정된 소유자에게 라우팅되면 동일한 실패를 놓치기가 훨씬 어려워집니다. 해결책은 규칙과 이름이었지, 영웅적인 노력이 아니었습니다.

게이트가 공개된 6개 게시물을 모두 막았을까요?

게이트는 스케줄링 전에 초안을 막았을 것입니다. 이미 공개된 6개 게시물은 여전히 정리가 필요했으므로, 이야기가 롤백이 아닌 다시 작성으로 끝나는 이유입니다.

팀이 할 수 있는 가장 작은 변경은 무엇입니까?

스케줄링 단계에 하나의 bulk_dr 호출을 추가하고 HOLD 규칙을 문서화하십시오. 이 쌍만으로도 이 이야기의 약한 인용문을 플래그 처리했을 것입니다.