estic

Автор и про изменение адреса на JS спрашивал. Читай внимательнее (концовка первого сообщения). Задача решается комплексно. А вы на вторую половину решения "наплевали".

Из ничего ругань на три страницы развели 😦

Ссылка на History API - это верно. Хорошая практика заключается в том, чтобы при любом "существенном" изменении содержимого на JS менять адрес динамически. Но это должно подкрепляться и выводом соответствующего содержимого при независимом запросе по этому адресу.

webinfo, вообще странно по нынешним меркам наблюдать, как информацию по History API называют "бессмысленной галиматьей". Сразу возникает ощущение, что кто-то "отстал от жизни" 😉

Естественно, если говорить о внутренних ссылках.

У каждого типа свое основное назначение.

1) для base или когда явно нужно указать относительные (и нет base). Актуальность в использовании относительных сейчас мала, но они по-прежнему часто используются, как наследие прошлого (и часто создают проблемы).

2) основной тип для шаблонов и т.п.

3) редко используется; в основном когда нет переадресации на адреса со схемой https.

4) основной тип для содержимого, но в общем типы 2 и 4 взаимозаменяемые.

От чрезмерного потребления пищи вы не станете великаном, а быстро "загнетесь".

Оптимальную методику "для ленивых" я описал в предыдущем сообщении.

Как выше написали, включать "выполение" html-файлов на PHP небезопасно. Используйте специальный скрипт для обработки запросов с .html в адресе. Или в крайнем случае сделайте так, чтобы запросы с .html в адресе обрабатывались в соответствующих php-файлах (при их наличии). А чтобы не было дублей /page.html и /page.php, разместите php-файлы в каком-то "скрытом" каталоге.

В последний раз: не нужно так делать.

Тоже иногда занимаюсь "восстановлением дропов" в облегченном варианте. Вместо восстановления страниц можно использовать информативную страницу ошибки 404, например с точной копией главной, и индивидуальную переадресацию с отдельных "интересных" адресов. А от того, что вы хотите сделать, будет только вред.

На соответствующие страницы, т.е. на страницы с примерно таким же содержимым, какое было раньше. Эти другие страницы могут размещаться на другом (или других) домене. Донор может быть даже одностраничником с индивидуальной переадресацией по отдельным внутренним адресам или без такой переадресации. Простейший пример - estic.ru сейчас. Одинаковое содержимое по всем (или почти всем) адресам, но главная все же отличается от внутренних 😉

Не нужно. Для пользователей можете выводить на странице ошибки 404 любое полезное содержимое. Возможно, разное содержимое по разным адресам или даже по одному и тому же адресу.

Не нужно так делать. Можно попробовать использовать переадресацию на JS или при помощи нестандартного заголовка Refresh, но даже это выявляется и не приветствуется поисковыми системами.

Во-первых, работа в реальном времени. Во-вторых, есть такие вещи, которые не воспроизводятся в копии даже при полном копировании (простейший пример - нагрузка на сервер).

Я тоже обычно работаю по SSH и т.п. Но ведь к PMA на сервере можно подключиться таким же способом. По возможности "посредников" лучше размещать ближе к "телу", независимо от того, реализуют ли они прикладной интерфейс или пользовательский.