WordPress 7.1 är ute. Underhålls din webbplats?

Två stora versioner på tre månader

WordPress stod inte still under 2026.

Den 20 maj 2026 släpptes WordPress 7.0 ”Armstrong”, uppkallad efter Louis Armstrong. Versionen introducerade bland annat en moderniserad administrativ upplevelse och en tydligare grund för AI-integrationer genom en AI Client i WordPress Core, Abilities API och klientbaserade funktioner.

Den 19 augusti 2026 följde WordPress 7.1 ”Mary Lou”, uppkallad efter jazzpianisten, arrangören och kompositören Mary Lou Williams.

7.1 vidareutvecklar flera delar av det dagliga arbetsflödet:

• adminfältet följer användaren genom hela administrationsmiljön
• block får mer direkt kontroll över responsiva stilar
• mediehanteringen samlas i ett tydligare flöde för beskärning, rotation, spegling och metadata
• Notes kan placeras mer flexibelt i innehållet, med formaterad text och omnämnanden
• nya Playlist- och Tabs-block utökar vad som kan byggas utan extra plugins
• utvecklare får bland annat ett API för att registrera egna ikoner till Icon-blocket

För utvecklare och redaktörer är det konkreta förbättringar. För en företagare är huvudbudskapet enklare:

Plattformen som webbplatsen körs på utvecklas kontinuerligt. Därför måste även webbplatsen förvaltas kontinuerligt.

Det här handlar om underhåll, inte om att jaga funktioner

De flesta företag behöver inte börja använda varje ny funktion samma dag den lanseras.

De behöver en webbplats som:

• förblir säker
• fungerar i den aktuella servermiljön
• har kompatibla teman och plugins
• beter sig korrekt på mobil och dator
• kan uppdateras utan panik
• har en fungerande säkerhetskopia om något går fel

WordPress passar fortfarande bra för många marknadsföringssajter, publiceringslösningar, medlemswebbplatser och webbutiker. Det förutsätter att underhåll behandlas som normal drift, inte som en uppgift som skjuts upp tills något slutar fungera.

Jag arbetar regelbundet med WordPress-webbplatser och ser ofta samma skillnad efter större versioner.

Team med en underhållsrutin kan testa och införa förändringar under kontrollerade former. Team som skjuter upp uppdateringar länge får oftare ett separat återhämtningsprojekt där WordPress Core, PHP, tema, plugins och hosting måste hanteras samtidigt.

Det som kunde ha varit rutin blir räddningsarbete.

Att vara uppdaterad betyder inte alltid att installera samma dag

Det är viktigt att skilja mellan olika typer av uppdateringar.

Säkerhetsuppdateringar bör normalt bedömas och installeras snabbt. Kända sårbarheter genomsöks ofta automatiskt, och en liten webbplats är inte osynlig bara för att den har lite trafik.

Underhållsversioner innehåller vanligtvis felrättningar och bör ingå i en regelbunden uppdateringsrutin.

Stora versioner, som 7.0 och 7.1, kan innehålla större förändringar i redigeraren, API:er och administrationsmiljön. De bör testas mot webbplatsens tema, plugins, servermiljö och kritiska funktioner före uppdatering i produktion.

Målet är alltså inte att vara först. Målet är att ligga tillräckligt nära aktuella versioner för att uppgraderingen ska förbli hanterbar.

En webbplats som ligger en kontrollerad version efter under några veckor medan teamet testar är inte nödvändigtvis dåligt underhållen. En webbplats som ligger flera år efter utan att någon vet varför är något annat.

”Vi uppdaterar senare” har ett pris

När jag granskar äldre WordPress-miljöer ser jag ofta en kombination av samma varningssignaler:

• WordPress Core ligger flera versioner efter
• PHP-versionen är gammal eller närmar sig slutet av sin supporttid
• webbplatsen har många plugins, men ingen vet vilka som fortfarande behövs
• vissa tillägg är övergivna eller borttagna från marknaden
• temat har inte granskats sedan lanseringen
• en säkerhetskopia finns, men ingen har testat om den går att återställa
• stagingmiljö saknas eller skiljer sig kraftigt från produktion
• hostingen var tillräcklig för flera år sedan men har aldrig omvärderats
• formulär och analysmätning har inte testats på länge

Startsidan kan fortfarande se helt normal ut. Sidorna öppnas, formuläret ser korrekt ut och ingenting känns akut.

Sedan kommer en tvingande PHP-uppgradering, ett plugin som inte längre stöds, en säkerhetsincident eller ett fel som bara syns i ett kritiskt användarflöde. Plötsligt måste flera års teknisk skuld lösas under tidspress.

För verksamheten kan det innebära:

• driftstopp
• förlorade förfrågningar eller beställningar
• trasig spårning
• dyr sanering
• försenad marknadsföring
• beroende av en person som förstår det gamla systemet
• behov av en tidigare ombyggnad än planerat

En strukturerad WordPress-hälsokontroll kan upptäcka många av problemen medan det fortfarande finns tid att prioritera dem.

Säkerhetsuppdateringar handlar om verksamhetens kontinuitet

WordPress-säkerhet handlar inte bara om WordPress Core.

En vanlig webbplats består också av:

• tema
• plugins
• hosting och serverprogramvara
• PHP och databas
• administratörskonton
• tredjepartsintegrationer
• formulär och e-postleverans
• säkerhetskopiering och återställning

En aktuell WordPress-version hjälper inte om ett övergivet plugin har en känd sårbarhet. På samma sätt löses inte alla problem genom att installera ett säkerhetsplugin om administratörslösenord delas, gamla konton ligger kvar eller ingen någonsin testar säkerhetskopian.

Ett intrång är sällan ”bara ett IT-problem”. Det kan leda till att:

• webbplatsen blir otillgänglig
• besökare omdirigeras till bedrägliga sidor
• uppgifter från formulär exponeras
• domänens eller e-postens anseende skadas
• annonser skickar betald trafik till en trasig sida
• teamet måste betala för akut sanering och återställning

Underhåll tar inte bort all risk. Det minskar onödig risk och gör det lättare att agera när något inträffar.

Plugins: WordPress styrka och underhållsrisk

Plugins är en viktig anledning till att WordPress passar så många olika projekt. De gör det möjligt att lägga till formulär, SEO-funktioner, flerspråkighet, e-handel, caching, medlemskap och integrationer utan att utveckla allt från grunden.

Varje plugin tillför samtidigt:

• kod som ska laddas
• fler uppdateringar
• möjlig konflikt med tema eller andra plugins
• en extern leverantör som verksamheten blir beroende av
• fler inställningar som någon måste förstå
• potentiell säkerhets- och integritetsrisk

I granskningar har jag hittat flera tillägg som löser överlappande problem. Varje enskilt tillägg kan verka rimligt, men tillsammans skapar de ett system som ingen vill ändra.

Innan du jagar nya funktioner i WordPress 7.1 bör du därför kartlägga vad webbplatsen faktiskt behöver:

1. Ta bort inaktiva plugins som inte ska användas igen.
2. Identifiera aktiva plugins som inte längre fyller en tydlig funktion.
3. Leta efter lösningar som överlappar varandra.
4. Kontrollera när varje tillägg senast uppdaterades.
5. Bedöm om leverantören aktivt stöder aktuella versioner av WordPress och PHP.
6. Testa innan något ersätts eller tas bort i produktion.
7. Dokumentera vilka plugins som är verksamhetskritiska.

Färre beroenden är inte automatiskt bättre om viktig funktionalitet då måste byggas och underhållas internt. Målet är inte lägsta möjliga antal, utan en kontrollerad uppsättning nödvändiga och aktivt underhållna beroenden.

Uppdateringen ensam löser inte prestandaproblemen

WordPress 7.0 och 7.1 förbättrar delar av plattformen och arbetsflödet. Det innebär inte att en Core-uppdatering automatiskt gör en långsam webbplats snabb.

WordPress Core kan inte ensam rätta till:

• enorma hero-bilder
• video som laddas innan den behövs
• fler analys- och annonsskript än verksamheten använder
• tunga page builder-miljöer
• typsnitt och stilmallar som laddas utan kontroll
• svag hosting
• API-anrop som blockerar sidan
• flera år av snabba tekniska nödlösningar

Jag har sett betydande prestandaförbättringar på marknadsföringswebbplatser efter arbete med bilder, skript, caching och resursladdning. Värdet kom från att hitta de faktiska flaskhalsarna, inte från att installera en ny huvudversion och hoppas på det bästa.

Om prestandan aldrig har granskats ordentligt, börja med en prestandaanalys av de viktigaste mallarna och användarflödena.

Användare säger inte att webbplatsen har ett LCP- eller INP-problem. De upplever bara att den känns långsam, instabil eller tung att använda.

Så skulle jag planera uppgraderingen till 7.1

En större WordPress-uppgradering bör behandlas som en mindre teknisk leverans, inte som ett slumpmässigt klick mellan andra arbetsuppgifter.

1. Kartlägg utgångsläget

Dokumentera:

• aktuell WordPress-version
• PHP- och databasversion
• aktivt tema och eventuellt child theme
• aktiva och inaktiva plugins
• egen kod
• hostingmiljö
• kritiska integrationer
• senaste fungerande säkerhetskopia

Om webbplatsen ligger långt efter är WordPress-versionen inte nödvändigtvis den enda utmaningen. PHP, temat och tilläggen kan innebära större risk.

2. Skapa en fullständig säkerhetskopia

Säkerhetskopian bör innehålla både filer och databas. Kontrollera var den lagras, hur länge den sparas och hur den återställs.

En säkerhetskopia som aldrig har testats är ett hopp, inte en dokumenterad återställningsplan.

3. Skapa en representativ stagingmiljö

Staging bör likna produktion när det gäller:

• PHP-version
• aktiva plugins
• tema och egen kod
• viktiga inställningar
• tillräckligt med verkligt innehåll för att mallarna ska kunna testas

Se samtidigt till att staging inte skickar riktiga kundmeddelanden, indexeras av sökmotorer eller av misstag utlöser produktionsintegrationer.

4. Kontrollera kompatibiliteten

Leta efter:

• dokumenterat stöd för WordPress 7.1
• nyare versioner av tema och plugins
• övergivna tillägg
• kända fel från leverantörerna
• föråldrad egen kod
• beroenden som kräver en annan PHP-version

Texten ”Compatible up to” är användbar, men ingen garanti. Det verkliga testet är din webbplats med era data och arbetsflöden.

5. Uppdatera och testa på staging

Testa mer än startsidan.

Gå igenom:

• kontaktformulär och e-postleverans
• inloggning och administration
• sök
• menyer och mobilnavigation
• viktiga sidmallar
• flerspråkiga sidor
• betalning och checkout
• medlemskap eller konton
• cookies och samtycke
• analytics och händelser
• caching
• schemalagda jobb och integrationer

Kontrollera även fel i webbläsarkonsolen, PHP-loggar och serverloggar.

6. Jämför prestanda och visning

Mät några representativa sidor före och efter uppgraderingen. Kontrollera både mobil och dator.

Leta efter:

• förändrade laddningstider
• nya JavaScript-fel
• layoutförändringar
• förlorad styling
• problem i redigeraren
• förändrad caching
• skillnader mellan inloggade och utloggade användare

Målet är inte att varje mätvärde måste förbättras efter en Core-uppgradering. Målet är att hitta regressioner innan användarna gör det.

7. Planera produktionsuppdateringen

Välj en tidpunkt med:

• lägre trafik
• någon tillgänglig för kontroll efteråt
• en tydlig återställningsplan
• ingen större kampanj eller publicering samtidigt
• tid att agera om något går fel

Fredag eftermiddag utan någon tillgänglig för uppföljning är sällan ett bra tillfälle.

8. Övervaka efter publicering

Kontrollera webbplatsen direkt efter uppdateringen och igen när bakgrundsprocesser, cache och verklig trafik har hunnit påverka systemet.

Titta särskilt på:

• formulär och e-post
• betalning eller bokning
• felloggar
• trafik och konverteringshändelser
• serverbelastning
• schemalagda processer
• redaktörernas arbetsflöde

En lyckad driftsättning betyder inte bara att startsidan öppnas. Det betyder att kritiska funktioner fortfarande gör sitt jobb.

Vad gäller för webbplatser som ligger flera år efter?

Det finns inte en enda korrekt uppgraderingsmetod för alla äldre WordPress-installationer.

WordPress Core kan ofta uppgraderas direkt över flera versioner. Det betyder inte att webbplatsens hela ekosystem klarar ett stort hopp utan förberedelser. Risken ligger ofta i gammal PHP, föråldrade plugins, övergivet tema eller egen kod, inte bara i WordPress Core.

Jag skulle därför inte automatiskt installera alla mellanversioner en efter en i produktion. Jag skulle först:

1. klona webbplatsen till staging
2. dokumentera den nuvarande miljön
3. uppdatera eller ersätta kritiska beroenden
4. testa målversionen
5. undersöka fel och kompatibilitet
6. avgöra om uppgradering eller ombyggnad är mest rimlig

Vissa gamla webbplatser kan föras upp till aktuell version genom kontrollerad upprensning. Andra har så stor teknisk skuld att ännu en omgång tillfälliga lösningar blir dyrare än en planerad ombyggnad.

Det bör avgöras efter en teknisk bedömning, inte enbart efter versionsnumret.

Vad 7.0 och 7.1 betyder i praktiken

WordPress 7.0 lade en tydligare grund för AI-integrationer i Core. Det betyder inte att alla webbplatser omedelbart bör kopplas till en modell eller automatisera innehållsproduktionen.

Innan sådana funktioner används bör verksamheten klargöra:

• vilken leverantör data skickas till
• vilka uppgifter som får ingå i en begäran
• vem som granskar och godkänner resultatet
• vilka kostnader integrationen skapar
• hur fel och olämpligt innehåll hanteras
• om funktionen faktiskt löser ett verkligt problem

WordPress 7.1 ger mer omedelbara förbättringar i administration, responsiva stilar, mediearbete och samarbete. Vissa team får direkt nytta av dem. Andra märker knappt någon skillnad på den publika webbplatsen.

Det är helt i sin ordning.

Affärsvärdet i en uppgradering är inte att varje ny funktion börjar användas. Värdet är att plattformen förblir stödd, hanterbar och redo för fortsatt utveckling.

Skapa en rytm, inte ett årligt räddningsprojekt

Ett realistiskt underhållsupplägg kan innehålla:

• regelbunden kontroll av tillgängliga uppdateringar
• snabb bedömning av säkerhetsversioner
• planerad testning av stora WordPress-versioner
• automatiska säkerhetskopior med återkommande test av återställning
• regelbunden granskning av användare och administratörsbehörigheter
• kontroll av formulär, e-post och betalningar
• månatlig eller kvartalsvis prestandakontroll
• upprensning bland plugins, innehåll och gamla integrationer
• dokumentation av väsentliga förändringar

Hur ofta varje punkt bör utföras beror på risken.

En enkel presentationswebbplats och en webbutik med dagliga transaktioner behöver inte samma beredskap. En webbplats som genererar en stor del av omsättningen bör heller inte underhållas som en digital broschyr utan ägare.

Meningen jag skulle komma ihåg

Din webbplats är infrastruktur. Infrastruktur som uppdateras, säkerhetskopieras och testas enligt plan är säkrare och vanligtvis billigare att äga än infrastruktur som måste räddas efter en kris.

WordPress 7.1 är den aktuella stora versionen i augusti 2026. Det är ingen mållinje, utan ännu en påminnelse om att kontrollera var webbplatsen står.

Du behöver inte installera varje funktion eller uppgradera utan testning. Du behöver en känd version, kontrollerade beroenden, fungerande säkerhetskopiering och en plan för nästa uppdatering.

Osäker på om webbplatsen är redo för nästa uppgradering?

Jag har sett företag lägga mer pengar på att reparera problem som kunde ha hittats i tid än de skulle ha lagt på planerat underhåll.

En fokuserad genomgång kan upptäcka föråldrade plugins, kompatibilitetsproblem, prestandaflaskhalsar, säkerhetsrisker och brister i backup eller uppgraderingsrutiner innan situationen blir akut.

Begär en webbplatsanalys och få en tydlig bild av webbplatsens säkerhet, prestanda och beredskap för WordPress 7.1 och kommande versioner.