Gadeninアプリを入れる

設計判断読了 6

Gadeninのグローバル対応 (2) — WEBの英語対応はSEO設計から始まる

次は Gadenin for WEB だ。WEB の多言語化は、本文を翻訳する前に「英語ページをどの URL で公開するのか」から考えないといけない。URL 設計と hreflang、どのページから英語化するかを書いておく。

シリーズ「Gadeninを世界へ」 第 1 回: APP の英語対応は「翻訳」ではなかった 第 2 回: WEB の英語対応 — SEO 設計から始まる (この記事)

前回、Gadenin APP 1.3.0 の英語対応について書いた。

テーブル設計、「都道府県」を「国 + 行政区画」に作り直した話、品種マスタの問題、法律まわり、そして App Store の落とし穴。翻訳そのものはいちばん軽い部分だった、という話だ。

APP の次に取り組んでいるのが Gadenin for WEB だ。

そして、ここでまったく別の難しさにぶつかった。


WEB の難しさは SEO だった

Gadenin for WEB には、作物の育て方だけでなく、

作物
栽培方法
病害虫
症状
作業時期

などの情報がある。これらも英語化すれば、海外のユーザーに Gadenin を知ってもらえる入口になる。

ただし WEB の場合、APP とは別の難しさがある。それが SEO だ。

APP なら、端末の言語設定に応じて表示を切り替えればいい。ユーザーはすでにアプリを持っている。

WEB は違う。まだ Gadenin を知らない人が、検索から辿り着くことが前提だ。だから、本文を翻訳する前に考えなければならないことがある。

「英語ページをどの URL で公開するのか?」

だ。

多言語サイトの URL をどうするか

例えば現在、

https://gadenin.com/crops/tomato

というトマトのページがある。この英語版を作る方法はいくつか考えられる。

方法 1:URL のパスで言語を分ける

日本語
/crops/tomato

英語
/en/crops/tomato

非常に分かりやすい方法だ。URL を見ただけで言語が分かり、それぞれが独立した URL になる。

Gadenin ではこの方式を採用することにした。 既存の日本語ページはそのまま維持し、新しく英語ページだけを /en/ 以下に作る。

方法 2:クエリストリングで切り替える

例えば、

/crops/tomato?lang=ja
/crops/tomato?lang=en

という方法も考えられる。アプリケーションとして言語を切り替えるだけなら実装しやすい場合がある。

ただ Gadenin では、英語版を検索エンジンから独立したランディングページとして扱いたい。そのため /en/crops/tomato という明確な URL を持たせる方針にした。

方法 3:サブドメインや別ドメインにする

例えば、

ja.gadenin.com
en.gadenin.com

あるいは国ごとに別ドメインを使う方法もある。大規模なグローバルサービスなら選択肢になるが、今の Gadenin には少し大げさだ。

まずは同じドメインの /en/ 以下に英語コンテンツを集約する。

URL を分けただけでは終わらない

ここからが SEO として重要なところだ。

/crops/tomato
/en/crops/tomato

という 2 つのページができた。人間には「上が日本語、下が英語だな」と分かる。でも検索エンジンにも、この関係を明示的に伝える必要がある。

そこで使うのが hreflang だ。

<link
  rel="alternate"
  hreflang="ja"
  href="https://gadenin.com/crops/tomato"
/>

<link
  rel="alternate"
  hreflang="en"
  href="https://gadenin.com/en/crops/tomato"
/>

「この 2 つは同じテーマを扱った、日本語版と英語版のページです」という関係を検索エンジンへ伝える。

canonical も言語ごとに持たせる

もう 1 つ気をつけたのが canonical だ。

英語版だからといって、

/en/crops/tomato
↓ canonical
/crops/tomato

としてしまうわけではない。それをやると「英語版は日本語版の複製です」と宣言することになり、英語版が検索結果に出なくなる。

英語版は英語版として検索結果に出したい。なので、

/crops/tomato
→ canonical: /crops/tomato

/en/crops/tomato
→ canonical: /en/crops/tomato

と、それぞれ自分自身を canonical として指定する。そして hreflang で「日本語版 ↔ 英語版」という関係を表現する。

canonical は「どれが正本か」、hreflang は「どれが対訳か」。役割が違う。

sitemap も英語対応する

URL を作っただけでは足りない。そのページを検索エンジンに発見してもらう必要がある。

そのため sitemap にも、

https://gadenin.com/crops/tomato
https://gadenin.com/en/crops/tomato

のように英語ページを追加する。

ただし、ここで 1 つルールを決めた。

まだ英訳できていないページを、とりあえず英語 URL として大量生成することはしない。

例えば /en/crops/tomato を開いたら、タイトルとメニューだけ英語で本文は日本語。これでは英語ユーザーにとって価値がない。

英語コンテンツとして成立したページだけを公開し、sitemap にも掲載する方針だ。

実装との相性

Gadenin for WEB は Hono + React を Cloudflare Workers 上で動かしている。ルーティングを自分で書いている構成なので、/en/ の prefix を足すのは素直だ。

大事なのは、既存の日本語 URL を変更しなくていいことだった。

すでに Google にインデックスされている URL を、

/crops/tomato
↓
/ja/crops/tomato

へわざわざ移動させる必要がない。日本語を prefix なしのまま据え置いて、英語だけ /en/ の下に増やす。既存の順位を捨てずに済む。

多言語化の設計でよく見る「両方の言語に prefix を付ける」形も理屈としては綺麗なのだが、すでに日本語で積み上げた評価がある以上、そこを動かす理由がなかった。

2026年のこの時代だからこそ本質的なSEOを理解する

AI時代だからこそ本質を知ることが重要であると気付かされます。

強いSEO “SEOおたく"が1000のサイトを検証してわかった成果を上げるルール

数多くのサイトを検証してきた著者が、検索流入を伸ばすための考え方や実践ルールをまとめたSEO本です。 「記事を増やしているのに検索順位が上がらない」「SEO対策をしているつもりだけど、何が正解なのかわからない」という人にもおすすめ。 小手先のテクニックだけではなく、サイトを長期的に強くしていくためのSEOの考え方を学びたい人に向いています。

¥2,420 (2026年9月15日 時点の参考価格)

すべてのページを英語化するわけではない

ここでも APP で直面した「品種問題」が出てくる。

Gadenin には日本国内の品種情報が多数登録されている。しかし、それをそのまま英語に翻訳して、

/en/crops/tomato/varieties/...

というページを大量に作っても、海外ユーザーが探している品種データにはならない。

そのため、今回の Gadenin for WEB 英語版では品種ページを作らないことにした。将来的に海外の品種マスタを整備した段階で対応する。

APP で「非日本語では品種名を出さない」と決めたのと、同じ判断だ。媒体は違っても、データが日本固有である以上、結論は同じところに落ちる。

では、どのページから英語化するのか

ここは Gadenin らしい戦略にした。

単純にアクセス数が多そうなページから翻訳するのではない。

「Gadenin APP を自然に使いたくなるユーザーが検索するページ」 を優先する。

例えば、

tomato leaves turning yellow

「トマトの葉が黄色くなった」という検索だ。

この人は、すでにトマトを育てている。

ページで原因と対処方法を調べる。今日の状態を写真に撮る。肥料を与えた。数日後に葉の状態を確認する。また写真を撮る。

こうなってくると、「この栽培記録を残しておきたい」 という需要が自然に生まれる。そこで Gadenin APP につながる。

同じように、

tomato plant wilting
how often to water tomatoes
when to fertilize tomatoes
white spots on cucumber leaves

といった検索も、すでに植物を育てている可能性が高いユーザーだ。

一方で「家庭菜園 始め方」のような検索は、アクセスは集まるかもしれないが、まだ何も育てていない人が多い。記録するものがない。

そこで英語版では、

作物 × 症状 → 栽培ガイド → 作物ページ → 病害虫

という順番を中心に英語コンテンツを増やしていく予定だ。

WEB は「翻訳」ではなく検索体験から作る

今回あらためて感じたのは、APP と WEB では国際化の意味が少し違うということだ。

APP では、同じ機能を別の言語でも自然に使えることが重要だった。

一方 WEB では、その言語で検索している人が、どんな言葉で何を探しているのかまで考える必要がある。

例えば日本語タイトルをそのまま英訳するのではなく、

Tomato Leaves Turning Yellow:
Causes & How to Fix It

のように、英語圏で実際に検索される表現を基準にタイトルやページ構成を考える。

日本語の「トマトの葉が黄色くなる原因と対処法」を直訳しても、英語圏の人が打ち込む言葉とは微妙にずれる。ここは翻訳ではなく、その言語での検索行動から逆算するしかない。

さらに、

検索
↓
Gadenin for WEB
↓
栽培の問題を解決
↓
記録したくなる
↓
Gadenin APP

という流れまで設計したいと思っている。


ここから試していく

APP の英語対応が、自分のシステムがどれだけ日本を前提にしていたかを剥がす作業だったとすれば、WEB の英語対応は その言語圏の人の検索行動を一から組み立てる作業になりそうだ。

同じ「英語対応」でも、やることがまるで違う。

Gadenin APP 1.3.0 の英語対応は、その最初の一歩だった。次は Gadenin for WEB。

日本で作り始めた小さな家庭菜園サービスが海外でどこまで使ってもらえるのか。ここから試していく。

この記事は広告を含みます。

関連記事

Gadenin 栽培記録アプリ・無料アプリを入れる