評価は不明、改善方法は他の業者を探す。

WordPressのClassic Editorの「テキスト」タブに直接HTMLのコードを書いている。

これに関しては、提示された情報の中では特に問題であるとは考えない。
目的を達成できたなら、手段は問題じゃない。
もし採用した手段に問題があるというなら、もっとはっきりと目的を提示する必要がある。
例えば、「納品したものを受け取った後に自分で修正する必要がある」という条件を事前に提示する。そうすれば表示方法の変更によって壊れてしまうようなものは条件を満たさないので、修正の依頼を出せる。
前提にそういったことがなければ、「ビジュアルタブのボタンを押さないで」という条件を押し付けられたとしても、（なんだそりゃとは思うけど）諦めるしかない。

あるレンタルサーバーから、あるレンタルサーバーへの引っ越しが出来ないという。

新環境への移行の案件として発注したのに、それができないって一体どういうこと？
事前に何を話して、何の同意をとって、発注をかけたの？
発注先が事前にできると言っていたのに、発注後にやっぱりできないと言ったのなら、そりゃ発注先が悪いけどあまりにも普通じゃない。そんなめちゃめちゃわかりやすい嘘をつくとは思えない。

引っ越しは出来ないので、元のリソースに上書きしてくださいと言われた。。

これに関しては、「（ミドルウェア等のアップデートによる動作保証ができないので、） 引っ越しは出来ないので、元のリソースに上書きしてください」ということならまぁ納得できる。
ただ前述の通り、事前にできると言っていたなら、そういったことも含め「できる」なので、契約通りにやってもらう。

もっと詳細な情報がないとどっちに責任があるかわからない。あなたは言ったつもりでも、実際には言っていないかもしれない。あなたは言ったつもりでも発注先があなたの意図通りのことを認識していないかもしれない。
なので、評価は不明。ただ、どちらが悪いかにかかわらず意思の疎通ができてなさそうなので、業者は変えるべき。間違ってもその業者に拘り、どうにかしようとは思わない。

midoribiさん
ご意見ありがとうございました。
確かに、、意思疎通、双方の思い込みの違いはあるかも知れませんね。。

なお、私としてはWordPressを使う＝ユーザーも簡単に編集・更新できるための仕組み
という前提があったので、
確かにWordPressで作るとはそういうものですよね？という事を、Web制作会社さんと話した記憶はありませんでした。

出来上がったものを見て「・・・これじゃあWordPress使わないで、最初からコードベタ打ちで作れば良いのでは？」と思ったものですが、、
そこからふと最近流行りの「ヘッドレスCMS」とかの方が良いのかな？
次回のサイト更改ではそうしてみるかな？なとと思ってみたりしました。

（補足）今回例に出しましたサイトは、決して、弊社のコーポレートサイトの事ではありません！
→今回のサイトの件は、そちらとは違うWeb制作会社さんです。

ちなみに現在のWordPress標準実装のブロックエディタ「Gutenberg」を駆使して構築されるWeb制作会社さんのほうが少ないですか？
※一般的によくあるコーポレートサイトのレイアウトイメージで想定してください。

なお、私としてはWordPressを使う＝ユーザーも簡単に編集・更新できるための仕組み
という前提があったので、

その前提はあっているとは思うけど、世の中には出来上がったものを何年間も修正せずにそのままにしたり、細かな修正でもお金を払ってやってもらう企業はごまんとある。
なので、あなたが受け取ったような納品物でも問題にならない場合がある。

出来上がったものを見て「・・・これじゃあWordPress使わないで、最初からコードベタ打ちで作れば良いのでは？」と思ったものですが、、
そこからふと最近流行りの「ヘッドレスCMS」とかの方が良いのかな？
次回のサイト更改ではそうしてみるかな？なとと思ってみたりしました。

誤解をしているか、ヘッドレスCMSに過度な期待をしている気がする。
WordPressであれば、フロントエンドとしてテンプレートがあり、それをちょこっといじるだけで、目的のUIが出来上がる。
ヘッドレスCMSではフロントエンドが全くないので、一から作らないといけない。もちろんテンプレート的なものはあるけど、それでもWordPressと比べると工数がかかる。

ヘッドレスCMSにしたら、タブを切り替えることによるレイアウト崩れ問題は解決すると思うけど、それは表面的な問題で根本的な問題は違うところにあるんじゃない？
なのでヘッドレスCMSに変えたところで問題が解決しないんじゃないかな？と考える。

midoribi さん

ありがとうございます。

ヘッドレスCMSにしたら、タブを切り替えることによるレイアウト崩れ問題は解決すると思うけど、それは表面的な問題で根本的な問題は違うところにあるんじゃない？
なのでヘッドレスCMSに変えたところで問題が解決しないんじゃないかな？と考える。

なるほど。
確かに、コードベタ打ち＝ヘッドレスCMSでは無いですよね。。
（・・・たぶんこの考えのままでは、事実を直視出来なかった逃げなだけで…再び悲劇が生まれるところでした）

人気だったWordPressとヘッドレスCMSのQiita記事も読んでみました。

普段実務で請負ってるWordPressサイトを、microCMSに変えられるのか考えてみた #WordPress - Qiita
・・・自身の環境を正しく振り返り将来を見つめる深い考察。こうありたいものでした。

AstroでWordPressを爆速Headless化してみる #WordPress - Qiita
・・・確かに、ローカルに置いたCMSからアップロードして静的サイト更新するのはセキュリティ確保として有益ですね！（こっちの目的もあるのかヘッドレスCMS！←いまさらの気付き。。）
そしてフロントエンドの構築はAstroが人気っぽいのですね？

なぜ、WordPressのテキストエディタにコードベタ打ちで納品されるのか？
なんとなくこちらのブログを拝見して、Web制作会社側の事情も分かった気がしました。

（えるぺぐ様ブログ）Wordpressでbrやpタグが消えてしまわない様にする方法
以下、引用させていただきます。

---

• まずは、レイアウトが崩れることの、回避方法。

ズバリ、Advanced Editor Tools（旧TinyMCE Advanced）プラグインを入れる事でこの問題を解消する事ができます。

「上級者向け設定」の欄へ進みます。
項目にある「クラシックブロックとクラシックエディター内のパラグラフタグを保持」へチェックを入れます。

• 次に、テキストエディタとビジュアルエディタを切り替えるとレイアウトが崩れる理由。

これはWordpressの「自動挿入」機能が働いているためです。

・・・なるほど。

• そして、なぜそういう納品が行われるかが、なんとなく分かりました。

Wordpressでは、テキストエディタに直接htmlタグを入れて作るのが普通です。

・・・え、そういうものなのですね？

制作工程上brやpを省くことはしない
Wordpressで制作する場合、まずは元ファイルである「HTMLページ」で形作り、それを固定>ページに流し込むのが基本でしょう。

その際にbrやpタグを、わざわざ一度省いたりしませんよね。

大抵はヘッダーやフッター部分以外のコンテンツ部分を丸ごと流し込むはずです。

手元のHTML通りであって欲しい
ここでもし改行タグや段落タグが消えてしまうと、少なくともHTMLの元ファイルとは違うものになってしまいます。

・・・なるほど、静的ページで作ったデザインがあって、そのデザインのまま、
そのHTMLコードをコピーして、WPのテキストエディタにそのままペーストするのですね。

次に、ユーザー側（サイト管理者）側の感想など。
※X（おそらく当時はTwitter時代）の投稿からいくつか拝借。
※「WordPress ベタ」で検索。