Бяспека праз .htaccess: шыфраванне, абарона паролем і каманды для ўзмацнення аховы сайта

Калі гаворка заходзіць пра бяспеку сайта на Apache ці LiteSpeed, файл .htaccess — гэта не проста набор радкоў, а сапраўдны камандны пункт для абароны. Шыфраванне праз .htaccess — гэта комплекс практычных метадаў: ад закрыцця асобных дырэкторый лагінам і паролем да забароны чытання самога канфігурацыйнага файла звонку, прымусовага перанакіравання на HTTPS і абмежавання шкоднасных запытаў. Самы папулярны сцэнар — гэта абарона каталога праз Basic Auth, дзе паролі захоўваюцца ў файле .htpasswd. Але тут ёсць важкі нюанс: сам па сабе Basic Auth не шыфруе звесткі, ён толькі запытвае доступ. Каб лагін і пароль не перадаваліся адкрытым тэкстам, гэтая схема абавязкова павінна працаваць праз SSL-сертыфікат па пратаколе HTTPS. SSL сертыфікат надзейны вэб-хостынг

Бяспеку сайта часта ўяўляюць як нешта складанае: масіўныя файрволы, дарагія плагіны ці заблытанае праграмнае забеспячэнне. Аднак правільна настроены .htaccess — гэта першая лінія абароны, асабліва на віртуальным хостынгу, для WordPress, самапісных PHP-праектаў і сайтаў малога бізнэсу. З дапамогай гэтага файла можна надзейна зачыніць ад чужых вачэй адмін-панэль, скіраваць увесь HTTP-трафік на бяспечны пратакол, забараніць паказ змесціва каталогаў, перакрыць доступ да канфідэнцыйных файлаў, спыніць крадзеж трафіку (hotlink) і актываваць базавыя загалоўкі бяспекі для браўзера.

У гэтым кіраўніцтве мы пакрокава разбяром, як арганізаваць абарону паролем праз .htaccess, растлумачым самыя запатрабаваныя ў жыцці каманды бяспекі і падзелімся гатовымі прыкладамі, якія вы зможаце скапіяваць і адаптаваць пад сябе. Прыведзеныя інструкцыі разлічаны на асяроддзі, дзе падтрымліваюцца модулі Apache mod_rewrite, mod_auth_basic і mod_headers. Паколькі серверы LiteSpeed у асноўным сумяшчальныя з сінтаксісам Apache, большасць правілаў спрацуе і там. Але залатое правіла адміністратара — перад унясеннем змен на баявы сервер абавязкова зрабіце рэзервовую копію і, па магчымасці, абкатайце новыя правілы на тэставым паддамене. кіраванне даменам рэзервовае капіраванне сайта

Што такое .htaccess і чаму гэта аснова бяспекі?

.htaccess — гэта лакальны канфігурацыйны файл, які тлумачыць вэб-серверу, як паводзіць сябе ў пэўнай дырэкторыі і ўсіх яе падпапках. Калі яго змясціць у корань сайта, ён звычайна ўплывае на ўвесь праект; напрыклад, файл у тэчцы public_html кіруе правіламі для галоўнага вэб-кораню вашага дамена. Калі ж змясціць яго ў даччыную папку, правілы будуць дзейнічаць толькі ў яе межах.

Паколькі гэты файл дазваляе кантраляваць доступ на ўзроўні сервера, шкодныя запыты можна блакіраваць яшчэ да таго, як яны дойдуць да кода прыкладання. Напрыклад, калі абараніць тэчку "admin", зламыснік натыкнецца на акно аўтарызацыі сервера яшчэ да спробы ўзламаць WordPress, вашу ўласную панэль кіравання або PHP-скрыпт. Такі падыход рэзка зніжае колькасць brute-force-атак і ўскладняе эксплуатацыю ўразлівасцяў на ўзроўні прыкладання.

Вось галоўныя перавагі .htaccess з пункту гледжання бяспекі:

• Правілы доступу можна дадаваць без умяшання ў зыходны код сайта.
• Асобныя дырэкторыі закрываюцца лагінам і паролем.
• HTTP-запыты аўтаматычна перанакіроўваюцца на бяспечны пратакол.
• Можна забараніць прагляд змесціва каталогаў, доступ да сістэмных файлаў і крадзеж кантэнту.
• Праз загалоўкі бяспекі можна зрабіць паводзіны браўзера больш абароненымі.
• Доступ можна абмяжоўваць па IP-адрасе, пашырэнні файла або HTTP-метадзе.

Аднак не варта спадзявацца толькі на .htaccess. Максімальны эфект дасягаецца толькі ў спалучэнні са свежымі версіямі ПЗ, надзейнай парольнай палітыкай, рэгулярнымі бэкапамі, якаснай хостынг-інфраструктурай, вэб-файрволам (WAF), антывірусным сканаваннем і SSL-сертыфікатам. бяспека хостынгу бяспека WordPress

Логіка абароны: Basic Auth і файл .htpasswd

Калі мы гаворым пра "шыфраванне праз .htaccess", звычайна маюцца на ўвазе дзве рэчы. Першае — гэта прымусовы запыт лагіна і пароля пры ўваходзе ў пэўную дырэкторыю; другое — забарона на чытанне самога файла .htaccess звонку. Першая задача вырашаецца праз механізм Basic Auth, другая — праз правілы абмежавання доступу да канфігурацыйных файлаў.

У схеме Basic Auth файл .htaccess змяшчае інструкцыі для праверкі, а .htpasswd — гэта сховішча з імёнамі карыстальнікаў і хэшамі пароляў. Захоўваць паролі ў адкрытым выглядзе нельга. Сучасныя сістэмы выкарыстоўваюць хэшаванне bcrypt, Apache MD5 ці SHA. Самы надзейны шлях — выкарыстоўваць убудаваную прыладу вашай панэлі кіравання хостынгам ("Абарона дырэкторый" ці "Пароль для папкі"), таму што яна аўтаматычна размесціць .htpasswd у бяспечным месцы і правільна згенеруе хэш.

Тыпавы код для абароны паролем выглядае так:

AuthType Basic

AuthName Ахоўная зона

AuthUserFile /home/karystalnik/.htpasswd

Require valid-user

Логіка гэтых чатырох радкоў простая: указваецца тып аўтэнтыфікацыі (Basic), назва вобласці (якую ўбачыць карыстальнік у дыялогавым акне), поўны серверны шлях да файла з паролямі і дазвол на ўваход толькі для правераных карыстальнікаў. Самая распаўсюджаная памылка тут — паказваць у AuthUserFile URL-адрас замест лакальнага шляху. Правільнае значэнне — гэта фізічны шлях на дыску сервера (/home/...), а не спасылка накшталт https://site.by/.htpasswd.

Дзе лепш захоўваць .htpasswd?

Па магчымасці заўсёды выносьце файл .htpasswd за межы тэчкі public_html. Калі сайт ляжыць у /home/akount/public_html, ідэальнае месца для пароляў — /home/akount/.htpasswd. Гэта гарантуе, што нават пры збоі ў наладах сервера файл нельга будзе спампаваць праз браўзер.

Што да правоў, то аптымальны варыянт — 640 ці 644 для .htpasswd і 644 для .htaccess. Правы 777 (поўны доступ для ўсіх) — гэта грубая дзірка ў бяспецы, такіх эксперыментаў варта пазбягаць.

Пакрокавая інструкцыя: як закрыць дырэкторыю паролем

Гэты раздзел для тых, хто хоча надзейна абараніць адміністратыўныя панэлі, тэставыя стэнды, справаздачы або кліенцкія файлы. Перад пачаткам — абавязкова зрабіце копію бягучага .htaccess. Адна прапушчаная коска ці лішні сімвал могуць пакласці сайт і выклікаць памылку 500 Internal Server Error.

1. Вызначэнне мэтавай папкі

Спачатку дакладна вырашыце, якую дырэкторыю трэба абараніць. Калі трэба зачыніць толькі site.by/admin, стварыце (або адрэдагуйце) .htaccess менавіта ўнутры папкі "admin". Калі ж плануеце часова схаваць увесь сайт ад старонніх вачэй, правілы дадаюцца ў корань.

2. Стварэнне карыстальніка ў .htpasswd

Калі ў панэлі кіравання ёсць інструмент для парольнай абароны дырэкторый — выкарыстоўвайце яго. Калі няма, але ёсць SSH-доступ, можна скарыстацца кансольнай утылітай. Логіка такая: htpasswd -c /home/karystalnik/.htpasswd admin. Гэта стварае новага карыстальніка "admin" і запытвае для яго пароль. Увага: флаг -c выкарыстоўваецца толькі пры першым стварэнні файла, інакш вы сатрэце ўсіх астатніх карыстальнікаў.

3. Даданне правіла ў .htaccess

Змесціце наступныя радкі ў .htaccess абранай папкі:

AuthType Basic

AuthName Панэль кіравання

AuthUserFile /home/karystalnik/.htpasswd

Require valid-user

Пасля захавання файла паспрабуйце зайсці ў гэтую дырэкторыю праз браўзер. Калі з'явілася акно ўводу лагіна і пароля — спрацоўванне паспяховае. Калі ж лагін і пароль правільныя, але акно пастаянна з'яўляецца зноў, праверце шлях у AuthUserFile і ці можа сервер прачытаць файл .htpasswd па правах.

4. Ніколі не выкарыстоўвайце без HTTPS

Basic Auth кадуе лагін і пароль у Base64, што не з'яўляецца шыфраваннем. Калі трафік ідзе па звычайным HTTP, зламыснік у лакальнай сетцы можа лёгка іх перахапіць. Таму любая абарона праз .htaccess павінна суправаджацца прымусовым пераходам на бяспечнае злучэнне. Актывуйце SSL на Hostragons і дадайце правіла перанакіравання на HTTPS, каб звесці рызыку да мінімуму. усталяванне SSL перанакіраванне на HTTPS

Прымусовы HTTPS і склейванне www

Перавод усяго трафіку на бяспечны пратакол — гэта базавы ўзровень гігіены для любога сучаснага сайта. Пасля таго як SSL-сертыфікат запрацуе, у каранёвы .htaccess дадаюць наступную канструкцыю:

RewriteEngine On

RewriteCond %{HTTPS} off

RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Гэтае правіла лавіць усе запыты па HTTP і мякка, з кодам 301 (пастаяннае перамяшчэнне), пераносіць іх на той жа адрас, але з HTTPS. Гэта правільна і з пункту гледжання SEO. Аднак калі вы выкарыстоўваеце знешні праксі-сервер, CDN ці балансіроўшчык нагрузкі, сервер можа думаць, што працуе па HTTP. У такіх выпадках лепш за ўсё запытаць рэкамендаваную канструкцыю ў службы падтрымкі вашага хостынгу.

Таксама важна абраць асноўнае люстэрка: з www ці без. Каб сабраць увесь трафік на версію без www, выкарыстоўваецца такі падыход:

RewriteEngine On

RewriteCond %{HTTP_HOST} ^www\.pryklad-domen\.by$ [NC]

RewriteRule ^(.*)$ https://pryklad-domen.by/$1 [L,R=301]

Не забудзьцеся падставіць свой дамен замест pryklad-domen.by. Калі вы адначасова наладжваеце і HTTPS, і www, імкніцеся пазбегнуць ланцужкоў перанакіраванняў. Ідэальна, калі карыстальнік трапляе на канчатковы правільны URL за адзін скачок. перанакіраванне дамена SEO-сумяшчальнае перанакіраванне

Базавыя каманды .htaccess для ўзмацнення бяспекі

У табліцы ніжэй сабраны самыя хадавыя прыёмы, якія робяць сайт больш устойлівым да нападаў. Перш чым уносіць гэтыя правілы, ацаніце свой бягучы канфіг: часам яны могуць канфліктаваць са стандартнымі правіламі WordPress, Laravel ці іншых сістэм.

Як схаваць змесціва каталогаў

Калі ў тэчцы няма файла index.html ці index.php, сервер можа проста паказаць спіс усіх файлаў. Гэта можа раскрыць бэкапы, тэставыя справаздачы ці зыходнікі. Адключыць гэта можна адным радком:

Options -Indexes

Пасля гэтага наведвальнік замест змесціва папкі атрымае памылку 403 Forbidden, што з пункту гледжання бяспекі правільна.

Закрываем .htaccess і канфідэнцыйныя файлы

Ваш .htaccess не павінен быць бачны праз інтэрнэт. Звычайна Apache блакіруе яго па змаўчанні, але лішняя перастрахоўка не перашкодзіць:

<Files .htaccess>

Require all denied

</Files>

Аналагічна варта зачыніць доступ да файлаў кшталту .env, composer.json, config.php.bak, backup.sql ці database.sql. Асабліва крытычны .env: у ім часта ляжаць паролі ад базы даных, API-ключы і сакрэтныя ключы шыфравання. Іх уцечка можа прывесці да поўнага захопу сістэмы.

Каб адным махам зачыніць некалькі тыпаў файлаў, падыдзе маска:

<FilesMatch ^(\.env|composer\.(json|lock)|package\.json|.*\.sql|.*\.bak)$>

Require all denied

</FilesMatch>

Галоўнае — не перашчыраваць і не забараніць тое, што сапраўды патрэбна сайту для працы (напрыклад, валідацыйныя токены ці інтэграцыйныя скрыпты).

Блакіроўка выканання PHP у часовых папках

Тэчкі для загрузкі файлаў — любімая мішэнь хакераў. Калі на сайце ёсць уразлівасць у механізме запампоўкі, зламыснік можа заліць шкодны PHP-скрыпт. Каб ён не запусціўся, дастаткова забараніць выкананне PHP у медыя-каталогах.

Стварыце .htaccess у папцы uploads з наступным зместам:

<FilesMatch \.php$>

Require all denied

</FilesMatch>

Гэта не дасць серверу апрацоўваць PHP-файлы ў гэтай дырэкторыі. Для WordPress гэта стандартная практыка для wp-content/uploads, але майце на ўвазе: некаторыя плагіны могуць выкарыстоўваць нестандартныя рашэнні, таму тэставанне абавязковае.

Барацьба з хотлінкам: беражом трафік

Хотлінк — гэта калі іншыя сайты ўстаўляюць вашы малюнкі на свае старонкі прамой спасылкай, расходуючы вашы рэсурсы. Прасцейшая абарона будуецца так:

RewriteEngine On

RewriteCond %{HTTP_REFERER} !^$

RewriteCond %{HTTP_REFERER} !^https?://(www\.)?pryklad-domen\.by [NC]

RewriteRule \.(jpg|jpeg|png|gif|webp)$ - [F,NC]

Тут усё проста: калі запыт на малюнак прыйшоў не з вашага сайта, аддаем памылку. Аднак калі вы выкарыстоўваеце CDN або хочаце, каб вашы відарысы адлюстроўваліся ў пошукавіках ці сацсетках, іх дамены трэба будзе дадаць у белы спіс. выкарыстанне CDN прадукцыйнасць вэб-сайта

Абмежаванне доступу па IP-адрасах

Калі вы хочаце, каб у адмінку можна было зайсці толькі з офіса, абмежаванне па IP — добры дадатак да парольнай абароны. На Apache 2.4 і вышэй гэта робіцца так:

Require ip 203.0.113.10

Гэты радок пакідае доступ толькі для аднаго пазначанага IP. Калі ў вас дынамічны адрас, будзьце асцярожныя: пры змене IP вы рызыкуеце самі сябе замкнуць на вуліцы. Таму часцей за ўсё IP-фільтр камбінуюць з парольнай абаронай.

Для дакладнай блакіроўкі аднаго шкоднага адрасу выкарыстоўваецца канструкцыя:

<RequireAll>

Require all granted

Require not ip 198.51.100.25

</RequireAll>

Гэта эфектыўна супраць кропкавых атак, але не выратуе ад размеркаваных ботнетаў. Для сур'ёзнай абароны патрэбны вэб-файрвол і сістэмы абмежавання частаты запытаў.

Загалоўкі бяспекі: абарона на ўзроўні браўзера

.htaccess можа не толькі забараняць, але і даваць каманды браўзеру, як сябе паводзіць. Калі модуль mod_headers уключаны, наступныя загалоўкі значна павышаюць базавую бяспеку:

Header always set X-Content-Type-Options nosniff

Header always set X-Frame-Options SAMEORIGIN

Header always set Referrer-Policy strict-origin-when-cross-origin

Header always set Permissions-Policy geolocation=(), microphone=(), camera=()

X-Content-Type-Options nosniff забараняе браўзеру "здагадвацца" пра тып файла, што зніжае рызыку выканання шкоднага кода. X-Frame-Options SAMEORIGIN забараняе ўбудоўваць ваш сайт у iframe на іншых рэсурсах, абараняючы ад клікджэкінгу. Referrer-Policy кантралюе, якія даныя перадаюцца пры пераходзе па спасылках. Permissions-Policy адключае доступ да камеры, мікрафона і геалакацыі.

Ёсць яшчэ Content-Security-Policy (CSP) — вельмі магутны, але складаны ў наладцы загаловак. Занадта жорсткі CSP можа зламаць паказ рэкламы, сістэмы аналітыкі, анлайн-кансультантаў ці шрыфтоў. Таму яго лепш спачатку абкатаць у рэжыме справаздач, а потым паступова ўкараняць на баявым сайце.

Чэк-ліст перад унясеннем змен

Змены ў .htaccess прымяняюцца імгненна, таму лепш перад гэтым прайсціся па кантрольных пунктах, каб не пакласці праект.

• Спампуйце на кампутар рэзервовую копію бягучага .htaccess.
• Пераканайцеся, што SSL-сертыфікат актыўны і працуе без памылак.
• Дадавайце правілы паступова, па адным, а не ўсе скопам.
• Пасля кожнай змены правярайце сайт на памылкі 500, 403 і 404.
• Не чапайце сістэмныя правілы WordPress ці Laravel без крайняй неабходнасці.
• Праверце звязку "абарона паролем + прымусовы HTTPS".
• Калі выкарыстоўваеце кэшаванне ці CDN, ацаніце рызыку канфліктаў.
• Пратэстуйце ключавыя сцэнары: уваход, формы, аплату на розных прыладах.

Драбіць працу на этапы — гэта стратэгічна правільна. Спачатку ўключыце Options -Indexes і праверце, ці ўсё добра. Потым перавядзіце трафік на HTTPS. І толькі потым дадавайце абарону паролем. Так вы імгненна зразумееце, які менавіта радок выклікаў праблему, калі нешта пойдзе не так.

Тыповыя памылкі і як іх выправіць

500 Internal Server Error

Самая распаўсюджаная прычына — сінтаксічная памылка ці выкарыстанне дырэктывы, якую не падтрымлівае ваш сервер (напрыклад, Header без mod_headers). Рашэнне: прыбярыце апошні дададзены блок, праверце логі памылак сервера і пераканайцеся, што патрэбныя модулі Apache ўключаны.

Акно ўводу пароля з'яўляецца бясконца

Калі лагін і пароль дакладна правільныя, але дыялог аўтарызацыі з'яўляецца зноў і зноў, хутчэй за ўсё, няправільна пазначаны шлях да .htpasswd, ці сервер не можа яго прачытаць з-за правоў доступу. Пераканайцеся, што ў AuthUserFile пазначаны поўны фізічны шлях ад кораня сервера.

Зацыкліванне перанакіравання на HTTPS

Гэта здараецца, калі сервер стаіць за проксі ці CDN. Сэрвер атрымлівае знешні запыт па HTTPS, але ўнутры сеткі думае, што ён HTTP, і спрабуе перанакіраваць яго зноў. Тут дапаможа правіла, якое арыентуецца на загаловак X-Forwarded-Proto, або пераключэнне рэжыму SSL у наладах CDN на Full ці Full Strict.

Зніклі малюнкі ці стылі

Калі пасля правак з'ехала вёрстка, верагодна, правілы блакіроўкі хотлінку ці FilesMatch занадта агрэсіўныя і чапляюць уласныя статычныя файлы сайта. Адкрыйце інструменты распрацоўшчыка ў браўзеры на ўкладцы "Сетка" і паглядзіце, якія запыты вяртаюць памылку 403.

Бяспека .htaccess на сайтах WordPress

У WordPress файл .htaccess гуляе ключавую ролю ў фарміраванні чалавека-зразумелых спасылак (ЧПУ). Таму нельга рэдагаваць блок паміж пазнакамі # BEGIN WordPress і # END WordPress без вострай патрэбы. Усе дадатковыя правілы бяспекі лепш дадаваць вышэй ці ніжэй за гэты блок.

Вось што можна зрабіць для ўзмацнення абароны WP:

• Дадаць дадатковы пласт Basic Auth на тэчку wp-admin.
• Забараніць выкананне PHP у wp-content/uploads.
• Калі не выкарыстоўваеце xmlrpc.php, абмежаваць да яго доступ.
• Схаваць ад чужых вачэй файлы readme.html і ліцэнзіі.
• Зрабіць перанакіраванне на HTTPS з улікам хатняга і сайтавага адрасоў WP.

Двайная абарона wp-admin (пароль адмінкі WP + пароль сервера) — гэта магутны бар'ер. Але ёсць нюанс: некаторыя плагіны выкарыстоўваюць файл admin-ajax.php. Калі наглуха зачыніць усю дырэкторыю, сайт можа страціць частку функцыяналу. Таму абавязковае тэставанне пасля наладкі — гэта не парада, а неабходнасць. хостынг для WordPress паскарэнне WordPress

Прафесійныя парады па працы з .htaccess

Дасведчаныя сістэмныя адміністратары заўсёды шукаюць баланс паміж бяспекай і зручнасцю суправаджэння. Занадта агрэсіўныя правілы могуць зрабіць сайт недаступным і стварыць галаўны боль у будучыні. Таму кожнае ваша дзеянне павінна быць задакументавана.

• Перад крытычнымі зменамі стварайце копіі з датай: htaccess-2026-01-15.bak.
• Не ператварайце .htaccess у "сметніцу" з сотняў незвязаных правілаў.
• Памятайце: 301-рэдырэкт — гэта назаўжды. Браўзеры і пошукавікі кэшуюць яго вельмі агрэсіўна.
• Пасля дадання загалоўкаў бяспекі адкрыйце кансоль браўзера і праверце, ці няма там новых блакіровак.
• У абароненых паролем зонах стварайце персанальныя ўліковыя запісы, а не раздавайце адзін агульны пароль на ўсіх.
• Тэставыя, стэйджынгавыя і архіўныя папкі лепш за ўсё зачыніць на ўзроўні сервера, не чакаючы, пакуль іх праіндэксуюць пошукавікі.

Яшчэ адзін важны момант — рэгулярная рэвізія. Інтэграцыя з нейкім сэрвісам, якая была патрэбна ўчора, сёння можа быць ужо непатрэбнай, а адкрыты для яе "калідор" у .htaccess застанецца. Вазьміце за правіла раз у квартал праглядаць спіс правілаў, выдаляць састарэлыя перанакіраванні і лішнія дазволы.

Выснова: маленькі файл — вялікая абарона

Каманды для "шыфравання" і ўзмацнення бяспекі сайта праз .htaccess — гэта магутны інструмент у руках уважлівага ўладальніка. Пры правільным выкарыстанні гэты маленькі файл умацоўвае пярэдні край абароны ад нападаў. Абараніць дырэкторыі паролем, прымусова ўключыць бяспечнае злучэнне, схаваць файлавую структуру, адрэзаць доступ да канфідэнцыйных дакументаў і наладзіць загалоўкі бяспекі — гэта простыя, вымерныя і вельмі дзейсныя крокі для большасці сайтаў.

Але не забывайце: .htaccess — гэта толькі частка пазла. Па-сапраўднаму надзейная абарона будуецца ў комплексе: якасная хостынг-пляцоўка, абноўленае ПЗ, SSL-сертыфікат, свежыя бэкапы і строгая парольная палітыка. Карыстаючыся Hostragons для размяшчэння вашага сайта, вы можаце кіраваць ключавымі кампанентамі абароны — SSL, хостынгам і даменамі — з адзінай панэлі, паступова выбудоўваючы эшаланаваную сістэму бяспекі. тарыфы вэб-хостынгу набыць дамен SSL-сертыфікаты

Часта задаваныя пытанні

Ці сапраўды .htaccess шыфруе файлы?

Не. Калі кажуць пра "шыфраванне праз .htaccess", звычайна маюць на ўвазе абмежаванне доступу па лагіне і паролі. Basic Auth абараняе ад пранікнення, але для бяспечнай перадачы даных патрабуецца SSL і пратакол HTTPS.

Ці можна захоўваць .htpasswd унутры public_html?

Гэта не рэкамендуецца. Самы бяспечны варыянт — трымаць .htpasswd за межамі вэб-кораню, у дырэкторыі, недаступнай для прамога запыту з браўзера. Гэта зніжае рызыку выпадковай уцечкі даных пры збоі канфігурацыі.

Што рабіць, калі пасля змены .htaccess з'явілася памылка 500?

Адразу прыбярыце апошні дададзены фрагмент кода ці вярніце рэзервовую копію файла. Затым праверце логі памылак сервера. Часцей за ўсё віной таму — друкарская памылка, непадтрыманая дырэктыва або адсутнасць патрэбнага модуля Apache.

Ці варта зачыняць тэчку wp-admin праз .htaccess?

Так, гэта дае дадатковы ўзровень абароны. Але пасля гэтага абавязкова праверце працу плагінаў, якія выкарыстоўваюць admin-ajax.php, а таксама карэктнасць уваходу, каментавання, працы кошыка і форм аплаты.

Ці шкодзіць SEO перанакіраванне на HTTPS?

Правільна выкананае перанакіраванне з кодам 301 не шкодзіць, а наадварот, фармуе бяспечную і аднастайную структуру URL. Галоўнае — не ствараць ланцужкі перанакіраванняў і сачыць, каб усе ўнутраныя спасылкі вялі адразу на канчатковыя HTTPS-адрасы.