How to Add a Comment Widget to Hatena Blog

Where Pro is required, and where it is not

Most platform guides on this site open with a plan you have to buy before the install works. Hatena inverts that. The install itself sits inside the free tier, and money buys you the two things around it: the address in the browser bar, and a phone-only copy of your custom HTML.

What you are installing

Your address was decided on day one

When a Hatena blog is created you pick a name and one of five domains, hatenablog.com, hatenablog.jp, hateblo.jp, hatenadiary.com or hatenadiary.jp, and the blog answers at that combination from then on. The help page for opening a blog puts the consequence plainly: "ブログのURL（ドメイン名）は、開設後に変更できません". There is no rename later.

A domain of your own is possible, on a paid plan. Hatena lists はてなCMS, はてなブログPro, はてなブログBusiness and はてなブログ for DevBlog as the plans that can use one, the field lives in 「詳細設定」 under 「独自ドメイン」, and the domain string you bring cannot contain the word hatena.

The part that matters for a widget comes next, and it surprises people. Moving to your own domain does not retire the hatena address: the help page says the old one is not redirected automatically and leaves that to you if you want it. So a blog in that state answers on two hostnames, and readers arrive on both, from bookmarks, from search results, from links written years ago.

Which is why the allowlist behind your site id is a list rather than a single value. Add both hostnames in the BootSignal dashboard while both are live. Add them in full, yourname.hatenablog.com rather than hatenablog.com: the check accepts any hostname ending in a registered domain, so the bare version would quietly cover every other blog on that domain too.

The boxes Hatena will take HTML in

There are four of them, and picking the right one is most of this install. Hatena's own blog-parts page points anything pasted from elsewhere at 「カスタマイズ」タブの「ヘッダ」の「ブログタイトル下」か「フッタ」, which tells you where the platform expects this to go.

A fifth route does not exist here, and it is worth naming because it exists nearly everywhere else. There is no template file to edit. Hatena's guide to building a theme describes the work as CSS, "CSSを編集してオリジナルテーマを作ることができます", written into the デザインCSS field. Nothing in it corresponds to a WordPress footer template. The four boxes above are the whole surface for a script.

The article fields are documented as scoped: 「記事上HTML（記事本文上）」および「記事下HTML」に設置したブログパーツ等は … 記事ページにのみ表示します. That is exactly the scope a per-post thread wants. If you are on Pro, or you have checked your own plan screen and the field accepts your paste, put the block there and skip the position workaround in step three.

The install

1. Put the hostname readers actually land on into the dashboard

   Open a published post of your own and copy the host out of the address bar, subdomain and all. That string goes into your site settings, which hands back a site id. If you are mid-move to a domain of your own, add both, since Hatena keeps the old address answering. The id is not a secret, and it does not need to be: it only works from the hostnames sitting next to it in that list.

2. Open the Footer field in the design settings

   From the dashboard go to 「デザイン」, choose the 「カスタマイズ」 tab, and open 「フッタ」. Hatena describes the field as "ブログ全体の下部にHTMLコードを自由に配置できます。" The same tab holds 「ヘッダ」 > 「ブログタイトル下」, described the matching way as "ヘッダのタイトル下にHTMLコードを自由に配置できます。", if you would rather the block ran near the top of the page.

3. Paste the loader, an empty slot and five lines that name the page

   The loader tag carries defer, so it scans once the document is parsed. The inline script runs while the page is still being parsed, which means the mount element is already sitting there when the scan happens, and no rescan call is needed. ENTRY is the one thing to adjust: leave it as it is and every page of the blog gets a thread, including the top page, or open one of your own posts, look at the shape of its path, and narrow the pattern to match only that.

   SnippetCopy

   <script src="https://bootsignal.com/bootsignal.js"
           data-site-id="YOUR_SITE_ID" data-lang="en" defer></script>
   
   <div id="bs-thread"></div>
   <script>
   (function () {
     // Narrow this to your own post path once you have looked at one.
     var ENTRY = /./;
     var slot = document.getElementById('bs-thread');
     if (!slot || !ENTRY.test(location.pathname)) return;
     var el = document.createElement('div');
     el.setAttribute('data-bootsignal', 'comments');
     // One conversation per path, so every post keeps its own.
     el.setAttribute('data-thread-id', location.pathname);
     slot.appendChild(el);
   })();
   </script>

4. Save the design change, then read a published post

   Hatena's help for the カスタマイズ tab describes each field without naming the button that commits it, so use whatever your screen offers; the sidebar path is the one whose button the help does name, 「適用する」. Then open a real post in a normal tab. A thread at the very bottom of the page is the フッタ box doing precisely what it says.

5. Decide what a phone gets before you tell anyone about it

   Roughly nobody reads a blog only on a desktop. On a free plan the answer is 「詳細設定」 and the 「レスポンシブデザイン」 checkbox, which makes the smartphone view use the PC design settings, your paste included. On Pro you also have the smartphone-only fields, 「タイトル下（はてなブログPro）」 and 「カスタムHTML（はてなブログPro）」, if you want a different arrangement there. Either way, open the blog on an actual phone before you consider this finished.

If you would rather it sat beside the posts

The sidebar takes the same paste through a different door: the 「カスタマイズ」 tab, then 「サイドバー」, then 「モジュールを追加」, choose 「HTML」, paste, and 「適用する」. One caveat comes from the shape of the column rather than from Hatena. A sidebar is narrow and a conversation grows downward, so this suits a short guestbook-style thread and reads badly as the main comment section of a post.

The deal Hatena offers on custom code

The platform is unusually direct about this. Its developer-settings page opens with permission: "詳細設定やデザイン設定で「開発者向けの設定です。」の表示がある項目は、ご自身でHTML、CSS、JavaScriptなどを記述できます." Then it sets the terms. Support does not cover what you write. Changes to Hatena's own specifications can stop your code working without notice. And customizations that Hatena's terms of service prohibit are off the table, the page naming hiding the ads or the header and footer as its examples.

That last line is worth reading closely rather than nervously. It is about removing Hatena's chrome and advertising from the page. A comment thread appended below your post removes nothing and hides nothing.

The question Hatena's documentation leaves open

On some builders, pasted HTML is dropped into a cross-origin sandboxed iframe, and a widget that checks which site it is on cannot survive that. Nothing in the Hatena pages consulted for this guide mentions iframes or sandboxing for these fields. They read the other way, describing HTML, CSS and JavaScript that you write into the blog yourself. But no page says in so many words that the fields are not sandboxed either, so the honest position is undocumented rather than settled.

Settle it once, in thirty seconds, on your own blog. Open a published post, inspect the area where the thread should be, and look at what surrounds your div. Plain page markup means the widget is reading your hostname. An <iframe> served from somewhere else means it is reading that host instead, and the Wix page walks through what a builder that does sandbox looks like from the reader's side.

What it adds to a Hatena bill

BootSignal is $20 per month or $200 per year, per registered domain, and every widget in the catalog is included, the ones added after you subscribe too. Nothing in that moves with pageviews, which is the number a Hatena blog is least able to predict: an entry that gets picked up runs hot for a week and then returns to its usual traffic, and metered comment tools charge for exactly that week.

Whichever Hatena plan you are on is a separate bill from Hatena, and this page has no figure for it: the pricing questions worth checking on your own account are what Pro costs and whether you want it at all. Ours is on the pricing page, and priced comparisons against other hosted comment systems live in the alternatives section, where each number carries a source and the date somebody read it.

The next widget is five more lines in the same box

The loader you pasted serves the rest of the catalog, so a second widget costs a few lines inside the function you already have. Reactions pair well with a blog: plenty of readers who will never write a comment will still tell you they liked something.

  var re = document.createElement('div');
  re.setAttribute('data-bootsignal', 'reactions');
  re.setAttribute('data-thread-id', location.pathname);
  slot.appendChild(re);

Keep a copy of the whole block, site id included, in a file next to your blog notes. Design settings are the first thing people rewrite when they change themes, and the paste that took an evening to get right takes two minutes to restore from a file you can find.

When the bottom of the page stays empty

1. Reload the post with the cache bypassed. A design change that never saved looks identical to a script that never ran.
2. Is bootsignal.js in the Network tab? If it is not, the box did not save, or the page you are on is not one the field applies to.
3. Does document.getElementById('bs-thread') return an element in the console? null means the HTML never reached the page at all.
4. Did you narrow ENTRY and then test on a page it does not match? Widen it briefly and reload to find out.
5. Does the hostname in the address bar match a registered one, character for character? yourname.hatenablog.com and yourname.com are two entries in the list, not one.
6. On a phone, is 「レスポンシブデザイン」 on? Without it the smartphone view is a separate design, and the smartphone HTML fields are the Pro ones.
7. Inspect the empty area. If your div is inside an <iframe> from another host, the hostname the widget reads is not yours.