pavlyk

1. Если это не результат вашей творческой деятельности и речь идет о регулярных платежах - то нужно ИП или ООО или т.п.
2. Можете, но зачем? Если вы все оформите полноценно, то платежная система будет просто перечислять вам на банковский счет.
3. Не важно.
4. Да. Нормальные платежные системы требуют этого. И дают пример такого текста. Как минимум там должно быть внятно написано, что человек покупает, как он может вернуть и пр. и пр.
5. А еще нужна онлайн-касса.
0. Но как правило при небольших объемах на всю юриспруденцию забивают.

А еще есть такая штука как referer, и если вы перейдете из вашей секретной админки куда-то по ссылке - адрес админки стане известен тому сайту на который вы перешли.

А если этот запрос отправлен по http, а не https, то ваш секретный адрес узнает еще и ваш провайдер, а также все промежуточные узлы, через которые идет запрос. И любой кто подключился к прослушке вашего трафика.

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

А еще баннерные сети, всякие гугл-аналитики и яндекс-метрики, если они у вас подключены.

И разнообразные CDN-ы, при подключении картинок, шрифтов, или библиотек, расположеных на внешних серверах.

Данная предосторожность чуть менее чем бесполезна.
Объясню почему:
1) Страницы, которые мы посещаем могут сливаться поисковикам нашими же браузерами.
2) Для того чтобы поисковики не индексировали желаемую страницу достаточно запретить в robots.txt доступ к директории, где она находится либо использовать noindex в самой странице.
<meta name="robots" content="noindex"/>
3) Подбор паролей работает если известен логин, а если логин не тривиальный, то и подбирать нечего.
4) Для защиты сайта большее внимание стоит уделять к тому, чтобы авторизационные данные шли через https, пароли хранились в хешированном с солью состоянии и отсутствовали возможности sql и xss иньекций.

https://cultofmartians.com

проще н-р хуки будут такого вида
https://samle.com/bots/ид_бота/секрет_бота
реврайт на
bots.php?botid=$1&secter=$2

Можно подключить RSS-фид

Никак.
Напишите в саппорт, скажите чтобы перестали блокировать запросы с Telegram API. Если не перестанут - меняйте хостера.

Скорее всего, в нике содержится Right-to-Left-маркер unicode. Попробуйте после ников добавлять Left-to-Right-маркер

У телеги проблемы с самоподписанными сертами, уже давно известно.
Используйте бесплатный let’s encrypt, startSSL и тому подобные ресурсы.

А простой браузер у вас как отображает сайт вКонтакте?
Дело в том, что и простой сайт использует АПИ

Авторизация(любая) работает при ее использовании, легче всего организовать ее использование при единой точке входа и нормальной архитектуре(например мвц). Весь смысл - получить связь пользователя с правами и зафиксировать ее на время работы с сайтом. Далее в "закрытых" частях сайта эта связь должна быть подтверждена(прчитана сессия с ключем авторизации или токен из куки, не важно вообще). Обычно пришется простенький метод/функция типа isAuth() и получают ответ тру/фалс, далее по логике, выбрасывать на главную, давать страницу ощибки, кидать на авторизацию, короче от задачи зависит.

Вам сюда для начала.

Лучше всего навигацию по сайту реализовывать через паттерн проектирования, например, самые классические MVC/HMVC или компонентные. Тогда у вас будет всего одна точка входа в систему и не придётся в каждом скрипте писать проверки, инклуды и тд.

Далее, касательно самой авторизации - тут тоже масса вариантов реализации, но самый минимальный и более-менее правильный вариант - организовать проверку на сессиях или куках, проверять методом наличие сессии или куки, если есть - пользователь авторизован, делать перенаправление со страницы авторизации на нужную, либо же динамически отдавать контент, в зависимости от того как у вас там спроектирована система. Если нет - отдать контент страницы авторизации или перенаправить на нее. SEO здесь так же влияет, если необходима индексация страницы авторизации, то только перенаправлять.

Чтоб сессии работали, ничего инклудить не обязательно, главное чтоб вначале скрипта всегда выполнялся session_start(). В итоге проверка отработает на всех ваших скриптах страниц, которые должны делать редирект в случае если пользователь не авторизован.

php.net/manual/ru/session.examples.basic.php

Добавлю:
Закрыть можно через использование доп.расширения.
Например: file.inc.php и все, где есть .inc - можно закрыть в .htaccess

Однако, чаще закрывают через проверку константы, которая задаётся только в головном файле скрипта.

Также, можно настроить через .htaccess все обращения на один php-файл.
тогда и закрывать ничего не нужно будет.