블로깅 시작하기: 개발자를 위한 필수 가이드

그렇다면 블로그를 시작하려는 개발자이신가요? 이 가이드에서는 도메인 이름 및 사이트 생성부터 SEO 및 신디케이션에 이르기까지 자신의 블로그 사이트를 운영하는 과정을 안내하겠습니다.

목차

• 섹션 0(선택 사항) - 블로그 플랫폼에서 글쓰기 시작
  • Dev.to
  • 해시노드
  • 해커눈
• 섹션 1 - 도메인 구매
  • 어떤 도메인 이름을 선택해야 합니까?
  • 도메인 이름을 어디서 구입하나요?
  • 도메인 비용
• 섹션 2 - 정적 사이트 생성기를 사용하여 간단한 사이트 만들기
  • 정적 사이트 생성기란 무엇입니까?
  • SSG를 사용하는 이유는 무엇입니까?
  • Hugo로 기본 사이트 만들기
• 섹션 3 - 블로그를 호스팅하세요
• 섹션 4 - 분석
• 섹션 5 - 기본 SEO
  • Google에 귀하의 존재를 알리기
  • 문제 확인 중
  • 정규화 및 정규화 URL
  • 비공개 GitHub 저장소
  • 백링크 및 도메인 권한
• 섹션 6 - 작업 공유
  • 레딧 사용
  • 특정 하위 레딧에 게시
  • 각 하위 레딧의 규칙을 확인하세요.
  • 커뮤니티에 참여하세요
• 섹션 7 - 블로그 플랫폼에 재게시
  • 재출판된 기사의 정규화
    • dev.to용 표준
    • 해시노드의 캐노니컬
    • HackerNoon의 정규화
    • FreeCodeCamp에서는 정규화할 수 없습니다!
  • 당신을 위한 홍보
  • 재출판의 단점
• 부록
  • 왜 블로그를 하는가?
    • 글쓰기 및 의사소통 능력 향상
    • 당신이 말하는 내용을 알고 있음을 증명할 수 있는 방법을 제공합니다.
    • 자신을 마케팅하고 기회를 창출하는 데 도움이 됩니다.
  • SSG의 빠른 비교
    • 지킬
    • 일레븐티
    • 개츠비
    • 휴고

섹션 0(선택 사항) - 블로그 플랫폼에서 글쓰기 시작

자신의 사이트를 설정하기 전에 약간의 준비 작업을 하고 싶다면 가장 쉽고 간단한 방법은 글을 쓰고 기존 블로그 플랫폼에 작업을 기여하는 것입니다.

궁극적으로 블로그에서 가장 어려운 점은 실제 글쓰기입니다. 적어도 우리 개발자에게는 일반적으로 그렇습니다! 따라서, 당신이 그것을 즐기는지 확인하기 위해 먼저 그것에 대한 느낌을 얻는 것이 나쁠 것은 없습니다. 또한 나중에 살펴보겠지만 이러한 기능은 별도의 블로그 사이트를 설정할 때에도 유용하게 사용할 수 있습니다.

Dev.to

아마도 dev.to 에 대해 들어보셨을 것입니다. 이는 여전히 가장 큰 개발자 블로그 플랫폼이며, 여기서 시작하시기를 권장합니다. 간단한 마크다운 편집기를 사용하여 쉽게 글쓰기를 시작할 수 있고, 독자층이 많기 때문에 작업 내용을 바로 살펴볼 수 있습니다.

여기에는 얼마나 많은 사람들이 귀하의 게시물을 읽고 있는지, 심지어 Reddit이나 Twitter와 같이 게시물을 어떻게 찾았는지 확인하는 데 도움이 되는 뛰어난 분석 기능이 내장되어 있습니다. 이를 통해 작업을 공유할 때 무엇이 가장 효과적인지 확인할 수 있습니다.

디자인에는 게시물에 대한 좋아요와 반응, 메시지 보드 스타일 토론 스레드 등 많은 소셜 미디어 스타일 요소가 포함되어 있습니다. (취향에 따라 장점이 될 수도 있고 단점이 될 수도 있습니다.)

의심스러우면 여기에서 시작하세요!

해시노드

Hashnode 는 최신 개발자 블로그 사이트입니다. 내 생각에는 dev.to보다 훨씬 더 전문적인 느낌이 든다. dev.to보다 훨씬 블로그 중심적인 느낌이 들며 소셜 미디어 사이트와는 덜 비슷합니다. 이는 별도의 블로그 하위 도메인을 제공하여 사이트 내에서 블로그에 약간의 별도의 ID를 제공합니다.

원한다면 원하는 경우 자신의 개인 도메인 이름에 연결할 수도 있습니다.

하지만 안타깝게도 dev.to보다 인기가 훨씬 적고, 내 경험상 트래픽도 거의 발생하지 않습니다. 깔끔한 스타일이 마음에 든다면 한 번 볼만한 가치가 있지만 게시물이 눈에 띄도록 더 많은 노력을 기울여야 할 것입니다.

해커눈

HackerNoon은 귀하가 제출하는 모든 기사가 게시되기 전에 귀하의 기사가 최상의 상태인지 확인하기 위해 귀하와 협력하는 인간 편집자를 거쳐야 한다는 점에서 dev.to 및 Hashnode와 매우 다릅니다. 그러나 그들은 귀하의 기사를 전혀 게시하지 않기로 선택할 수도 있습니다.

여기에는 장단점이 있습니다. 한편으로는 이것은 훌륭한 학습 경험이지만 다른 한편으로는 원하는 시간과 내용을 단순히 게시하는 자유를 제한합니다. 따라서 학습 경험을 제공하기 위해 HackerNoon에 작업을 제출하는 것이 좋지만 블로그의 기본 홈을 다른 곳에 두는 것을 고려해보세요.

섹션 1 - 도메인 구입

안타깝게도 자신만의 블로그를 만들려면 가장 두려운 개발자 작업 중 하나인 이름 지정이 필요합니다! 순전히 기술적인 관점에서는 그리 어렵지는 않지만, 미리 조사하고 생각해 볼 가치가 있습니다. 사이트를 설정하는 동안 다시 생각해 보세요.

어떤 도메인 이름을 선택해야 합니까?

여기에는 두 가지 주요 선택이 있습니다.

1. 자신의 이름을 따서 블로그 이름을 지정하세요.

2. 별도의 이름으로 블로그에 고유한 정체성을 부여하세요.

   
   

나는 각각에 대해 다양한 의견을 접했습니다. 내 블로그의 경우에는 단순히 내 이름을 따서 이름을 지정했습니다. 내 생각에는 당신이 자신의 이름을 널리 알리기 위해 블로그를 사용하고 있다면 블로그에 자신의 이름을 사용하는 것은 어떨까요?

무엇을 선택하든 도메인은 변경하기가 다소 어렵다는 점을 기억하세요. 따라서 시간을 들여 자신 있는 도메인을 찾는 것이 좋습니다. 그러나 원하는 도메인이 이미 사용 중이라면 도메인을 다시 생각하거나 조정해야 할 수도 있으므로 마음을 굳히기 전에 도메인이 사용 가능한지 확인하세요.

도메인 이름을 어디서 구입하나요?

BlueHost , Hostinger , GoDaddy 및 Namecheap 과 같은 많은 도메인 등록 기관에 대해 이미 들어보셨을 것입니다.

하지만 확인해야 할 핵심 사항은 Google Domains 입니다. 이는 .dev 도메인을 판매하는 유일한 등록 기관이기 때문입니다. 제가 조언하는 바는 구할 수 있다면 .com 여전히 최고라는 것입니다. 따라서 마음에 드는 것이 있으면 선택하세요. 하지만 그렇지 않다면 .dev 훌륭한 대안이 될 수 있습니다.

도메인 비용

도메인 비용은 다양하며, 도메인을 유지하려면 매년 비용을 지불해야 합니다 . 도메인은 연간 10달러만큼 저렴할 수 있으므로 비즈니스 목적으로 도메인을 구매하는 것이 아니라면 값비싼 도메인을 구매하기 전에 신중하게 생각하세요.

섹션 2 - 정적 사이트 생성기를 사용하여 간단한 사이트 만들기

정적 사이트 생성기란 무엇입니까?

정적 사이트 생성기(SSG)는 웹 서버에 있는 정적 파일로 제공될 수 있도록 웹 사이트 콘텐츠를 템플릿화하고 생성합니다.

홈 페이지, 게시물 색인, '정보' 페이지 등과 같은 사이트의 기본 구조를 설정한 후 마크다운 파일을 추가하기만 하면 전체 페이지를 생성할 수 있습니다.

SSG를 사용하는 이유는 무엇입니까?

한마디로 SSG는

• 빠른 사이트 제공

• GitOps 워크플로를 사용하여 게시할 수 있습니다.

• 안전합니다(해킹할 데이터베이스가 없습니다!)

• 플랫폼이 제공할 수 있는 것에 국한되지 않고 기술 능력을 활용할 수 있습니다.

  
  

개발자로서 우리는 매우 유사한 작업을 수행하는 GitHub를 거의 매일 사용합니다. 코드 저장소에서는 마크다운으로 읽어보기 및 기타 문서를 작성하고 GitHub는 웹페이지에서 볼 수 있도록 형식을 잘 지정합니다.

SSG를 사용하면 자신의 블로그에 대해 거의 동일한 GitOps 워크플로를 따를 수 있습니다. dev.to에 글을 쓰기 시작했을 때 Git 저장소에서 초안을 관리했습니다. 게시하기 전까지는 괜찮았는데, 그 시점에 콘텐츠를 웹 편집기로 전송해야 했습니다.

괜찮았지만 SSG를 통해 GitHub의 추가 정보 업데이트와 동일한 작업 흐름을 사용할 수 있다는 사실을 알게 되었을 때 더 자세히 알아보고 싶었습니다.

블로그를 설정하는 일반적인 방법은 WordPress와 같은 것을 사용하는 것입니다. 이것은 확실히 많은 이점을 가지고 있지만 모든 콘텐츠를 데이터베이스에 저장합니다. 정적으로 생성된 사이트에는 사이트가 필요하지 않으며 이는 훨씬 더 빠르다는 것을 의미합니다.

물론 속도가 전부는 아니지만 Google은 사이트가 로드되는 속도에 관심이 있으므로 SSG 생성 사이트가 제공할 수 있는 속도를 활용해 보는 것은 어떨까요?

Hugo로 기본 사이트 만들기

정적 사이트를 만들려면 Hugo를 추천합니다. 간단히 말해서, 인기 있고, 잘 지원되고, 빠르며, 미리 만들어진 템플릿을 사용하여 빠르게 시작하고 실행할 수 있기 때문입니다.

(대체 SSG에 대한 자세한 내용은 부록의 SSG 비교 섹션을 참조하세요.)

Hugo 공식 문서의 빠른 시작 페이지 에서는 기본 Hugo 사이트 설정에 대한 훌륭한 설명을 제공합니다. 제공되는 단계를 따르되 '사이트 만들기' 명령에 도달하면 대신 다음으로 변경하는 것이 좋습니다.

 hugo new site quickstart cd quickstart git init echo "/public/" >> .gitignore echo "/resources/_gen/" >> .gitignore echo ".hugo_build.lock" >> .gitignore git clone https://github.com/leafee98/hugo-theme-flat themes/flat rm -rf themes/flat/.git/ themes/flat/.github/ echo "theme = flat" >> hugo.toml hugo server

공식 가이드와 다음과 같은 차이점이 있습니다.

• .gitignore 파일 설정

• Ananke 테마 대신 뛰어난 'Flat' 테마를 사용합니다.

• git 하위 모듈이 아닌 자신의 저장소 내 코드로 테마를 설정합니다. 이렇게 하면 나중에 테마를 자신의 취향에 맞게 조정하는 것이 훨씬 쉬워집니다.

GitHub 저장소를 생성할 때 비공개로 설정하세요 . 이는 나중에 살펴보게 될 SEO상의 이유입니다.

가이드를 따르면 호스팅할 사이트가 준비됩니다! 이 시점에서 변경하고 싶은 사이트 측면이 있을 가능성이 높습니다. 그러나 호스팅을 중단할 필요는 없습니다.

나중에 변경하지 않으려면 가장 중요한 것은 URL입니다 . 다른 모든 것은 나중에 변경될 수 있습니다.

섹션 3 - 블로그를 호스팅하세요

Hugo 문서의 호스팅 및 배포 섹션에 설명된 대로 정적 사이트가 있기 때문에 거의 모든 곳에서 호스팅할 수 있으며 거의 확실히 무료입니다.

물론 WordPress 기반 사이트를 위한 무료/저렴한 호스트도 많이 있지만 특정 호스트는 너무 많은 대역폭만 제공합니다. 일반적으로 정적 사이트는 실제로 돈을 넘겨주지 않았더라도 비용에 비해 더 많은 대역폭을 제공합니다.

Hugo의 호스팅 가이드에는 많은 가능성이 나열되어 있지만 개인적으로 CloudFlare Pages를 사용하라는 Bryce Wray의 권장 사항 에 동의할 수 있습니다. 무료 계층은 아마도 가장 빠르며 사용하기 쉽습니다.

'GitHub 저장소 설정'부터 가이드를 따르기만 하면 됩니다. 이 시점에서 귀하의 사이트는 온라인 상태가 됩니다! 하지만 my-blog-xyz.pages.dev 와 같은 보기 흉한 도메인을 가지게 됩니다. 사용자 지정 도메인 설정에 대한 CloudFlare 가이드를 따르기만 하면 이전에 구입한 도메인에 사이트를 게시할 수 있습니다.

섹션 4 - 분석

헛되고 헛되고 헛되도다 모든 것이 헛되도다!

— 전도서 1:2

엄밀히 말하면 이것은 선택적인 단계이지만 이 시점에서는 사이트에 대한 분석을 설정하는 것이 좋습니다. 아마도 제가 헛된 것일 수도 있지만, 제게 있어 블로깅의 가장 큰 즐거움은 사람들이 실제로 당신이 쓴 내용을 보고 관심을 갖고 있다는 것을 알 수 있다는 것입니다.

정적 사이트 설정의 한 가지 제한 사항은 일종의 데이터베이스가 필요하기 때문에 분석을 직접 호스팅할 수 없다는 것입니다. 그러나 이용 가능한 훌륭한 제3자 분석 제공업체가 많이 있기 때문에 어쨌든 그것은 큰 문제가 되지 않습니다.

여러분이 들어보셨을 가장 큰 것은 Google Analytics입니다.

제3자 제공업체를 통해 분석을 설정하려면 일반적으로 다음이 필요합니다.

1. 계정 설정

   
   

2. 페이지에 자바스크립트 스니펫이나 링크를 추가합니다.

제가 추천한 Hugo 템플릿에서는 간단히 head.html 템플릿 파일에 다음과 같은 내용을 추가하면 됩니다.

 {{/* Include analytics, but only in production */}} {{- if hugo.IsProduction | or (eq site.Params.env "production") }} <script defer data-domain="yourdomain.com" src="/link/to/script.js"></script> {{- end }}

사이트에 GA를 설정하려면 Google의 공식 문서를 따르세요.

제가 함께한 분석 제공업체는 Plausible 입니다. 안타깝게도 무료는 아니지만(한 달에 약 9달러) 사용하기 쉽고 가벼우며(스크립트는 1kb 미만) 개인 정보 보호를 존중하므로 IMO를 살펴볼 가치가 있습니다.

섹션 5 - 기본 SEO

당신이 그것을 구축하면, 그들은 올 것이다

— 꿈의 분야

위의 인용문에는 어느 정도 진실이 있습니다. 귀하의 블로그를 Google에 올리기 위해 해야 할 일이 그리 많지 않으며, 다행히도 키워드를 잔뜩 집어넣는 헛소리의 시대는 끝났습니다 . 궁극적으로 중요한 것은 좋은 콘텐츠를 작성하는 것입니다. 이는 우리와 같은 독립 블로거에게 좋은 소식입니다.

즉, 귀하의 사이트가 검색 엔진에 적합한지 확인하기 위해 수행할 수 있는 몇 가지 작업이 있습니다.

Google에 귀하의 존재를 알리기

Google의 웹 크롤러는 결국 귀하의 사이트를 찾게 되지만, Google이 먼저 시작하고 Google 검색 콘솔 에 귀하의 사이트를 설정하는 데 확실히 도움이 됩니다. 다음을 수행하고 싶을 것입니다.

• 가입하기

• 도메인 주소 등록(Google Domains에서 도메인을 구입한 경우 이 절차가 훨씬 간단해집니다.)

• 사이트맵 탭에 사이트의 sitemap.xml URL을 제출하세요. 다행히 Hugo가 https://yourdomain.com/sitemap.xml 에서 귀하를 위해 사이트를 생성해 드릴 것입니다.

이 작업이 완료되면 Google은 (다음 며칠에 걸쳐) 귀하의 웹사이트 크롤링을 시작합니다. 하지만 검색 콘솔에는 며칠 정도 약간의 지연이 있습니다.

귀하의 사이트에 색인된 내용을 확인하는 가장 신뢰할 수 있는 방법은 site: 쿼리(예: site:yourdomain.dom 를 사용하여 Google에 검색하는 것입니다.

Search Console 설정의 또 다른 유용한 이점은 '페이지' 탭에서 Google이 페이지 색인을 생성할 수 없거나 색인을 생성하지 않는 이유에 대해 보고된 문제를 확인할 수 있다는 것입니다.

문제 확인

Hugo와 우리가 사용하는 템플릿은 좋은 SEO 관행을 위한 대부분의 기반을 포괄해야 합니다. 하지만 Google의 PageSpeed Insights 도구 에서 사이트를 확인하는 것도 나쁘지 않습니다. (템플릿 파일을 조정하여 사이트를 원하는 대로 만들기 시작하면 이는 더욱 중요해집니다.)

이를 통해 페이지의 성능, 접근성 및 SEO 문제(예: 메타 태그 누락)에 대한 좋은 개요를 얻을 수 있습니다.

정규화 및 정규화 URL

블로거로서 이해하는 데 중요한 SEO 개념 중 하나는 정규화 및 표준 URL 입니다. 기본적으로 동일한 콘텐츠가 서로 다른 URL을 통해 액세스될 수 있지만 Google이 단일 페이지의 페이지 순위를 여러 URL에 걸쳐 분할하는 것을 원하지 않는다는 아이디어입니다.

따라서 검색 엔진이 페이지의 URL 로 간주해야 하는 URL을 페이지에서 선언하도록 할 수 있습니다.

CloudFlare는 사용자 지정 도메인과 함께 my-blog-xyz.pages.dev 와 같은 "추악한" 도메인도 생성한다는 점을 기억하세요. 대부분의 호스팅 제공업체에서는 이 기본 도메인을 해제하는 것을 허용하지 않지만 페이지에 표준 URL이 설정되어 있는 한 문제가 되지 않습니다. Google은 맞춤 도메인 아래에만 목록을 표시합니다. "못생긴" 것이 아닙니다.

내가 Hugo에 Flat 테마를 추천하는 이유 중 하나는 (Ananke의 권장 기본값과 달리) 표준 링크가 이미 포함되어 있다는 것입니다. 그러나 다른 테마를 사용하려는 경우 다음과 같이 헤더 템플릿에 간단히 추가할 수 있습니다.

 <link rel="canonical" href="{{ .Permalink }}" />

위에 언급된 PageSpeed Insights 도구에서 이를 확인하여 특정 페이지에 대해 이것이 올바르게 설정되었는지 확인할 수 있습니다. 페이지에 'SEO' 섹션 아래 체크리스트 항목으로 표준 URL이 있는지 확인할 수 있습니다.

아래의 재출판 섹션 에서 정규화에 대해 자세히 살펴보겠습니다.

비공개 GitHub 레포

앞서 GitHub 저장소를 비공개로 설정했다는 사실을 기억하실 것입니다. 이는 (작성 당시) 마크다운 문서에 표준 URL이나 NOINDEX 태그를 추가할 수 없기 때문에 이것이 또 다른 미묘한 코드 중복 문제로 작용하기 때문입니다. 비공개 저장소가 이 문제를 해결합니다.

백링크 및 도메인 권한

Google에서 사이트 순위를 결정하는 요소 중 하나는 해당 사이트에 링크된 다른 사이트의 수에 달려 있다는 말을 들어보셨을 것입니다. 이것을 도메인 권한 이라고 하며, 이 맥락에서 한 사이트에서 다른 사이트로의 링크를 백링크 라고 합니다.

Google에서 귀하의 블로그 순위를 높이기 위해 백링크를 "파밍"하는 방법에 대해서는 이야기하지 않겠습니다. 우선, Google은 그러한 계획을 현명하게 처리했으며, 게다가 자신의 사이트를 만드는 것의 이점 중 하나는 웹을 더 이상 그런 멍청한 것들로 채우는 대신 웹을 더 나은 곳으로 만드는 데 도움을 줄 수 있다는 것입니다.

대신에 중요한 점은 단순히 Google에서 좋은 순위를 매기려면 시간이 걸린다는 것입니다. 처음에는 도메인 권한이 많지 않지만 시간이 지나면서 그 권한은 커질 것입니다. 언제나 그렇듯이, 여러분은 가능한 최고의 게시물을 작성하는 데만 집중해야 합니다.

섹션 6 - 작업 공유

광고는 악한 것을 광고할 때만 악합니다.

— 데이비드 오길비

Google이 귀하의 블로그를 찾을 수 있다는 것만으로도 충분하다고 말하고 싶은 만큼, 현실적으로 약간의 자체 홍보를 하고 귀하의 게시물을 온라인으로 공유하는 것이 실제로 도움이 됩니다.

레딧 사용

가장 좋은 방법은 Reddit에 기사 링크를 게시하는 것입니다. 소셜 미디어에 게시하는 것은 나쁘지 않지만 Reddit의 주요 장점은 투표 시스템을 통해 좋은 게시물(귀하의 게시물도 마찬가지일 것입니다)이 즉시 삭제되지 않고 한동안 하위 Reddit의 첫 페이지에 머물 수 있다는 것입니다. 타임라인을 따라.

특정 하위 레딧에 게시

당신이 작성하고 있는 프로그래밍 언어나 기술과 같은 특정 하위 레딧에 게시하세요. 하위 레딧이 클수록 잠재적으로 더 많은 사람들이 귀하의 게시물을 볼 수 있지만 /r/programming 과 같은 대규모 하위 레딧에서는 많은 사람들이 자신의 게시물을 계속 유지하기 위해 좋은 게시물을 단순히 묻어두기 위해 전술적으로 반대 투표를 하게 되는 경우가 많습니다. 맨 위.

대신, 귀하의 게시물에 적용되는 가장 구체적인 Reddit을 고수하면 더 많은 행운을 누릴 수 있습니다. 그러한 커뮤니티는 귀하의 게시물에 더 관심을 갖고 읽을 가능성이 높으며 자체 홍보를 더 잘 받아들입니다.

각 하위 레딧의 규칙을 확인하세요

하위 레딧에 익숙하지 않다면 게시하기 전에 항상 커뮤니티 규칙을 확인하세요 . 각 하위 레딧에는 서로 다른 규칙이 있으며, 특히 자신의 기사에 대한 링크에 대한 허용 범위가 다릅니다.

이는 자기 홍보에 대한 전면 금지, 자기 게시를 너무 많이 하지 않을 것이라는 기대, 전혀 제한이 없는 경우에 따라 달라질 수 있습니다.

주의해야 할 또 다른 주요 규칙은 원하지 않는 게시물 주제가 더 적절한 하위 레딧으로 리디렉션될 가능성이 있다는 것입니다 . 예를 들어, /r/programming 의 규칙은 기술적인 질문을 r/learnprogramming 으로 리디렉션하도록 요구하고, 마찬가지로 채용 목록을 /r/forhire 로 리디렉션하도록 요청합니다.

커뮤니티에 참여하세요

제출하는 하위 레딧의 규칙에 관계없이 Reddit을 자신의 목적을 위한 도구로만 사용하는 것보다 커뮤니티의 일부가 되는 것이 항상 좋은 생각입니다. 즐겨찾는 다른 블로그의 링크를 게시하고 토론에 참여하며 즐거운 시간을 보내세요.

가끔 "Reddiquette"을 읽어보고 책임감 있는 방식으로 참여하고 있는지 확인하세요.

섹션 7 - 블로그 플랫폼에 재게시

자신만의 별도 블로그를 갖는 것만큼 보람 있는 일이지만, dev.to와 같은 개발자 블로그 플랫폼에 게시물을 다시 게시하는 것은 여전히 유용합니다. 자신의 블로그를 설정하는 데 시간을 투자한 후 우리가 왜 다시 돌아왔는지 궁금할 것입니다.

궁극적으로 중요한 것은 다른 개발자가 여러분의 생각을 읽고 평가하는 것입니다. 재발행은 사람들이 여러분의 작업을 접할 수 있는 또 다른 방법을 추가함으로써 이를 수행하는 데 도움이 됩니다.

또 다른 주요 이점은 백링크를 통해 자신의 블로그에 대한 도메인 권한을 구축하는 데 도움이 된다는 것입니다. 하지만 사이트에 해당 백링크가 포함되도록 하려면 올바른 방법으로 다시 게시해야 합니다.

재출판된 기사의 정규화

앞서 논의한 표준 URL의 개념을 기억하시나요? 기사를 다른 곳에 다시 게시할 때 이상적으로는 기사의 정식 버전이 블로그에 있는 기사임을 표시할 수 있는 사이트에만 게시하는 것이 좋습니다.

이렇게 하면 재게시를 통해 노출 이점을 얻을 수 있지만 결과로 발생하는 백링크로 인해 자신의 블로그에 대한 도메인 권한이 구축됩니다.

dev.to용 표준

dev.to의 편집 가이드 에 자세히 설명되어 있듯이 게시물의 "머리말" 속성에 canonical_url 속성을 추가하면 표준 URL을 추가할 수 있습니다.

해시노드의 캐노니컬

"다시 게시하시겠습니까?" 아래의 Hashnode 기사에 표준 URL을 설정할 수 있습니다. 기사에 대한 '기사 설정' 보기 섹션. (자세한 내용은 해당 문서를 참조하세요.)

HackerNoon의 정규화

HackerNoon의 문서 에서 다룬 것처럼 게시물 설정의 "처음 본 위치"에서 표준 URL을 설정할 수 있습니다.

FreeCodeCamp에서는 정규화할 수 없습니다!

이 Hashnode 기사 에서 언급했듯이 FreeCodeCamp에서는 표준 URL 설정을 허용하지 않으므로 작업을 다시 게시하기 전에 두 번 생각하십시오. 실제로 이 dev.to 게시물은 이로 인해 특정 블로거에게 부정적인 영향을 미쳤음을 자세히 설명합니다.

당신을 위한 홍보

재발행의 또 다른 이점은 Reddit 및 기타 소셜 미디어에서 작업을 공유하기 위한 일부 발품 작업이 종종 귀하를 위해 수행된다는 것입니다.

특정 커뮤니티를 위한 기사를 선별하는 봇과 블로거는 블로그 플랫폼의 특정 태그를 통해 귀하의 작업을 찾아 소셜 미디어에 공유하는 경우가 많습니다.

재발행의 단점

그러나 재출판에는 약간의 비용이 듭니다.

• 특히 자신의 사이트에 게시할 때 멋진 GitOps 흐름과 달리 이러한 사이트에 다시 게시하는 것은 약간의 작업이 될 수 있습니다. (여기서는 일부 자동화 및 반자동 솔루션을 사용하여 도움을 받을 수 있습니다.)

• 재출판된 저작물이 검색 엔진에서 원본보다 높은 순위를 차지할 가능성이 있습니다. 이상적으로 표준 URL은 다시 게시된 저작물의 색인이 전혀 생성되지 않음을 의미하지만 이는 보장되지 않습니다(특히 Bing의 경우 내 경험상).

따라서 원본을 출판한 후 얼마 후에 다시 출판하는 것을 고려해 볼 가치가 있습니다(예를 들어 1~2주 정도 소요되지만 시간은 귀하에게 달려 있습니다). 여기에는 다음과 같은 이점이 있습니다.

• 원본 및 재출판 전반에 걸쳐 수정 및 추가 작업의 중복이 줄어듭니다. 필연적으로 귀하의 교정 노력에도 불구하고 귀하 또는 귀하의 독자는 문제나 놓친 내용을 발견하게 될 것입니다. 기사가 귀하의 블로그에만 있을 때 이를 수행하는 것이 더 좋습니다.

• 검색 엔진은 먼저 사이트를 색인화할 시간을 갖습니다.

부록

왜 블로그인가?

글쓰기 및 의사소통 능력 향상

고맙게도 애자일은 소프트웨어 개발이 이전 시대에 그랬던 것처럼 대량의 문서를 생성하는 것과 거의 관련되지 않는다는 것을 의미하지만, 진자가 다른 방향으로 너무 멀리 휘둘렀다고 생각하며, 신규 이민자에게 소개하는 데 도움이 되는 좋은 문서입니다. 시스템이나 저장소는 슬프게도 무시됩니다.

그리고 개발자로서의 경력이 발전함에 따라 생각을 정리하고 복잡한 개념과 시스템을 명확하고 간결하게 설명해야 할 필요성이 점점 더 많아질 것입니다.

블로깅은 이러한 기술을 연습할 수 있는 좋은 방법을 제공합니다. 특히, 관객이 있다는 것은 큰 동기부여 요인이 됩니다!

당신이 말하는 내용을 알고 있음을 증명할 수 있는 방법을 제공합니다.

당신이 알고 있는 기술 목록을 이력서에 기재하는 것도 중요합니다. 당신이 자신의 기술을 안팎으로 알고 있음을 명확하게 보여주는 당신이 작성한 기사에 링크할 수 있음으로써 당신이 그것을 정말로 이해하고 있음을 증명하는 것은 또 다른 일입니다.

자신을 마케팅하고 기회를 창출하는 데 도움이 됩니다.

Jeff Atwood는 자신의 블로그인 Coding Horror 를 통해 Joel Spolsky를 부분적으로 만났고 이후 Stack Overflow라는 작은 것을 만들었습니다.

단순히 블로그를 만든다고 해서 그런 일이 일어날 것이라고 보장할 수는 없지만, 그렇다고 해서 나쁠 것도 없습니다. 특히 틈새 기술 분야에서는 과거에 귀하의 기사를 읽었던 누군가를 통해 귀하의 이름이 누군가에게 떠오를 수도 있습니다.

SSG의 빠른 비교

몇 가지 인기 있는 SSG에 대한 내 생각과 Hugo를 선택하게 된 과정은 다음과 같습니다. 훨씬 더 큰 목록을 보려면 jamstack.org를 참조하세요.

지킬

지킬은 한때 매우 인기가 있었지만 지금은 그렇지 않습니다. GitHub 페이지를 지원하며 매우 블로그 지향적입니다. 나는 처음에 그것을 고려했지만 블로그 페이지에 URL 내에 날짜 구성 요소가 포함되어 있다고 주장하는 엄격한 URL 구조 때문에 연기되었습니다. 이는 내 블로그에서 피하고 싶었던 것입니다.

게시물을 보다 추상적인 "컬렉션" 유형의 일부로 작성하면 이를 방지할 수 있지만, 그렇게 하면 자체 블로그 게시물 추상화 내에서 작업할 때 얻을 수 있는 많은 이점을 잃게 됩니다.

일레븐티

Eleventy는 많은 인기를 얻고 있는 SSG입니다. node.js로 구동되며 매우 유연합니다. 템플릿 엔진과 마크다운 렌더러를 사용자 정의할 수 있으며, 동일한 사이트 내의 여러 페이지에 대해 서로 다른 옵션을 사용할 수도 있습니다.

제가 발견한 가장 큰 단점은 템플릿이 내장되어 있지 않기 때문에 상자에서 바로 블로그를 쉽게 생성할 수 없다는 것입니다. 또한 노드에서 실행되므로 설치가 더 복잡해집니다. 결코 거래를 중단하지는 않지만 Hugo만큼 편리하지는 않습니다.

개츠비

최근에는 개츠비(Gatsby)도 큰 인기를 얻고 있습니다. 그러나 정적 사이트가 아닌 반응 기반 단일 페이지 앱을 생성합니다. 이는 유효한 옵션입니다. 블로그를 만들 때 순수한 HTML 및 CSS의 단순성을 원했습니다.

게다가 이 작가는 사용 경험이 좋지 않아 대신 Hugo를 추천하는 것을 보았습니다.

휴고

마지막으로 제가 블로그에 사용하는 SSG인 Hugo를 살펴보겠습니다. Go로 작성되었으며 이를 사용한다는 것은 단일 바이너리를 설치한다는 것을 의미합니다. 이는 호스팅 관점에서 볼 때 이점이 있습니다. 내 공급자에 Hugo 버전을 지정하면 로컬에서와 동일한 방식으로 작동하는지 확인할 수 있습니다.

그것은 타오르는 속도로 빠르게 진행됩니다. 블로그에 게시물이 몇 개만 포함된 경우에는 별 차이가 없지만 사이트가 성장함에 따라 빌드 시간이 안정적으로 빠르게 유지된다는 점을 아는 것이 좋습니다.

가장 인기 있는 SSG입니다 (GitHub 스타로 판단) . 이는 잘 사용되고 문서화되어 있으며 거의 모든 정적 사이트 호스팅 플랫폼에서 잘 지원된다는 의미입니다.

무엇보다도 시작하는 데 도움이 되는 템플릿이 있습니다. 어느 시점에서는 자신만의 템플릿을 만들고 싶을 수도 있지만(또는 최소한 자신의 취향에 맞게 수정) 최소한 즉시 시작할 수 있는 내용을 제공합니다.

주요 단점은 Go의 템플릿 언어를 사용한다는 것입니다. 어떤 의미로든 끔찍하지는 않지만 일부에 비해 약간 투박하며 다른 템플릿 언어에 관심이 있다면 여기서는 운이 좋지 않을 것입니다. 이것이 당신에게 문제가 된다면 Eleventy를 살펴볼 가치가 있을 것입니다.