Blog

ブログ

画像SEOについて改めて考える〜おさえておきたいポイントとは

画像SEOについて考える

画像SEOについて考えたことはありますか?

普段は画像をそのまま記事に使用したりしていることもありますが、一つの工夫でアクセスが見込める可能性がある。
今回はブログを書くにあたり、改めて画像SEOについて見直してみました。

 

画像SEOとは何なのか?

Google画像検索で上位に画像が表示されることを目指す取組について。
Google検索では上位画像は通常の検索結果にも表示されることがあるので、通常のSEOを行う他に画像SEOも意識することで露出が増えアクセス増が期待できます。

検索結果の上位に自分が探している内容の画像があると自分が探していた内容かも!と見てしまうことがありますね。
こういった効果を期待したいです。

画像SEOを行う上でのポイント

では、画像SEOに取り組むにあたって行ったらいいことはなんでしょうか。
無意に画像を多用するだけでは記事やコンテンツの品質に関わってきます。
6つのポイントに絞ってみます。

オリジナルの画像を使用する

現在はフリー素材の画像など、利用できる画像は多々あります。
しかし、同じような画像素材を使用ていると、他の記事との差別化が難しくなり埋もれていくこともあるでしょう。

独自性のあるオリジナル画像を使用することで他の記事とは差別化がされます。
掲載されている画像=特定のコンテンツという関連付けができますね。

ただ、このオリジナル画像については必ずしもSEOにマイナスの影響を与えるわけではありません。
Google 画像検索 SEO ベストプラクティスにて「Google が画像を検出してインデックスに登録できるようにする」と記載もあるため、独自画像を用意した方が好ましいという形です。

Google 画像検索 SEO ベストプラクティス:

https://developers.google.com/search/docs/appearance/google-images?hl=ja#create-a-great-user-experience

ファイル名には簡潔な名前、また内容を簡潔に表している名前を設定する

Googleでの評価は、ファイル名も評価の対象となります。

iPhoneやデジカメ等で撮影した場合に設定される「IMG○○.png」等の名前だと、画像がどのような内容であるか認識ができず評価がされません。
短く、画像内容を表現できる名前にすることで評価されやすくなっていきます。

花見の写真などであれば、「hanami.png」や「tokyo_hanami.png」などであると、花見や東京の花見などの評価がされます。
掲載画像についても一工夫することで変わってくることもあるかと思いますので、積極的に行っていきましょう。

画像を設定する場合はaltタグの内容を設定する

画像とWordPressのファイル情報例
WordPressのファイル情報例

代替えテキストを設定することによって、検索エンジンに画像の情報が伝達されます。

タグ内の単語が検索にヒットすることも考えられるので、積極的に設定するのが良いですね。
各画像全てに代替えテキストの用意は手間ではありますが、検索上でのヒット率向上を考えると行っておきたいところです。

ただし、代替えテキスト内にキーワードを多く記載する場合、スパム判定され悪い評価となるので気をつけましょう。

画像内容に関連する文章を周囲に配置する

画像と文章の配置例
画像と文章の配置例

画像の前後や左右に文章を配置することによって画像内容を前後の文脈から判断することがあります。
関連する文章を配置することによって、検索のヒット率向上となります。
関連性を持たせることは記事自体の検索順位を維持するのにも重要となるので配置にも気をつけていきましょう。

画像データのサイズ、形式を適切なものに設定する

サポートされている画像形式を使用、速度と画質を考慮して最適化これらもGoogleの評価対象となることがあります。
速度が極端に遅いページは評価が下がるようになったという話も…
早い=評価が上がるというわけではないので注意です。

サポートされている画像形式を使用
サポートしている形式:BMP、GIF、JPEG、PNG、WebP、SVG、AVIF

速度と画質を考慮して最適化
低画質で何の画像かわからないと画像を掲載している意味がありません。
高画質になるにつれ表示速度にも影響が出るため適度に画像圧縮を行い最適化しましょう。

構造化データ、画像サイトマップの利用する

構造化データで画像をマークアップすることでバッジというものがつきます。
バッジとは、Google画像検索をした時に画像に「パソコン」「カメラ」「椅子」などカテゴリ分けされたものとなります。

何の画像であるかがわかることで認識がされやすくなり、リッチリザルトにも影響が出てきます。

リッチリザルト例
リッチリザルト例

画像サイトマップを送信することで、サイトマップの情報を使用しなければ検出されない可能性のある画像のURLを指定できます。
画像サイトマップ作成は固定画像なら現実的ではあるかと思ういますが、ブログなどの毎度変わる画像に関しては保守の面で手間となるため、導入については要検討なところですね。

最後に

今回記事を書くにあたり画像を用意しましたが、画像を作成するだけでも大変だなと感じました。

全てを最初から実行するのは難しいものと思います。
できる範囲から少しずつ取り組んでいくのが良いでしょう。

 

Eccube4.3で「同じURLクエリパラメータを複数回使用しない」を実装してみた

SEO観点におけるURLについて調べていると
URLのクエリパラメータに関するベストプラクティスとして以下の内容が載っていました。

同じパラメータを 2 回使用しないようにします。Googlebot はどちらかの値を無視する可能性があります。
 推奨: ?type=candy,sweet
 非推奨: ?type=candy&type=sweet  (引用)

参考:URL のクエリ パラメータに関するベスト プラクティス

Eccubeで複数選択可の項目を検索すると、 「?type[]=candy&type[]=sweet」 のような、
上記で非推奨とされる「同じパラメータを複数回使用しているURL」になります。
検索エンジンにインデックスさせる対象が、単一選択されたページのみ(「?type[]=candy」「 ?type[]=sweet」 は対象だが 「?type[]=candy&type[]=sweet」 はインデックス対象ではない)
の場合は気にする必要はないと思いますが、もし、複数選択したページをインデックスさせたいなら対応が必要かも(?)ということで今回、Eccube4.3で試してみました。

手順1.複数選択可の検索項目をカスタマイズして追加する

前提条件である「複数選択検索」をできる項目が、Eccube4.3の初期状態では無いので、まずはそれを追加します。
今回は「複数選択可なカテゴリ」を追加します。
(カテゴリ検索は既にあるのですが、単一選択しかできないので、複数選択可な状態のなものを追加します)

1-1.FormTypeのカスタマイズ
EccubeのフォームはFormTypeに実装されているので、カスタマイズして、複数選択可用のカテゴリ項目を追加します。

app/Customize/Form/Extension/ 配下に以下のような「SearchProductTypeExtension.php」を追加します。

実装例
<?php

namespace Customize\Form\Extension;

use Eccube\Form\Type\SearchProductType;
use Eccube\Repository\CategoryRepository;
use Symfony\Bridge\Doctrine\Form\Type\EntityType;
use Symfony\Component\Form\AbstractTypeExtension;
use Symfony\Component\Form\FormBuilderInterface;

class SearchProductTypeExtension extends AbstractTypeExtension
{
private CategoryRepository $categoryRepository;

public function __construct(CategoryRepository $categoryRepository)
{
$this->categoryRepository = $categoryRepository;
}

public static function getExtendedTypes(): iterable
{
yield SearchProductType::class;
}

public function buildForm(FormBuilderInterface $builder, array $options)
{
$categories = $this->categoryRepository->getList(null, true);

$builder->add('category_ids', EntityType::class, [
'class' => 'Eccube\Entity\Category',
'choices' => $categories,
'choice_label' => 'NameWithLevel',
'multiple' => true,
'expanded' => true,
'required' => false,
'label' => 'カテゴリ(複数選択)',
'attr' => [
'class' => 'form-control',
],
]);
}
}

参考:FormTypeカスタマイズの公式ドキュメント

これで、既存のSearchProductType に対して、「category_ids」フォーム項目を追加したことになります。
既に存在するカテゴリ検索項目「category_id」との違いは、チェックボックスになるように「’multiple’ => true」「’expanded’ => true」を追加しただけです。

1-2.Repositoryのカスタマイズ

新しく追加したフィールド「’category_ids’」で検索されるようにRepositoryもカスタマイズします。

app/Customize/Repository配下に以下のようなファイルを追加します。

実装例
<?php

namespace Customize\Repository;

use Doctrine\ORM\EntityManagerInterface;
use Doctrine\ORM\QueryBuilder;
use Eccube\Doctrine\Query\QueryCustomizer;
use Eccube\Repository\QueryKey;

class ProductRepositoryCustomizer implements QueryCustomizer
{

    private EntityManagerInterface $entityManager;

    public function __construct(EntityManagerInterface $entityManager)
    {
        $this->entityManager = $entityManager;
    }

    /**
     * 商品検索にカテゴリ(複数)を追加する
     *
     * @param QueryBuilder $builder
     * @param array $params
     * @param $queryKey
     */
    public function customize(QueryBuilder $builder, $params, $queryKey): void
    {
        // category(s)
        if (!empty($params['category_ids'])) {
            $Categories = $params['category_ids'];
            if ($Categories->count() > 0) {
                $subQb = $this->entityManager->createQueryBuilder();
                $subQb->select('1')
                    ->from('Eccube\Entity\ProductCategory', 'pct_sub')
                    ->where('pct_sub.Product = p') // 'p'は親クエリのエイリアス
                    ->andWhere($subQb->expr()->in('pct_sub.Category', ':Categories'));

                $builder->andWhere($builder->expr()->exists($subQb->getDQL()))
                    ->setParameter('Categories', $Categories);
            }
        }
    }

    /**
     * ProductRepository::getQueryBuilderBySearchData に適用する.
     *
     * @return string
     * @see \Eccube\Repository\ProductRepository::getQueryBuilderBySearchData()
     * @see QueryKey
     */
    public function getQueryKey(): string
    {
        return QueryKey::PRODUCT_SEARCH;
    }
}

参考:Repositoryのカスタマイズ

category_ids」が選択されている場合は、選択されたカテゴリIDが、カテゴリとして設定されている商品をExistで絞り込んでいます。

 

1-3.twigのカスタマイズ

app/template/default/Product 配下に src/Eccube/Resource/template/default/Product/list.twig のコードをコピーして配置します。するとapp/template/default/Product/list.twig の方が参照されます。

参考:テンプレートカスタマイズの公式ドキュメント

新しく配置したapp/template/default/Product/list.twigのformタグの中に、category_idsフィールドを追加します。
その時、既存の、「FormTypeのフィールドをfor文でhiddenとして書き出している処理」からcategory_idsフィールドを除外します。

実装例
<form name="form1" id="form1" method="get" action="?">
   {{% for item in search_form  %}
      {# category_idsは除外 #}
      {% if item.vars.name != 'category_ids' %}
            <input type="hidden" id="{{ item.vars.id }}"
                  name="{{ item.vars.full_name }}"
            {% if item.vars.value is not empty %}value="{{ item.vars.value }}" {% endif %}/>
      {% endif %}
   {{% endfor %}
   {{# 新しい複数選択カテゴリフィールドの表示 #}
   {<div class="form-group">
      {{ form_widget(search_form.category_ids) }}
      {{ form_errors(search_form.category_ids) }}
      <button type="submit" class="btn btn-primary mt-2">
            {{ '検索' }}
      </button>
   {</div>
</form>

これで検索結果一覧ページにアクセスすると、複数選択出来るカテゴリのチェックボックスと検索ボタンが追加された画面が表示されます。

これでカテゴリの複数検索すると下記のようなURLになります。(デコードしています)

http://localhost:8080/products/list?mode=&category_id=&name=&pageno=&disp_number=20&orderby=1&category_ids[]=7&category_ids[]=9

※動作確認のため、いくつかカテゴリを追加しています。

これで前提条件である「同じパラメータを複数回使用したURL」の状態になりました。

手順2.複数カテゴリ検索時のURLをカンマ区切りにする

いよいよ本題であるURLのカンマ区切りに着手します。

2-1.検索実行直前にjavascriptで配列 → 文字列 変更する

チェックボックスで選択した値をそのままの状態で検索実行してしまうと、配列のURLが生成されてしまうので、javascript でカンマ区切りの文字列に変更します。

実装例(app/template/default/Product/list.twig に追記しました)
    <script>
        document.addEventListener('DOMContentLoaded', function () {
            const form = document.getElementById('form1');

            form.addEventListener('submit', function (e) {
                const checkboxes = form.querySelectorAll('input[name="category_ids[]"]:checked');
                const selectedValues = Array.from(checkboxes).map(cb => cb.value);

                // 既存の複数inputをdisabledにして送信されないようにする(後で1つのinputにまとめるため)
                checkboxes.forEach(cb => cb.disabled = true);

                // 新しいhidden inputを1つ作成
                const input = document.createElement('input');
                input.type = 'hidden';
                input.name = 'category_ids';
                input.value = selectedValues.join(',');

                form.appendChild(input);
            });
        });
    </script>

上記のjavascript コードで、以下の内容を実行しています。

  • submitの直前に、選択された「category_ids」の値を取得
  • 元々の category_idsチェックボックスフィールド はdisabled
  • 選択された「category_ids」の値をカンマ区切りにしてformに新フィールドとして追加

これだけでURLは、目的である「同じパラメータは1回しか使用されない」状態になります。

http://localhost:8080/products/list?mode=&category_id=&name=&pageno=&disp_number=20&orderby=1&category_ids=7,9
※デコードしています。

しかし、これだけだと検索がうまくいきません。FormTypeでは配列で送られてくることが期待されていますが、文字列で来たためエラーになってしまいます。

今度はFormType側で文字列 → 配列 に変換して帳尻を合わせます。

2-2.FormTypeの処理時に文字列 → 配列 に変換する

手順1で追加した「SearchProductTypeExtension」に以下の内容を追記します。

実装例
<?php

namespace Customize\Form\Extension;

・・・省略・・・use Symfony\Component\Form\FormEvent; use Symfony\Component\Form\FormEvents;
class SearchProductTypeExtension extends AbstractTypeExtension
{
    private CategoryRepository $categoryRepository;

    public function __construct(CategoryRepository $categoryRepository)
    { ・・・省略・・・ }

    public static function getExtendedTypes(): iterable
    { ・・・省略・・・ }
    public function buildForm(FormBuilderInterface $builder, array $options)
    {
        ・・・省略・・・ $builder->addEventListener(FormEvents::PRE_SUBMIT, function (FormEvent $event) { $data = $event->getData(); // カンマ区切りの文字列を配列に変換 if (isset($data['category_ids']) && is_string($data['category_ids'])) { $ids = array_filter(array_map('trim', explode(',', $data['category_ids']))); $data['category_ids'] = $ids; $event->setData($data); } });
    }
}

PRE_SUBMIT イベントを使って、カンマ区切り文字列を配列に変換しています。
PRE_SUBMIT イベントは「フォームにデータを送信する前に、リクエストのデータを変更する」時に使うものなので、今回のような目的にはピッタリですね。
参考:Symfony Form Events

FormTypeに上記を修正を適用すると、URLの目的を達成しつつ、検索機能も損なわない状態になります。

一応これで今回の試したかったことは出来ました。お試しだったので「category_ids」に特化したコードになってしまいましたが、本当に運用するつもりなら、処理は部品化して汎用的に使えるようにすると良いと思います。

まとめ

いかがだったでしょうか。今回はたまたま見つけた「同じパラメータを 2 回使用しない」を試してみました。
私は今まで聞いたことが無かったので、SEO対策としての重要度はそこまで高く無いのかもしれません。また、最初にも書いた通り、複数選択された状態をインデックスさせる必要が無い場合はそもそも必要ありません。

それなりに対応コストはかかるので、もし本格的に導入を検討をする際には、一度SEO対策会社の方へ相談してから判断するのが良いでしょう。

 

【必見】今さら聞けない「EC-CUBE」って?できること&便利機能をわかりやすく解説!

こんにちは!
今回はネットショップ運営を考えている方、または今のECサイトに満足していない方に向けて、
日本生まれのECプラットフォーム「EC-CUBE(イーシーキューブ)」をご紹介します。
無料で始められて、しかも柔軟にカスタマイズできるとあって、実は中小企業から大手企業まで幅広く使われているんです。

 

そもそもEC-CUBEって?

EC-CUBEは、日本発のオープンソースECプラットフォーム。
言い換えれば、「自分で自由に作れるネットショップの土台」です。
無料でダウンロード・利用できて、自社に合ったショップを思い通りに作れるのが最大の魅力!
デザインの変更も、機能追加も、まるでブロックのパーツのように組み立て自由自在なのです。

 

EC-CUBEでできること

✅ 商品の登録やカテゴリ分け
✅ 受注〜発送までの一元管理
✅ 会員登録・購入履歴・ポイント機能
✅ HTML/CSSでの自由なデザイン編集
✅ プラグインで機能拡張(クーポンやSNS連携)
つまり、「これがあればネットショップとして十分」な機能が、はじめからそろっています。

これは便利!知っておきたいおすすめ機能

💡 スマホ表示に自動対応
 スマートフォンでも見やすく、購入しやすいUIになっています。
💡 会員ランクやポイント制度もカンタン導入
 リピーター獲得の施策もばっちり。
💡 越境ECも視野に(多言語・多通貨対応)
 必要に応じて、海外販売の足がかりにもなります。
💡 エンジニアにはうれしい構造
 開発やカスタマイズがしやすい設計、開発コミュニティやドキュメントも充実。
💡 管理画面がわかりやすい!
 日本語で操作に迷わず、誰でもショップ運営をスタートできます。

EC-CUBEはこんな人におすすめ!

* これから本格的にネットショップを始めたい方
* 自由にカスタマイズして差別化したい方
* ShopifyやBASEでは物足りなくなってきた方
* 自社独自の販売スタイルに合わせて構築したい方

自分で作りたい人にも、プロに頼んで構築する人にも使いやすいのがEC-CUBEの魅力。
まずは一度、公式サイトやデモで触ってみてはいかがでしょうか?

EC-CUBEは、アイデア次第でショップの可能性がどんどん広がる柔軟なプラットフォームです。
「やってみたいけど、どこから手を付けたらいいかわからない」「自社向けにカスタマイズしたい」など、
導入や運用でお悩みがあれば、ぜひお気軽にご相談ください。
お問い合わせはこちら

AWSマルチアカウント戦略でシンプル&セキュアな運用へ

はじめに

弊社では長らく、社内サービスを 単一の AWS アカウント に集約して運用してきました。サービス数自体は多くないものの、運用メンバーが増えるにつれて権限の境界が曖昧 となり、「誰がどこまで操作できるのか」を把握しづらい状況に陥っていました。

この課題を解決するため、AWS Organizations を活用した マルチアカウント戦略 を導入し、環境・責務ごとにアカウントを分離する取り組みを開始。本記事では、その背景と具体的なアプローチ、そして得られたメリットを紹介します。

現状の課題

  • 管理アカウントALB5 台の EC2 が混在

 

  • 管理アカウントに IAM ユーザーが集中しており、各メンバーに必要以上の権限が与えられている状況が多く、最小権限の原則を実践しにくい
  • 単一アカウントではコストの内訳が分かりにくい
    • コスト配分タグを使ってある程度の集計は行っていましたが、集計や可視化の観点ではやや見づらく、タグ運用も属人化しやすい課題がありました。

 

マルチアカウント構成とは

AWS Organizations を用いて 環境(開発・本番)や目的(ネットワーク・共有サービス)ごとにアカウントを分割 し、ガバナンスを効かせつつスケーラブルに拡張していく方法です。アカウントはそれぞれがセキュリティ境界となり、権限・課金・ログなどを独立して管理できます。

期待するメリット

1. 環境ごとの権限分離

アカウント単位で IAM ロールを限定できるため、操作ミスなどにより特定のサービスが停止するリスクを軽減できます。サービスごとにアカウントを分けることで、影響範囲を明確に分離し、安定した運用が可能になります。

2. コストの可視化と予算管理

コスト配分タグでもある程度の可視化は可能でしたが、マルチアカウント構成によりアカウントごとの使用量が分けて見られるようになり、より直感的かつ明確にサービスごとのコストを把握できるようになります。請求自体は管理アカウントに集約されるものの、各アカウントの使用状況が明確になることで、予算アラートの設定や異常検知にも役立ちます。

対応: ネットワークアカウントとサービスアカウントを分離

ルーティングを担うALB をネットワークアカウントに配置し、そこから別アカウントに移行した EC2 インスタンスへトラフィックを転送する構成とします。
本記事では、実際にHPインスタンスを別アカウントに移行したのでその手順を記載します。

大まかな移行ステップ

  1. 新規AWSアカウント作成、作成したAWSアカウントでVPC作成(この記事では割愛)
  2. ネットワーク接続
    • 管理アカウントの VPC ↔ 移行先 VPC を VPC ピアリングで接続。
    • RAMを使用してセキュリティグループを共有し、ALB からのトラフィックを許可。
  3. AMIを使用し、EC2を移行
    • AMI化し、構成を変更せずそのまま移行する想定
    • 共有機能で別アカウントで使用できるようにする
    • ※ 本構成のEC2は、MySQL をインスタンス内に直接構築しているため、AMI により構成をそのまま保持した移行が可能でした。
  4. ルーティング調整
    1. 新EC2へ接続するターゲットグループを作成。
      1. 別アカウントのEC2は参照できないため、IPアドレスでターゲットグループを設置する
    2. ALBのターゲットグループを差し替える。

 

ネットワーク接続

VPC ピアリングの手順

1. 移行元アカウントでVPC > ピアリング接続からピアリング接続を作成をクリック

2. VPC ID(リクエスト元)は接続元VPCのID、VPC ID(アクセプタ)は接続先VPCのIDをそれぞれ入力
今回のケースでは、アクセプタ側が別アカウントのため、アカウントID(アクセプタ)には接続先のアカウントIDを、VPC ID(アクセプタ)には移行先VPCのIDを入力

3. 移行先アカウントでVPC > ピアリング接続を表示するとリソースができているので、「リクエストを承諾」をクリック

4. それぞれのVPCでルーティングできるよう、ルートテーブルに設定を追加

 

RAMを使用し、移行先のアカウントにセキュリティグループを参照できるようにする

1. ALBが存在するアカウントでResource Access Manager > 自分が共有で、リソース共有を作成をクリック

2. ALBのセキュリティグループを共有する

AMIを使用し、EC2を移行

1. EC2のコンソール > インスタンスの状態 > イメージとテンプレート >イメージを作成から、AMIを作成する

2.イメージ名を入力し、「イメージを作成」を選択する

※本番稼働しているインスタンスの場合、「インスタンスを再起動」には要注意。チェックを入れていると、インスタンスが再起動されてしまいます。

3. EC2 > AMIから、作成したAMIを移行先のアカウントへ共有

4. 移行先のアカウントでEC2 > AMIから、「AMIからインスタンスを起動」をクリックで起動

5. EC2のセキュリティグループ > インバウンドルールは、RAMで共有したALBのセキュリティグループを紐づける
※この時、カスタムルール内のプルダウン内にはALBのセキュリティグループは存在しないと思うので、セキュリティグループIDで直接入力する

ルーティング調整

1. EC2 > ターゲットグループから、ターゲットグループの作成をクリック

2. 他アカウントのEC2は直接参照できないので、グループの詳細の指定は「IPアドレス」を選択

3. 「その他のプライベートアドレス」を選択し、移行先のEC2インスタンスのプライベートIPアドレスを入力し、ターゲットグループを作成

4. ALBのターゲットグループを差し替えて、画面が表示されれば完了

 

終わりに

単一アカウント運用からマルチアカウント構成への移行は、セキュリティや運用の観点から重要な一歩でした。特に、IAMの権限分離やコストの明確化といった課題は、アカウントを分割することでシンプルかつ直感的に解決できることが実感できました。

今回のように、ALBをネットワークアカウントに残したまま、EC2をサービスアカウントへ移行することで、既存構成を大きく変更せずにスムーズな切り出しが可能です。

今後も、サービス単位や環境単位でのアカウント分離をさらに進めることで、よりガバナンスが効いた、安全かつスケーラブルなクラウド環境を構築していきたいと考えています。

本記事が、同様の課題を抱える方々の参考になれば幸いです。今後も運用で得られた知見を積極的に共有していきますので、ご期待ください。