こんにちは、やまさきです！
ここ最近は、当日の国内最高気温を山陰で記録したぐらい暑くなっていましたね😅
前回の記事では、Ruby Silver試験対策学習アプリをLaravelで開発し、共有レンタルサーバーへ公開するためにPHPへ移植した過程と、AIを活用した品質改善について紹介しました。
今回は、その後の追加開発として、ログイン機能のダッシュボードへの統合と、SEOを意識したサイト構成の改善を行いました。
特に今回の改善では、
- 未ログインユーザーにもサイトの内容を見てもらえるようにする
- ログイン操作をより使いやすくする
- 検索エンジンにサイトの内容を正しく伝える
- Googleなどのクローラーがアクセスしたときにも、サイトの価値が伝わる構成にする
ことを目的としました。
これまでの課題
これまでのサイトでは、「ログインページ」と「ダッシュボード」が別々のページになっていました。
未ログイン状態でダッシュボードへアクセスすると、ログインページへリダイレクトされる仕組みです。
これはログインが必要な学習サービスとしては一般的な構成ですが、SEOという観点では問題がありました。
Googleなどの検索エンジンのクローラーは、通常ログインした状態ではサイトを閲覧しません。
そのため、Googlebotがダッシュボードへアクセスしても、実際に見ることができるのはログインフォームだけです。
つまり、
「このサイトにはRuby Silver試験対策の学習コンテンツがあります」
という情報を、検索エンジンに十分伝えられていない状態でした。
そこで今回は、ダッシュボードを未ログインユーザーにも公開できる「サイトの入口」に変更することにしました。
ログイン機能をダッシュボードに統合
今回の改善で最も大きく変更したのが、ログイン機能です。
参考にしたのは、オンラインプログラミング学習サービスの「Progate」のUIです。
ログインボタンをクリックすると、ページを移動するのではなく、背景を暗くしてログインフォームをモーダルウィンドウとして表示する方式を採用しました。
未ログイン時
未ログイン状態では、ヘッダーに、
- ログイン
- 新規登録
のボタンを表示します。
ボタンをクリックすると、その場でログイン・新規登録フォームが表示されます。
これにより、ユーザーはサイトを離れることなくログイン操作を行えます。
ログイン後
ログインに成功すると、従来のダッシュボードが表示されます。
学習ステータスやコマンド一覧、ログアウトなど、ログインユーザー向けの機能はこれまで通り利用できます。
また、フォーム送信先をダッシュボード自身にすることで、バリデーションエラーが発生した場合にも、同じページでエラー内容を表示し、モーダルを開いた状態を維持するようにしました。
未ログインユーザー向けの「サイト紹介ページ」に
ダッシュボードをサイトの入口として利用するため、未ログイン状態の画面そのものを大きく変更しました。
単に「ログインしてください」と表示するのではなく、Ruby Silver試験対策サイトがどのようなサービスなのかを説明するコンテンツを追加しています。
具体的には、
- サイトの概要
- 収録問題数
- 対応分野数
- 学習機能の紹介
- サンプル問題
- よくある質問
- 公式サイトや公式模擬試験へのリンク
などを掲載しました。
現在、収録している問題は480問、65分野です。
検索エンジンに対しても、これらの情報をHTMLとして提供できるようになりました。
実際の問題を使った「サンプル問題」も追加
今回、特に工夫したのがサンプル問題です。
データベースから問題を1問ランダムに取得し、未ログインユーザーでも実際に問題を解けるようにしました。
問題に回答すると、その場で正誤判定を行い、解説まで確認できます。
「どんなサイトなのか」を文章だけで説明するよりも、実際に1問解いてもらった方がサービスの特徴を理解してもらいやすいと考えました。
また、ユーザーにとっての使いやすさだけでなく、ページ内に学習サービスに関する具体的なコンテンツが増えることで、SEOの面でも意味のある改善となります。
SEO対策も同時に実施
今回はログイン機能の変更だけではなく、HTMLやサイト構造についても見直しました。
titleタグの重複を解消
複数のページで同じtitleが設定されていたため、それぞれのページの内容に合わせて見直しました。
canonicalタグを追加
検索エンジンに対して、ページの正規URLを明示するため、canonicalタグを追加しました。
構造化データを追加
JSON-LDによる構造化データも追加しました。
今回は、
- Course
- FAQPage
のスキーマを利用しています。
サイトの内容やFAQを、検索エンジンが理解しやすい形で提供することを目的としています。
og:urlの不具合を修正
SNSなどでページを共有した際に利用されるOGP情報についても確認しました。
その中で、og:urlに本来のURLではなくホスト名だけが出力される不具合を発見。
こちらも修正しました。
サイトマップにも問題を発見
今回、SEO対策を進める中で、サイトマップについても見直しました。
サイトではPHPによって動的に生成するsitemap.xml.phpを用意していました。
しかし、確認を進めていくと、思わぬ問題が見つかりました。
robots.txtでは、
/sitemap.xml
を指定していました。
ところが、サーバーの.htaccessの設定によって、古い静的なsitemap.xmlが優先して配信されていたのです。
つまり、
「最新のサイトマップを作っていたのに、Googlebotには古いサイトマップが配信されていた」
という状態でした。
これは実際にHTTPレスポンスを確認したことで判明しました。
原因となっていた古い静的ファイルを削除し、最新のサイトマップが正しく配信される状態に修正しました。
Webサイトでは「コードを書いたから終わり」ではなく、実際にサーバーから何が返ってきているのかを確認することが重要だと改めて感じた部分です。
301リダイレクトへ変更
トップページについても構成を整理しました。
これまではindex.phpからdashboard.phpへリダイレクトする構成でした。
このリダイレクトを、それまでの302（一時的なリダイレクト）から301（恒久的なリダイレクト）へ変更しました。
また、サイトマップに登録するトップページについても、リダイレクトだけを行うindex.phpではなく、実際にコンテンツを提供しているdashboard.phpを指定するようにしました。
検索エンジンに対して、
「このサイトの中心となるページはこちらです」
という情報を、より明確に伝えるためです。
見出しタグも見直し
画面上のデザインだけでなく、HTMLの構造も確認しました。
これまで見出しとして使用していた一部の<div>要素を、適切な<h2>タグへ変更しました。
人間が見たときには見た目がほとんど変わらない部分ですが、HTMLとしては大きな違いがあります。
見出しを適切に設定することで、
- ページの構造が分かりやすくなる
- スクリーンリーダーなどでも内容を把握しやすくなる
- 検索エンジンにもコンテンツ構造を伝えやすくなる
といったメリットがあります。
AIを活用しながら、最後は実際に検証
今回も開発ではAIを活用しました。
ただし、AIにコードを書かせて終わり、という進め方にはしていません。
実装した内容について、実際のブラウザやサーバー環境で検証を行いました。
具体的には、
- Playwrightによるブラウザ操作
- スクリーンショットによる画面確認
- テストユーザーを使ったログイン検証
php -lによるPHP構文チェックcurlによるHTTPレスポンスの確認- JSON-LDの出力確認
- サイトマップの配信確認
などを実施しました。
特に今回は、サイトマップのように「コード自体は正しく見えるが、実際には別のファイルが配信されている」という問題も発見できました。
AIによるコード生成やレビューだけではなく、実際に動かして、HTTPレスポンスまで確認することが重要です。
フレームワークを使わないPHPだからこその工夫
このWebアプリは、Laravelなどのフレームワークを使わず、シンプルなPHPで構築しています。
これは、今回利用している共有レンタルサーバーへ比較的容易にデプロイできることを重視したためです。
一方で、フレームワークを使わない分、
- 共通レイアウト
- 認証処理
- バリデーション
- SEO関連タグ
- 構造化データ
- サイトマップ
などを自分たちで設計・実装する必要があります。
また、このサイトにはドット絵風フォント「DotGothic16」や、RPGゲームのウィンドウをイメージしたUIなど、既存のデザインがあります。
今回の大幅な構造変更でも、これまでのデザインイメージを崩さないように実装しました。
今回の改善で変わったこと
今回の変更によって、サイトの入口が大きく変わりました。
これまでは、
未ログイン → ログインページ → ログイン → ダッシュボード
という流れでした。
これを、
未ログイン → ダッシュボード（サイト紹介・サンプル問題） → 必要に応じてログイン
という構成に変更しました。
これによって、ユーザーはログインする前にサイトの内容を確認できます。
同時に、Googlebotなどの検索エンジンのクローラーも、ログインフォームだけではなく、サイトの概要や学習機能、サンプル問題などのコンテンツを取得できるようになりました。
今回の変更内容
今回の実装では、主に7ファイルを変更しました。
中心となったdashboard.phpには、約600行のコードを追加しています。
実装後は本番環境へFTPでデプロイし、動作確認まで実施しました。
今後はGoogle Search Consoleへサイトマップを再登録し、検索エンジン側でどのように認識されるようになったのかを確認していく予定です。
まとめ
今回の改善では、単に「ログイン画面を使いやすくする」というUI改善から始まりました。
しかし、実際に設計を見直していくと、
UI → HTML構造 → SEO → サイトマップ → HTTPレスポンス → サーバー設定
と、Webサイトを構成するさまざまな要素が関係していることが分かります。
特に今回、古いサイトマップがサーバー設定によって優先配信されていた問題は、実際のレスポンスを確認しなければ気づきにくいものでした。
AIを活用することで、実装やコードレビューのスピードは大きく向上しています。
一方で、AIが生成したコードをそのまま採用するのではなく、実際にブラウザで操作し、サーバーから返ってくるデータを確認し、問題があれば原因を一つずつ切り分ける。
この開発プロセスは、今回のWebアプリ開発を通して改めて重要だと感じています。
今後も機能追加だけではなく、ユーザーにとって使いやすく、検索エンジンにも正しく理解されるWebアプリを目指して改善を続けていきます。
