이미지 개수에 공식 기준이 있나

먼저 분명히 해둘 것이 있습니다. 네이버가 블로그 글의 이미지 개수·크기·형식을 공식 기준으로 공개한 바는 확인되지 않습니다. 실무에서 쓰이는 숫자는 상위 노출 글을 역으로 관찰해 정리한 업계 벤치마크이고, 그 내용은 본문 최소 1,500자 이상(상위 노출 글 평균은 2,000~3,000자)에 직접 촬영·제작한 원본 이미지 5장 이상, 그리고 다른 글과 겹치는 유사 이미지 회피입니다. 그러니 "다섯 장"은 목표가 아니라 최소선으로 읽는 편이 맞습니다. 개수를 늘리는 것보다 중요한 것은 그 이미지가 직접 만든 것인지입니다. 저품질(검색 누락) 진단의 주요 원인으로 유사·중복 문서와 낮은 원본성이 지목되기 때문입니다. 이것 역시 네이버 공식 판정 기준이 아니라 업계 관찰이라는 점은 감안해야 합니다. 반대로 이미지를 서른 장 붙이는 방식도 권하지 않습니다. 스크롤이 길어져 읽는 사람이 중간에 이탈하고, 페이지가 무거워져 뒤에서 다룰 속도 문제가 생깁니다.

jpg와 webp 중 무엇으로 올리나

용량만 보면 답은 분명합니다. 구글 공식 문서에 따르면 WebP 손실 압축 이미지는 동등한 화질의 JPEG보다 25~34% 작고, 무손실 WebP는 PNG보다 26% 작습니다. WebP는 손실·무손실 두 방식 모두에서 투명도를 지원해, 로고처럼 배경이 비어야 하는 이미지에서 PNG를 대체할 수 있습니다. 다만 여기서 중요한 단서가 있습니다. 이 수치는 파일 용량에 대한 것이지 검색 노출이나 유입 증가를 보장하는 수치가 아닙니다. 그리고 오래된 브라우저나 일부 저작 도구, 일부 국내 서비스 업로더는 WebP를 아직 받아주지 않을 수 있습니다. 그래서 실무 판단은 이렇게 갈립니다. 내가 직접 운영하는 홈페이지나 랜딩페이지처럼 파일을 통제할 수 있는 곳은 WebP로 바꿔 얻는 이득이 크고, 남의 플랫폼에 올리는 사진은 업로더가 받아주는 형식(대개 JPEG)으로 올린 뒤 플랫폼이 알아서 변환하도록 두는 편이 사고가 적습니다.

얼마나 줄여야 화질이 안 깨지나

정답 수치는 없습니다. 같은 압축률이라도 사진의 내용에 따라 결과가 달라지기 때문입니다. 그래서 방식으로 접근합니다. 첫째, 화면에 실제로 표시될 크기보다 지나치게 큰 이미지를 올리지 않습니다. 4000픽셀짜리 원본을 그대로 올려도 화면에서는 1000픽셀 남짓으로 줄여 보여주므로 나머지는 전부 낭비입니다. 둘째, 압축은 한 번만 합니다. 이미 압축된 JPEG을 다시 저장하기를 반복하면 화질이 계단식으로 떨어집니다. 원본은 따로 보관하고, 압축본은 올릴 때마다 원본에서 새로 만듭니다. 셋째, 확인은 눈으로 합니다. 압축한 파일을 실제 업로드할 화면 크기로 띄워놓고 글자 가장자리와 그라데이션 부분이 뭉개졌는지 봅니다. 여기서 문제가 없으면 더 줄여도 되고, 뭉개졌으면 한 단계 되돌립니다.

파일명과 대체 텍스트는 어떻게 쓰나

이미지 파일에 붙는 텍스트는 두 가지 역할을 합니다. 하나는 검색엔진이 이미지의 내용을 이해하는 단서이고, 다른 하나는 이미지가 안 뜰 때 사람이 읽는 설명입니다. 네이버가 스마트렌즈·쇼핑렌즈 같은 이미지 기반 검색을 넓혀 왔다는 점에서 이미지 정보를 채워두는 편이 낫다는 실무 조언이 많지만, 이것이 노출 증가로 이어진다는 인과는 공식 자료로 확인되지 않습니다. 실무 규칙은 단순합니다. 파일명은 카메라가 붙인 숫자열 대신 내용을 알 수 있는 단어로 바꾸고, 대체 텍스트에는 사진에 실제로 보이는 것을 설명합니다. 여기서 흔한 실수가 대체 텍스트에 지역명과 업체명을 반복해 넣는 것입니다. 과도한 키워드 반복은 저품질 진단 원인으로 지목되는 항목이므로 오히려 손해입니다. 사진마다 다른 설명을 붙이는 것이 같은 문구를 복사해 넣는 것보다 낫고, 그 설명이 본문에서 다루는 내용과 이어지면 글 전체의 일관성도 함께 올라갑니다.

업로드가 막히거나 페이지가 느려지면 어디부터 보나

네이버 블로그 에디터의 첨부 제한값(파일당 몇 MB, 한 포스트당 몇 MB)으로 커뮤니티에 정리된 수치가 돌아다니지만, 공식 고객센터 문서로 대조되지 않았습니다. 원출처가 오래된 게시물이라 현재 값과 다를 수 있으므로 숫자를 외우기보다 절차로 대응하는 편이 낫습니다. 업로드가 거부되면 파일 용량을 줄여 다시 시도하고, 그래도 막히면 블로그 고객센터에서 현재 제한값을 확인합니다. 자체 홈페이지 쪽은 측정 지표가 명확합니다. 코어 웹 바이탈 기준 LCP는 2.5초 이내가 양호 등급이고, 페이지가 느려지는 가장 흔한 원인이 용량이 큰 이미지입니다. 로드 시간이 1초에서 3초로 늘어나면 이탈률이 32% 증가한다는 보고도 있지만 이건 여러 조사에서 관찰된 경향치이지 확정된 상수가 아닙니다. 속도는 감으로 판단하지 말고 무료 측정 도구로 수치를 직접 확인하고, 이미지 압축과 형식 변환 뒤에 같은 도구로 다시 재보면 됩니다.