狙いは 「ファイルができた」の次の一手 です。まだキャプチャ手段を決めている段階なら、Web Page to Editable HTML ワークフローを先に。
「エクスポート」の現場での意味
| 形態 | 向く用途 | つまずき |
|---|---|---|
単一 .html | 差し戻し用の最小成果物 | アセットだけ置き忘れ |
HTML + _files | Chrome などの完了保存スタイル | HTML だけ別ディレクトリへ |
ルートを揃えることを最優先に。相対パス前提のとき、HTMLだけ移動させると画像がほぼ一斉に欠落します。
ローカルでレイアウトが死ぬ主因
/css/xxxのような サイトルート相対。ローカルのfile://には存在しません。相対化するか、そのまま開発サーバ経由。- SPA：ハイドレーション前提のコンテンツは 単純な静的保存では空 のまま。手でDOMを復元できる規模だけ手直し、
reactが前提の複雑UIは 再キャプチャ が現実解。 - 仕上げ前に
python -m http.server級で一度localhostで見るだけで、file://特有の問題を切り分けられます。
パッチだけか、撮り直しか
| 状況 | 手元で直す | 取り直し |
|---|---|---|
| リンク数個の typo | ○ | △ |
| ほぼ全セクション JS 依存 | △〜× | ○ |
| コピーライティング微修正 | ○ | 通常不要 |
再取得は copyweb.net/url-to-html でプレビュー確認→書き出しのほうが、パッチだらけより早く終わるケースがあります。
構成リサーチの文脈は ランディングのインスピレーション用クローン、公開リスクは ウェブクローンと法 とセットで読むと安全側に寄せられます。
FAQ（関連検索の言い換え）
「名前をつけて保存」だけでも編集できる？
レイアウトが軽ければイエス。ただし React/Vue 製LPでスクリプトごと無意味なときは、View Source ではなくレンダ済み経路へ。
画像がすべて壊れたように見える
フォルダ階層を崩した、src が data-src のまま、lazy で未取得、のどれか。ネットワーク列をブラウザで追う。
CMS へ載せ換えられる？
チャンク化（ヒーロー・証拠リスト・FAQ などブロック単位）が無難。丸ごと iframe 相当は保守が苦しいです。
細かなコピーを回すときは先に chat。