Videre til indhold 
WordPress HTTPS beskytter login-data, kontaktformularer og cookies og hjælper mig med at øge ranking og konvertering. I denne guide viser jeg dig det komplette skift fra HTTP til HTTPS i WordPress - med certifikat, URL-konvertering, 301-omdirigeringer, rettelse af blandet indhold og rene SEO-trin.
Centrale punkter
- SSL Aktiver korrekt og dæk domænet
- URL'er konvertere til WordPress
- 301 Gennemtving videresendelse
- Blandet indhold Målrettet udbedring
- SEO efterspænd og tjek
Hvorfor HTTPS er vigtigt for WordPress
Uden kryptering kan angribere kapre sessioner eller læse formularer, hvilket er grunden til, at jeg sikrer hele Transmission mellem browser og server med TLS. HTTPS forhindrer advarsler i browseren, øger tilliden og styrker de signaler, som søgemaskinerne vurderer positivt. Mange API'er, betalingstjenester og browserfunktioner kræver alligevel sikre forbindelser. Jeg drager også fordel af HTTP/2 og HTTP/3, som indlæses hurtigere under TLS og muliggør parallelisering. Et rent skift til HTTPS forhindrer duplikeret indhold, fordi jeg kan begrænse alle varianter til en unik Kanon (Kanonisk).
Forbered backup og SSL-certifikat
Før jeg rører ved nogen indstillinger, tager jeg en komplet backup af filerne og databasen, så jeg kan få adgang til dem når som helst. Sikring kan returnere. Derefter bestiller eller aktiverer jeg et certifikat - Let's Encrypt er ofte tilstrækkeligt uden ekstra omkostninger, alternativt bruger jeg et DV/OV/EV-certifikat afhængigt af mine krav. Mange hostere har en guide, der automatisk udsteder og fornyer certifikater. Hvis du har brug for trinvis hjælp, kan du bruge denne vejledning på Opsæt gratis SSL. Derefter kontrollerer jeg, om certifikatkæden er komplet, og om både www- og apex-domæner (uden www) er dækket af certifikatet; jeg tager også hensyn til underdomæner som staging eller cdn og beholder deres Gyldighed på et øjeblik.
Valg af certifikat og nøglehåndtering
Ud over den indledende aktivering bemærker jeg også et par detaljer, der mangler i mange instruktioner: Skal jeg bruge et wildcard-certifikat (*.domain.tld) til mange subdomæner, eller er et SAN-certifikat med flere eksplicitte værtsnavne tilstrækkeligt? Af hensyn til ydeevnen bruger jeg ECDSA-certifikater (elliptiske kurver) i stedet for klassiske RSA-nøgler, hvor det er muligt - de er mindre og gør TLS-håndtrykket hurtigere. Jeg beskytter den private nøgle strengt (filtilladelser 600, kun serverbrugere), og jeg dokumenterer Fornyelse-kæde: Går den automatiske fornyelse virkelig igennem, selv om et CDN eller en omvendt proxy er tilsluttet upstream? Ved ACME-udfordringer tjekker jeg, om omdirigeringer, takstgrænser eller vedligeholdelsessider forstyrrer valideringen. Jeg aktiverer også OCSP-hæftning og moderne protokoller (TLS 1.2/1.3) direkte i webserveren, så browsere kan behandle certifikattjek hurtigere.
Skift WordPress-URL'er
Jeg logger ind på dashboardet og åbner Indstillinger → Generelt, så sætter jeg "WordPress-adresse (URL)" og "Webstedsadresse (URL)" til https://. Når jeg har gemt, logger jeg ind igen, hvis sessionen genstarter. Derefter sletter jeg browserens cache og, hvis det er muligt, cachen i mit cache-plugin, så de besøgende straks får den sikre version. Derefter kigger jeg på widgets, menuer og hårde links, da de stadig kan indeholde http-links. For medier i indlæg redigerer jeg individuelt indhold eller planlægger en ren Søgning i databasen (se nedenfor).
Sikkert login og administration
Til administratorområdet håndhæver jeg TLS med en lille tilføjelse i wp-config.php. For at gøre dette tilføjer jeg følgende over linjen "/* Det er alt, stop med at redigere! */" og uploader filen:
define('FORCE_SSL_ADMIN', true);
Det betyder, at login, cookies og hele backend kører udelukkende via HTTPS. Hvis en reverse proxy eller et CDN-lag er tilsluttet upstream, sørger jeg for, at WordPress fortolker headeren "X-Forwarded-Proto: https" korrekt. Ellers behandler applikationen fejlagtigt forbindelsen som usikker og indstiller cookies uden Sikker-flag.
Mere sikre WordPress-konstanter og proxy-registrering
Hvis jeg ikke kan nå URL'erne i backend (f.eks. loop gennem plugins), sætter jeg midlertidigt eksplicitte konstanter i wp-config.php og eliminerer dermed forkerte indstillinger:
define('WP_HOME', 'https://deinedomain.de');
define('WP_SITEURL', 'https://deinedomain.de');
Jeg tilføjer også detektering bag proxyer, så is_ssl() korrekt:
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
$_SERVER['HTTPS'] = 'on';
}
Dette forhindrer forkert generering af blandet indhold i backend og sikrer, at auth-cookies konsekvent er knyttet til Sikker-attribut leveres.
Opsæt 301-omdirigeringer i .htaccess
For at sikre, at alle anmodninger permanent går til den sikre version, har jeg oprettet en Videresendelse fra http til https. I et klassisk Apache-miljø åbner jeg .htaccess i WordPress-roden og tilføjer reglerne over WordPress-blokken:
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Med Nginx sker viderestillingen i serverkonfigurationen (server { listen 80; return 301 https://$host$request_uri; }). For detaljer, varianter og fejlfinding kan du finde en klar vejledning til HTTPS-videresendelse. Vigtigt: Jeg holder omdirigeringskæden kort, dvs. http→https og om nødvendigt www→non-www eller omvendt i ét spring, så der ikke er nogen unødvendige hop i omdirigeringskæden. Opladningstid øge.
Ren omdirigeringsstrategi uden loops
Ud over den grundlæggende videresendelse sætter jeg regler for konsistens: Enten www eller ikke-www - aldrig begge dele. Med Apache løser jeg dette i ét trin med et hostcheck:
RewriteEngine On
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} !^deinedomain\.de$ [NC]
RewriteRule ^ https://deinedomain.de%{REQUEST_URI} [L,R=301]
Jeg modtager forespørgselsstrenge (UTM-parametre) automatisk, reducerer omdirigeringer til ét hop og undgår sløjfer ved ikke at aktivere konkurrerende regler i plugin'et eller CDN'et. Hvis en edge-proxy bruger "Flexible SSL" (Browser→CDN krypteret, CDN→Origin ukrypteret), skifter jeg til "Full (strict)", så TLS håndhæves for både den besøgende og oprindelsen - ellers er der risiko for loop-problemer og blandede protokoller.
Genkende og fjerne blandet indhold
Efter omdirigeringen tjekker jeg siden med browserværktøjerne for "blandet indhold", dvs. indhold, der stadig kan tilgås via http er indlæst. Billeder, skrifttyper, scripts eller stylesheets i temaer, page builders eller widgets er ofte påvirket. Jeg retter hårdt kodede URL'er ved at ændre dem til https i editoren, i customiser eller i plugin-indstillingerne. Værktøjer som "Really Simple SSL" hjælper på kort sigt, men en permanent oprydning af kilderne er bedre. Blokeret indhold forårsager stylingfejl eller skjulte funktioner, så jeg rydder op i alt, indtil browseren ikke blokerer noget indhold. Advarsler viser mere.
Professionel tjekliste med blandet indhold
- Jeg aktiverer CSP-direktivet som en test
opgradering-usikker-anmodningeri report-only mode for at se, hvad browseren automatisk opgraderer til https - så rydder jeg permanent op i kilderne. - Skrifttyper og eksterne stilarter kræver ofte CORS-overskrifter; uden
Adgangskontrol-Allow-Originde fremstår som blokerede. - Jeg genkender CSS-baggrundsbilleder med absolutte http-links i udviklerværktøjer og erstatter dem med relative stier eller https.
- iframes (f.eks. kort, videoer) skal også tale https, ellers skjuler browseren dem.
- I temaer undgår jeg hårdkodede stier og bruger funktioner som f.eks.
home_url(),site_url(),plugins_url()ogcontent_url()så WordPress leverer den korrekte basis-URL.
Trin-for-trin oversigt
Følgende tabel opsummerer alle de opgaver, der er involveret i omstillingen, i et kompakt format og hjælper mig med at Sekvens der skal overholdes.
| Trin | Anbefaling/forklaring |
|---|---|
| Opret backup | Gennemfør før hver ændring Sikring af filer og database |
| Opsæt SSL-certifikat | Aktivér Let's Encrypt eller en betalt version hos hosteren |
| Tilpas URL'er | Indstil til https i backend under Indstillinger → Generelt |
| Indstil omdirigeringer | Konfigurer .htaccess eller Nginx-serverblok til 301 til HTTPS |
| Tjek blandet indhold | Erstat hårde http-links i indhold, temaer og plugins |
| Udskift databasen | Erstat alle http-forekomster med en sikkerhedskopi og et velrenommeret værktøj |
| Opdater Google/SEO | Tilpas Search Console-egenskaber, sitemap, analyser og kanonikaler |
Erstat database-URL'er på en ren måde
Nogle gange ligger der http-links i widgets, kortkoder eller brugerdefinerede felter, så jeg bruger en afprøvet og testet Værktøj som "Bedre søgeudskiftning". Jeg søger efter "http://deinedomain.de" og erstatter det med "https://deinedomain.de", først i en prøveperiode og derefter i virkeligheden med backup. Til seriel omdøbning via WP-CLI bruger jeg "wp search-replace", som er meget hurtigere til store sider. Serialiserede arrays og objekter skal håndteres korrekt, så jeg er afhængig af værktøjer, der håndterer dette korrekt. Efter udskiftningen tjekker jeg tilfældige prøver i frontend og i vigtige Layouts.
Database: Hvad jeg ikke blindt erstatter
Jeg rører kun ved GUID-kolonnen i wp_posts, når jeg rent faktisk ændrer domænet. Den rene protokolændring til https kræver normalt ingen Ændring af GUID'er, da de primært tjener som en unik identifikator. Før en global udskiftning tjekker jeg også, om plugins refererer til eksterne endpoints (webhooks, API'er) med http - jeg foretrækker at opdatere disse specifikt og teste returkanalen. Ved store projekter planlægger jeg en kort indholdsfrysefase, så der ikke oprettes nye indlæg med gamle skemaer under søgeudskiftningen. Jeg bruger WP-CLI for at sikre hastighed og reproducerbarhed:
wp search-replace 'http://deinedomain.de' 'https://deinedomain.de' --all-tables-with-prefix --precise --dry-run
wp search-replace 'http://deinedomain.de' 'https://deinedomain.de' --all-tables-with-prefix --precise
SEO-tjek efter omstillingen
Efter ændringen opretter jeg en ny ejendom med https i Search Console og indsender en opdateret Sitemap på. Jeg tjekker interne links, kanoniske tags, hreflang-referencer og open graph-tags for https. Tracking snippets (analytics, tag manager, pixel) skal også bruge den sikre adresse. I SEO-plugins tjekker jeg omdirigeringsregler og sikrer, at der ikke er nogen "bløde 404'ere". Hvis tællere for sociale delinger er vigtige, tester jeg, hvordan værktøjet fungerer med den nye Adresse håndtag.
Finjuster feeds, robotter og canonicals
Jeg kontrollerer, om RSS/Atom-feeds er tilgængelige via https og leverer gyldigt indhold. I en statisk vedligeholdt robots.txt tilpasser jeg sitemap-stier til https, hvis det er nødvendigt. Jeg indstiller kanoniske URL'er konsekvent absolut med https, så søgemaskiner fortolker signaler entydigt. hreflang-par (flersprogede websteder) må ikke afvige i protokollen, ellers opstår der inkonsekvens.
Caching, CDN og ydeevne under HTTPS
HTTPS er også værdifuldt med hensyn til hastighed, da HTTP/2/3 muliggør multiplexing og header-komprimering via en Forbindelse. Jeg er opmærksom på genoptagelse af TLS-sessioner, OCSP-hæftning og moderne cipher-suiter, som gør håndtrykket hurtigere. Et CDN leverer statiske aktiver tættere på den besøgende, men skal konsekvent køre på https. I cache-plugins aktiverer jeg indstillingen "Cache for HTTPS", hvis den er tilgængelig, og rydder gamle artefakter. Derefter måler jeg med værktøjer som Lighthouse og sammenligner Tider før og efter ændringen.
CDN/Proxy-funktioner
Med et upstream CDN sætter jeg altid "Full (strict)" til Origin, uploader certifikatet der eller bruger et Origin-certifikat og tillader kun levering af https. Jeg tjekker, om CDN'et cacher omdirigeringer (ellers ser jeg gamle tilstande) og rydder edge-cacherne efter skiftet. Brotli-komprimering, HTTP/3/QUIC og 0-RTT kan også hjælpe - men det er vigtigt, at regler for hele siden ikke længere injicerer http-ressourcer. Endelig sender jeg den korrekte Klient-IP-header (f.eks. X-Forwarded-For) og konfigurer webserveren, så logfiler viser den rigtige besøgendes IP.
HSTS og andre sikkerhedsoverskrifter
Hvis webstedet udelukkende kører på HTTPS, aktiverer jeg HTTP Strict Transport Security (HSTS), så browsere kun bruger HTTPS-variant. Jeg sætter f.eks. headeren sådan her: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload - men kun hvis alle subdomæner virkelig er sikkert tilgængelige. For muligheder og faldgruber anbefaler jeg guiden Aktiver HSTS. Derudover indstiller jeg sikkerhedsoverskrifter som X-Content-Type-Options, X-Frame-Options og en stram indholdssikkerhedspolitik, der tillader https-kilder. Disse overskrifter styrker lagene af beskyttelse mod indholdsinjektion, clickjacking og MIME-Sniffing.
Finjuster sikkerhedshovedet
Ud over HSTS tilføjer jeg en pragmatisk header-konfiguration: Henvisningspolitik: strict-origin-when-cross-origin begrænser overførslen af følsomme stier, Politik for tilladelser begrænser browser-API'er (f.eks. kamera, mikrofon), og en moderat CSP med default-src 'self' https: forhindrer uønskede udenlandske kilder. Jeg begynder med Kun rapportJeg indsamler overtrædelser og strammer derefter retningslinjerne. Det er sådan, jeg forhindrer, at sikkerhedsoverskrifter utilsigtet "ødelægger" webstedet.
Test, overvågning og fejlfinding
Jeg tester overgangen i et privat vindue og på mobile enheder, så ingen gamle Cookies eller cacher. Browserens konsollog viser hurtigt advarsler om blandet indhold og blokerede ressourcer. Jeg bruger "curl -I http://deinedomain.de" til at tjekke, om der sker en 301 til https-versionen, og om der opstår andre kæder. Derefter overvåger jeg fejllogs på serveren og 404-rapporter i SEO-plugin'et eller i Search Console. Hvis enkelte plugins ikke længere indlæses, tjekker jeg deres eksterne Afhængigheder og opdatere den til den nyeste version.
Go-live-kontrol og løbende overvågning
- Jeg aktiverer eventuelt en kort vedligeholdelsestilstand, før jeg skifter, for at etablere ensartede omdirigeringer og cacher.
- Jeg overvåger certifikatets udløb (alarmer), så der ikke kommer ubehagelige overraskelser.
- I de første par dage overvåger jeg 404-raten, rankingkurver, crawl-statistikker og Core Web Vitals for at kunne træffe tidlige modforanstaltninger.
- For kampagner tjekker jeg, om UTM-parametre bevares fuldt ud via 301-omdirigering.
Særlige funktioner ved multisite, proxy og staging
For multisite ændrer jeg netværksadressen til https og justerer mappingerne, så alle sites har en ensartet Videresendelse brug. Bag load balancere eller CDN'er skal webserveren overholde "X-Forwarded-Proto"-headeren, ellers vil WordPress tro, at forbindelsen er usikker og indstille de forkerte URL'er. Til staging-systemer bruger jeg mine egne certifikater eller beskytter dem med Basic Auth, så søgemaskiner ikke indekserer dem. Efter live-ændringen slår jeg cacherne til igen, varmer dem op og overvåger belastningen. I miljøer med deres egne proxyer eller firewalls dokumenterer jeg alle ændringer, så senere implementeringer kan bruge Konfiguration tage over.
Multisite- og commerce-detaljer, der ofte mangler
I opsætninger med flere sider opdaterer jeg pr. side siteurl og hjem værdier, især hvis der er tale om domænekortlægning. Hvis en solopgang.php eller særlige mapping-plugins, tjekker jeg, om de er https-kompatible. I butikker (f.eks. WooCommerce) indstiller jeg konsekvent "Checkout" og "My account" til https, tester betaling og Webhook-returneringer og tak-sider. Betalingsudbydere og forsendelses-API'er kræver ofte opdaterede callback-URL'er - jeg tilpasser dem og verificerer signaturtjekket efter ændringen.
Almindelige faldgruber og hurtige løsninger
Forkerte certifikater giver røde advarselssignaler - jeg tjekker derfor udstedelsesperioden, kæden og om alle domæner er inkluderet i certifikatet, så Forbindelse kører uden afbrydelser. Manglende 301-redirects skaber duplikatindhold; jeg regulerer dette med klare, korte regler og undgår flere hop. Blandet indhold kommer ofte fra hårdt kodede temafiler; her erstatter jeg http-skemaer eller bruger skemaløse URL'er ("//...") på de relevante steder. Eksterne tjenester, der stadig refererer til http-blokeringsanmodninger; her opdaterer jeg webhooks, endpoints og nøgler. Hvis et plugin ikke kan håndtere overgangen, tester jeg en opdatering eller erstatter det med en løsning, der fuldt ud understøtter HTTPS. Understøtter.
Resumé: Skiftede sikkert til HTTPS
Jeg starter med en komplet backup, aktiverer CertifikatJeg skifter WordPress-URL'er til https, gennemtvinger 301-omdirigeringer og rydder konsekvent op i blandet indhold. Derefter erstatter jeg alle resterende http-poster i databasen, opdaterer SEO-indstillinger og måler performance. HSTS og sikkerhedsheaders øger sikkerheden yderligere, så længe alle subdomæner reagerer korrekt på https. Til hosting bruger jeg udbydere med god support, automatisk fornyelse og hurtig TLS-provisionering som webhoster.de, hvilket gør mit arbejde meget lettere. Det holder siden sikker, hurtig og synlig - og det er præcis, hvad jeg forventer af en bæredygtig hjemmeside. HTTPS-omstilling.
