띠가 칸을 덮어도 브라우저는 모릅니다

화면 아래 고정 띠는 페이지 위에 떠 있습니다. 그래서 띠가 입력 칸을 덮고 있어도 브라우저는 칸이 가려진 줄 모릅니다.

휴대폰 자판까지 올라오면 보이는 화면은 더 줄어듭니다.

한 줄 칸과 여러 줄 칸은 눌렀을 때 화면이 움직이는 기준도 다릅니다. 같은 양식에서 어떤 칸은 멀쩡하고 어떤 칸만 가려진다면 이 차이 때문일 수 있습니다.

저희 템플릿 신청 양식에서 메모 칸 아래가 2px 걸렸던 날

2026년 10월 1일에 저희 템플릿의 신청 양식을 점검했습니다. 화면 아래에 버튼 띠가 고정된 페이지였습니다.

한 줄짜리 입력 칸은 누르면 띠 위로 잘 비켜 올라왔습니다. 그런데 여러 줄을 쓰는 메모 칸은 아래쪽이 띠에 걸렸습니다.

앞선 점검에서 권했던 여백 값은 88이었습니다. 그 값을 실제로 넣고 재 보니 메모 칸 아래가 2px 가려졌습니다. 권했던 값만 믿고 넘어갔다면 점검 결과에 「가림 없음」이라고 잘못 적을 뻔했습니다.

그래서 값을 몇 개 대 보며 다시 쟀습니다. 104에서 처음으로 칸 아래가 띠 윗선보다 위로 올라왔습니다.

재는 동안 보니 값을 8px 올려도 칸은 3~5px만 움직였습니다. 여러 줄 칸은 칸 전체가 아니라 지금 글자를 쓰는 줄을 기준으로 화면을 옮기기 때문입니다.

내 사이트 문의 양식에서 눌러 볼 두 가지

휴대폰으로 내 사이트 문의 양식을 열고 맨 아래 칸까지 차례로 눌러 보세요. 누를 때마다 칸이 띠에 가리는지만 보면 됩니다.

여러 줄 칸이 있다면 줄을 여러 번 바꿔 가며 글을 써 보세요. 지금 쓰는 줄이 띠 뒤로 숨는지 확인하면 됩니다.

처음부터 휴대폰 입력까지 맞춘 홈페이지가 필요하시면 홈페이지 제작에서 살펴보실 수 있습니다.

태블릿인데 휴대폰 화면이 나오는 이유

홈페이지는 기기의 화면 폭을 보고 휴대폰 화면, 태블릿 화면, 컴퓨터 화면 가운데 하나를 골라 보여 줍니다. 이때 「폭이 얼마 이하면 이 화면」이라는 경계를 기준으로 나눕니다.

그래서 경계에 딱 걸린 기기는 숫자 하나 차이로 전혀 다른 화면을 받습니다. 아이패드를 세로로 들면 폭이 정확히 768px입니다. 사이트에 「768px 이하면 휴대폰 화면」이라고 적혀 있으면 아이패드 세로는 휴대폰 쪽으로 들어갑니다. 메뉴가 숨겨지고 여러 칸이던 내용이 한 칸으로 합쳐지는 것도 이 때문입니다.

만드는 사람은 보통 컴퓨터와 휴대폰으로만 화면을 봅니다. 태블릿 세로처럼 그 사이에 낀 폭은 열어 볼 일이 적어서 놓치기 쉽습니다. 한국에서도 태블릿으로 홈페이지를 보는 사람이 적지 않고, 상담이나 예약을 태블릿으로 하는 손님도 있습니다.

저희 템플릿을 재 보다가 걸린 경계값

2026년 8월 31일, 저희 템플릿을 휴대폰 폭과 태블릿 폭에서 모두 재 보는 점검을 했습니다. 아이패드 세로에서 메뉴가 통째로 숨겨지고, 여러 칸이던 내용이 모두 한 칸으로 무너졌습니다.

원인은 경계값 하나였습니다. 템플릿 8개, 51곳에 「768px 이하면 휴대폰 화면」이라고 적혀 있었습니다. 폭이 딱 768px인 아이패드 세로가 그대로 휴대폰 쪽으로 넘어간 겁니다.

그 뒤로 저희가 점검할 때 쓰는 기준은 이렇습니다. 휴대폰 화면은 767px까지만 적용하고, 768px부터 1023px까지는 태블릿 화면을 따로 둡니다. 테마가 처음부터 768을 기본값으로 정해 둔 경우는 그 테마의 설계라서 따로 보고 판단합니다.

내 사이트에서 확인해 볼 두 가지

아이패드가 있다면 세로로 들고 내 사이트를 열어 보세요. 메뉴가 보이는지, 내용이 한 줄로만 길게 늘어서 있지 않은지 보면 됩니다.

아이패드가 없으면 컴퓨터 크롬으로도 볼 수 있습니다. 검사를 열고 기기 모양 버튼을 누른 다음 폭을 768로 맞춰 같은 것을 보세요. 이어서 폭을 767로 바꿔 화면이 갑자기 달라지는지도 봐 두세요.

태블릿에서 메뉴가 사라지거나 내용이 한 줄로 무너진다면 오류 수정에 맡기실 수 있습니다.

사이트맵은 검색엔진에게 내미는 주소 목록입니다

사이트맵은 검색엔진에게 「이 주소들을 봐 달라」고 건네는 목록입니다. 여기에 이미 없는 페이지가 섞여 있으면 검색엔진은 그 주소를 찾아갔다가 헛걸음을 하고, 그게 서치 콘솔에 404 오류로 쌓입니다.

지운 페이지가 404로 잡히는 것 자체는 큰일이 아닙니다. 문제는 사이트맵에 주소가 남아 있는 동안 검색엔진이 그 주소를 계속 다시 찾아온다는 점입니다.

페이지를 지웠는데 왜 목록에는 남아 있을까

관리자 화면에서 페이지를 지우면 보통 사이트맵도 같이 바뀝니다. 그런데 다른 경로로 지웠거나, 사이트맵 쪽에 예전 목록이 기억돼 있으면 옛 주소가 한동안 빠지지 않습니다.

저희 템플릿 사이트 4곳에서 옛 주소 7개가 나왔습니다

2026년 9월 29일, 저희 템플릿 사이트 4곳의 사이트맵을 열어 주소를 하나씩 눌러 봤습니다. 휴지통으로 보낸 옛 페이지 주소 7개가 목록에 그대로 있었고, 눌러 보니 모두 404였어요.

원인은 페이지를 지운 방식에 있었습니다. 플러그인을 거치지 않는 방식으로 지우다 보니, 사이트맵을 만드는 검색 최적화 플러그인이 페이지가 없어진 걸 알아채지 못한 겁니다.

한 번에 정리되지도 않았습니다. 사이트맵은 플러그인이 따로 기억해 둔 목록을 내보내는데, 그 위에 페이지 캐시가 한 겹 더 있었거든요. 한쪽만 비우면 다른 쪽에 남은 옛 목록이 다시 나갔습니다. 두 겹을 다 비우고 나서야 옛 주소가 빠졌고, 다시 열어 보니 4곳 모두 사이트맵에 없는 페이지 주소는 하나도 남아 있지 않았습니다.

내 사이트에서 먼저 열어 볼 곳

• 내 사이트 주소 뒤에 사이트맵 주소를 붙여 열고, 최근에 지운 페이지 주소가 목록에 남아 있는지 보세요.
• 구글 서치 콘솔의 페이지 보고서에서 「찾을 수 없음(404)」 목록을 열고, 그 주소가 사이트맵에서 온 것인지 확인해 보세요.

사이트맵과 서치 콘솔 오류를 같이 정리하고 싶으시면 검색 등록 서비스를 이용하실 수 있습니다.

비웠다는 알림이 떴는데 손님 화면은 그대로

2026년 9월 2일에 저희가 운영하는 사이트 한 곳의 화면을 고쳐 올렸습니다. 올린 뒤 캐시를 비웠고, 캐시 플러그인도 비웠다고 알려 줬습니다. 그렇게 두 번 비웠습니다.

그런데 방문자에게는 고치기 전 화면이 계속 나가고 있었습니다. 저장된 화면 파일도 고치기 전 시각 그대로 남아 있었습니다.

저희는 한동안 이걸 몰랐습니다. 고친 뒤 확인할 때 캐시를 건너뛰는 방식으로 열어 봤거든요. 그렇게 열면 새 화면이 보입니다. 새 화면을 보는 사람은 저희뿐이었던 겁니다.

주인 눈에만 바뀌어 보이는 까닭

캐시는 한 겹이 아닙니다. 캐시 플러그인이 옛 화면을 기억하고, 서버와 호스팅 회사, 손님의 브라우저, 그 사이의 전송망도 저마다 옛 화면을 기억할 수 있습니다.

관리자로 로그인해 있으면 캐시를 건너뛴 화면이 보일 때가 많습니다. 그래서 주인은 고쳐진 화면을 보고 손님은 옛 화면을 보게 됩니다.

「비웠습니다」라는 알림도 그대로 믿으면 곤란합니다. 이 알림은 비우라는 명령을 받았다는 표시일 수 있고, 실제로 다 지워졌다는 뜻은 아닐 수 있습니다.

그날 뒤로 저희가 끝났다고 보는 때

이제 저희는 화면 두 개를 나란히 엽니다. 하나는 방문자가 받는 그대로의 화면이고, 다른 하나는 캐시를 건너뛴 화면입니다. 둘이 같아야 끝난 것으로 봅니다.

비우는 때도 따져야 했습니다. 고친 직후에는 서버가 옛 코드를 잠깐 더 쥐고 있을 때가 있습니다. 그 사이에 비우면 비운 자리가 곧바로 옛 화면으로 다시 채워집니다. 그래서 고친 뒤 잠깐 기다렸다가 비웁니다.

다음 날인 2026년 9월 3일에는 이 순서를 사람 손에 맡기지 않기로 했습니다. 올리기와 비우기를 한 번에 하는 저희 배포 절차로 묶었습니다.

로그아웃하고 휴대폰 데이터로도 열어 보세요

먼저 로그아웃하거나 시크릿 창을 띄워 내 사이트를 열고, 고친 곳이 바뀌었는지 봅니다.

휴대폰 데이터로도 한 번 열어 봅니다. 집이나 사무실 인터넷과는 다른 길로 들어가서 보는 셈입니다.

고친 것이 손님 화면까지 갔는지 매번 열어 보기 번거로우시면 관리형 구독으로 맡기셔도 됩니다.

로그인 시도는 어디로 들어왔나

기록을 따라가 보니 시도가 들어온 곳이 여럿이었습니다.

로그인 화면에는 아이디와 비밀번호를 바꿔 가며 넣어 보는 요청이 몰려 있었습니다. 예전 앱 연동에 쓰던 통로로도 시도가 들어왔습니다. 이 통로는 요청 한 번에 비밀번호를 여러 개 넣어 볼 수 있어서 공격하는 쪽이 좋아합니다. 서버에 직접 접속하는 문에도 하루 동안 로그인 실패가 49번 남아 있었습니다.

그때까지 이 서버에는 반복 시도를 따로 막는 장치가 없었습니다. 같은 곳에서 계속 두드려도 서버는 매번 그대로 받아 주고 있었습니다.

비밀번호가 길어도 그냥 두면 손해인 까닭

비밀번호를 길게 만들어 두셨다면 괜찮겠다고 생각하기 쉽습니다. 그래도 그냥 두기 어려운 까닭이 둘 있습니다.

하나는 서버가 지친다는 점입니다. 로그인 시도가 들어올 때마다 워드프레스가 돌아가야 해서, 시도가 쌓일수록 진짜 방문자가 보는 화면이 느려집니다.

다른 하나는 계정 가운데 가장 약한 곳이 뚫린다는 점입니다. 예전에 만든 짧은 비밀번호나 다른 사이트와 같이 쓰는 비밀번호가 계정 하나에만 남아 있어도 거기가 입구가 됩니다. 관리자 계정이 뚫리면 그동안 쌓아 온 글과 검색 유입이 한꺼번에 흔들립니다. 소 잃고 외양간 고치지 않으려면 뚫리기 전에 막아 두는 편이 훨씬 덜 아픕니다.

켜기 전에 지난 기록에 먼저 대 본 이유

2026년 10월 21일, 저희는 서버 입구에서 반복 시도를 자동으로 돌려보내는 장치를 넣었습니다. 서버 입구에서 막으면 워드프레스는 그 요청을 아예 받지 않습니다.

바로 켜지는 않았습니다. 먼저 그동안 쌓인 기록에 대 봤습니다. 기록에는 로그인 시도가 약 1만 2천 건 있었는데, 처음 만든 규칙은 그중 한 건도 잡지 못했습니다. 기록에 적힌 날짜 모양이 규칙이 기대한 모양과 달랐기 때문입니다. 그 부분을 맞추고 다시 대 보니 그 시도를 전부 잡았고, 보통 방문자 요청은 한 건도 걸리지 않았습니다.

규칙이 틀려도 장치는 정상 작동 중으로 보입니다. 켜기만 하고 끝냈다면 막고 있다고 믿으면서 실제로는 아무것도 못 막았을 겁니다. 보안 장치를 켜 두셨다면 정말 시도를 잡고 있는지도 확인해 보셔야 합니다.

켜자마자 막힌 IP가 나왔고, 서버에 있는 사이트들은 모두 평소처럼 열렸습니다.

서버에 손댈 수 없는 호스팅이라면

일반 호스팅을 쓰시면 서버 입구에 장치를 넣기 어렵습니다. 이때 고를 수 있는 길이 둘 있는데, 둘 다 아쉬운 점이 있습니다.

보안 플러그인의 로그인 횟수 제한은 관리자 화면에서 바로 켤 수 있어 편합니다. 다만 시도가 워드프레스까지 들어온 뒤에 막기 때문에 서버는 계속 일을 합니다.

앱 연동 통로를 막으면 대입 시도가 많이 들어오는 문 하나가 닫힙니다. 그런데 그 통로를 쓰는 앱이나 플러그인이 있다면 그것도 같이 멈춥니다. 사이트에서 무엇이 그 통로를 쓰는지 모르고 막으면 엉뚱한 기능이 끊길 수 있으니, 사이트 구성부터 살펴보고 정하셔야 안전합니다.

지금 바로 열어 볼 곳

관리자 화면의 사용자 목록을 열어 지금은 안 쓰는 관리자 계정이 남아 있는지 보세요. 예전 직원이 쓰던 계정이나 외주 작업 때 만든 계정도 함께 살펴보시면 좋습니다.

보안 플러그인을 쓰고 계시다면 로그인 실패 기록 화면도 열어 보세요. 같은 곳에서 반복 시도가 쌓여 있다면 이미 누군가 로그인 화면을 두드리고 있다는 뜻입니다.

기록을 보고 걱정되신다면 저희가 쓰고 계신 서버와 호스팅을 보고 막을 방법을 함께 정할 수 있습니다. 보안 업그레이드 견적도 따로 받아 보실 수 있습니다.

로그인 보안과 정기 점검을 맡기고 싶으시면 관리형 구독을 살펴보세요.

저희는 이 경우를 가장 나쁜 고장으로 봅니다. 방문자는 고장 난 사이트로 보게 되고, 검색엔진은 빈 쪽을 그대로 담아 갈 수 있기 때문입니다.

정상 응답이 왔는데 내용은 0바이트

2026년 9월 2일, 저희가 운영하는 사이트 8곳에서 이런 일이 있었습니다. 기본 글 주소와 검색 결과 주소를 열면 서버는 정상 응답(200)을 보냈습니다. 그런데 내려온 내용은 0바이트였고, 화면은 그냥 하얬습니다.

머리와 바닥만 나오고 본문이 빠진 서비스 페이지

2026년 9월 8일에는 저희 본 사이트의 서비스 페이지 두 쪽이 비어 있었습니다. 이번에도 응답은 정상이었고, 내려온 코드는 70KB였습니다. 그런데 화면에 보이는 글자는 57자뿐이었습니다. 위쪽 머리와 아래쪽 바닥만 그려지고, 그 사이 본문이 통째로 빠져 있었습니다.

자동 점검 20가지를 모두 통과한 빈 쪽

그때 저희는 자동 점검 20가지로 사이트를 살피고 있었습니다. 이 빈 쪽들은 그중 하나에도 걸리지 않았습니다. 점검들이 응답이 정상인지, 죽은 링크가 있는지는 봤지만 속이 비었는지는 보지 않았거든요. 결국 사람이 눈으로 열어 보고 나서야 찾았습니다.

그 뒤 본 사이트 26쪽의 화면 글자 수를 재 봤습니다. 제대로 나오는 쪽은 494자에서 8,639자 사이였고, 빈 쪽은 38자였습니다. 이 차이를 보고 빈 쪽만 따로 잡아내는 점검을 더했습니다.

오류 없이 하얗게 비는 흔한 원인

널리 알려진 원인 몇 가지를 들면 이렇습니다.

테마나 페이지 빌더에 그 주소를 그리는 틀이 없으면, 머리와 바닥만 나오거나 아예 아무것도 나오지 않습니다.

내용을 처음에는 숨겨 두고 자바스크립트로 보이게 하는 구조도 있습니다. 이 구조에서는 스크립트가 멈추면 내용이 있어도 화면에 나오지 않습니다.

응답 코드만 보는 감시는 이런 쪽을 정상으로 넘깁니다.

내 사이트에서 직접 열어 볼 두 곳

원인을 가려서 고치는 일은 사이트마다 다릅니다. 그래도 지금 비어 있는지 아닌지는 직접 열어 보면 바로 압니다.

하나, 내 사이트의 검색 결과 주소와 오래된 기본 글 주소를 열어 보세요. 본문이 나오는지만 보면 됩니다.

둘, 중요한 페이지 몇 개를 휴대폰과 컴퓨터에서 각각 열어 보세요. 머리와 바닥 사이에 본문이 들어 있는지 눈으로 확인하면 됩니다.

빈 화면이나 원인 모를 표시 문제를 고치고 싶으시면 오류 수정 서비스를 이용하실 수 있습니다.

재고는 있는데 장바구니가 비어 있다면

상품 화면만 보면 이상한 데가 없습니다. 옵션 목록도 잘 나오고 재고 표시도 맞습니다. 품절인 옵션을 고르면 담기가 제대로 막히기까지 합니다.

그런데 재고가 있는 옵션을 골라 담기를 누르면 아무 말 없이 넘어가고, 장바구니에는 아무것도 없습니다. 겉으로는 다 돌아가는 것처럼 보이니, 실제로 담아 보기 전에는 알아채기 어렵습니다.

저희가 쇼핑몰 템플릿을 만들다 겪은 일

저희도 쇼핑몰 템플릿을 만들다가 똑같은 일을 겪었어요. 색·크기를 고르는 옵션 상품을 넣었고, 옵션 이름은 한글로 지었습니다.

재고가 넉넉한 옵션을 골라 담았는데 장바구니가 비어 있더군요. 그런데 품절 옵션은 또 멀쩡히 막혔습니다. 재고 확인은 되는데 왜 안 담기는지 몰라서 한참을 헤맸습니다.

알고 보니 옵션을 저장하는 형태가 문제였습니다. 상품 화면이 보내는 옵션 이름과 쇼핑몰에 저장된 옵션 이름의 모양이 달라서, 둘이 서로 짝을 찾지 못했던 거예요. 한글 이름이라서 생긴 어긋남이었습니다.

옵션 목록이나 재고 표시로는 끝까지 티가 안 났고, 재고 있는 옵션을 하나씩 직접 담아 보고 나서야 잡을 수 있었습니다.

한글 옵션 이름이 어긋나는 까닭

우커머스는 옵션 이름을 주소에 쓰기 좋은 모양으로 바꿔서 주고받습니다. 한글 이름은 이 과정에서 모양이 크게 바뀝니다. 화면에서 넘어온 이름과 저장된 이름이 같은 모양으로 맞춰져 있지 않으면, 손님이 고른 옵션을 쇼핑몰이 알아보지 못합니다.

상품을 관리자 화면에서 직접 만들지 않고 가져오기나 자동 등록 같은 방법으로 넣었다면 이 모양이 어긋날 수 있습니다. 그렇게 올린 옵션 상품이 있다면 한 번 더 담아 보시는 게 좋습니다.

내 쇼핑몰에서 직접 담아 볼 것

• 옵션이 있는 상품마다 재고가 있는 옵션을 하나씩 골라 실제로 장바구니에 담아 보세요.
• 장바구니에 담긴 상품에 내가 고른 옵션이 제대로 적혀 있는지 확인해 주세요.

쇼핑몰에서 이런 담기·주문 오류를 고치고 싶으시면 오류 수정에서 맡기실 수 있습니다.

사진보다 글씨가 먼저 그려지는 사이

글씨는 페이지가 열리자마자 그려집니다. 사진은 내려받는 시간이 지나야 화면에 나오고요. 그 사이 사진 자리에는 사진 뒤에 깔린 바탕색이 비칩니다. 이 바탕이 밝은 색이면 흰 글씨가 바탕에 묻혀 버립니다.

이 빈틈은 어느 페이지에나 생깁니다. 처음 들어온 방문자나 통신이 느린 휴대폰에서는 더 길어지고요. 사진 주소가 깨져서 사진이 아예 안 뜨면 글씨는 끝까지 안 보인 채로 남습니다.

저희 랜딩 템플릿에서 흰 글씨가 크림색 바탕에 묻혔던 일

2026년 9월 2~3일에 저희 랜딩 템플릿 한 판에서 사진 띠 위 흰 글씨를 사진이 뜨기 전 상태로 재 봤습니다. 사진 대신 그 뒤의 크림색 바탕이 비쳤는데, 흰 글씨와 크림색 바탕의 대비가 1.09:1이었습니다. 두 색이 거의 같아서 글씨가 사라진 것과 마찬가지였어요.

그동안 몰랐던 데는 까닭이 있었습니다. 글자 대비 검사는 보통 사진이 다 뜬 화면으로 합니다. 그러면 사진이 뜨기 전 순간은 검사에서 빠집니다. 같은 크림색 바탕을 쓰는 다른 화면도 똑같이 걸려 있어서, 화면끼리 맞대 봐도 잡히지 않았습니다.

사진이 뜬 화면은 그대로 두고 뜨기 전만 고쳤습니다

사진이 들어가는 칸 바탕에 짙은 색을 한 겹 깔았습니다. 사진이 뜨면 이 색은 사진에 덮여 보이지 않고, 뜨기 전에만 드러나서 흰 글씨를 받쳐 줍니다.

고친 뒤 같은 자리의 대비는 17.04:1이 됐습니다. 사진이 뜬 뒤의 화면은 하나도 바뀌지 않았고요.

사진 위에 어두운 그라데이션을 얹는 방법은 쓰지 않았습니다. 사진이 어두워져서 원래 디자인과 달라지기 때문입니다. 그라데이션은 대개 아래쪽만 진해서 윗줄 글씨는 그대로 묻힌다는 점도 걸렸습니다.

사진이 다 뜬 뒤에도 글씨가 안 읽힌다면 그건 다른 문제입니다. 그때는 사진 밝기를 보고 모자란 만큼만 어둡게 맞춥니다.

내 페이지도 그런지 확인해 보려면

크롬 개발자 도구를 열고 「네트워크」 칸에서 속도를 느린 휴대폰 통신으로 바꿉니다. 캐시를 끈 채로 새로 고침을 하면 사진이 뜨기 전에 글씨가 보이는지 눈으로 볼 수 있습니다. 다 보고 나면 속도는 원래대로 돌려 두세요.

그 사진이 안 뜨는 날도 한번 떠올려 보세요. 사진 뒤 바탕색이 글씨 색과 비슷하면, 사진이 깨질 때 글씨도 같이 사라집니다.

사진 위 글씨나 첫 화면 칸을 손보고 싶으시면 페이지 제작에서 맡기실 수 있습니다.

제목 줄이 2개면 검색엔진이 고릅니다

테마가 제목을 찍고 검색 최적화 플러그인도 자기 제목을 내면, 한 페이지에서 제목이 두 줄 나갑니다. 오래된 테마나 직접 만든 테마에서 자주 생깁니다.

이러면 둘 중 어느 쪽을 쓸지는 검색엔진이 정합니다. 내가 플러그인에서 정한 제목 대신 테마가 찍은 제목이 검색 결과에 뜰 수 있습니다. 플러그인 화면에서 아무리 고쳐도 검색 결과 제목이 그대로라면 이것부터 의심해 볼 만합니다.

다만 검색엔진은 검색 결과 제목을 따로 고쳐 쓰기도 합니다. 제목이 다르게 뜬다고 해서 늘 제목 줄이 2개라서 그런 것은 아닙니다.

저희 템플릿 사이트 4곳을 재 본 날

2026년 9월 18일에 저희 템플릿 사이트 4곳의 페이지 제목을 쟀습니다. 페이지 소스에 제목 줄이 1개인 곳이 1곳, 2개인 곳이 3곳이었습니다.

원인은 위에서 말한 그대로였습니다. 템플릿은 제목을 직접 찍게 만들어져 있었고, 검색 최적화 플러그인도 자기 제목을 내고 있었습니다.

괜찮아 보였던 1곳이 오히려 함정이었습니다

조심해야 했던 곳은 제목 줄이 1개였던 1곳입니다. 4곳 모두 코드는 같았는데, 그 사이트에서만 플러그인이 제목을 내지 않고 있었습니다.

그 1곳만 열어 보고 「이 구조는 괜찮네」 하고 넘어갔다면, 나머지 3곳은 계속 제목을 2개씩 내보냈을 겁니다. 같은 코드라도 플러그인 상태에 따라 나가는 제목 수가 달라서, 사이트마다 실제로 나간 결과를 따로 봐야 했습니다.

그래서 짐작으로 한쪽을 꺼 버리지 않았습니다. 페이지가 실제로 내보낸 결과에 제목이 이미 있는지 보고, 없을 때만 템플릿이 제목을 찍게 고쳤습니다. 고친 뒤에는 4곳 모두 제목 줄이 1개가 됐습니다.

내 사이트 제목 줄 세어 보기

크롬에서 내 사이트 첫 화면을 열고 페이지 소스 보기를 엽니다. 찾기로 title 을 검색해서 제목 줄이 몇 개인지 세어 보세요. 첫 화면만 보지 말고 글 하나도 같이 열어 봅니다.

제목 줄이 2개라면 두 줄의 문구가 같은지 다른지 봅니다. 그리고 검색 결과에 뜬 내 사이트 제목이 둘 중 어느 쪽과 같은지 맞대 봅니다.

제목과 설명이 검색에 맞게 나가는지 같이 보고 싶으시면 검색 등록 서비스를 이용하실 수 있습니다.

저희 주문서에서도 화면이 저절로 커졌습니다

2026년 8월 31일에 저희 사이트와 템플릿을 휴대폰 폭에서 모두 재 보는 점검을 했습니다. 그때 저희 주문서가 걸렸어요. 아이폰에서 입력칸을 누르면 화면이 저절로 확대됐습니다.

원인은 입력칸 글자 크기였습니다. 아이폰 사파리는 입력칸 글자가 16px보다 작으면 칸을 누를 때 화면을 키웁니다. 15.5px처럼 아주 조금만 작아도 확대가 일어나요. 그 뒤로 저희 점검 기준에 「입력칸 글자는 16px 이상」을 넣었습니다.

아이폰은 왜 화면을 키울까

작은 글씨를 읽기 쉽게 해 주려는 아이폰의 배려입니다. 그래서 화면 확대 자체를 막아 버리면 글씨가 작아 보기 힘든 분들이 불편해집니다. 입력칸 글씨를 키우는 쪽이 낫습니다.

이런 일은 디자인을 컴퓨터 화면에서만 맞췄을 때 잘 생깁니다. 컴퓨터에서 맞춘 크기 그대로 두면 입력칸 글씨가 작게 잡히기 쉽거든요.

전화번호 칸에 문자 키보드가 뜬다면

저희 점검 기준에는 칸마다 이름인지, 이메일인지, 전화번호인지 브라우저에 알려 주는 표시가 있는지도 함께 들어 있습니다.

이 표시가 없으면 전화번호 칸을 눌러도 숫자 키패드 대신 문자 키보드가 뜹니다. 칸 종류를 알려 주면 키보드가 칸에 맞게 뜨고, 이름·전화·이메일 자동 채우기도 잘 됩니다.

내 사이트 문의 양식에서 눌러 볼 것

아이폰 하나로 바로 확인해 볼 수 있습니다.

• 아이폰 사파리로 내 사이트 문의 양식을 열고 입력칸을 하나씩 눌러 보세요. 누를 때 화면이 저절로 커지는지 보시면 됩니다.
• 전화번호 칸을 눌렀을 때 숫자 키패드가 뜨는지, 이메일 칸에서는 @가 있는 키보드가 뜨는지도 봐 주세요.

휴대폰에서 양식 채우기가 불편하다면 오류 수정으로 맡겨 주셔도 됩니다.