Mājaslapas tehniskā inventarizācija un satura audits gada nogalē

Gada laikā jebkura aktīva uzņēmuma mājaslapa uzkrāj ievērojamu daudzumu digitālo gružu: vecās kampaņu nolaišanās lapas, kuras vairs nav aktuālas, izdzēstu produktu saites, kas rada 404 kļūdas, desmitiem tūkstošu nevajadzīgu datubāzes revīziju un novecojušus satura gadaskaitļus. Šis balasts lēnām, bet neatgriezeniski samazina lapas ielādes ātrumu, tērē meklētājprogrammu pārmeklēšanas budžetu (Crawl Budget) un rada nevīžīgu iespaidu par uzņēmumu.

Decembra vidus ir ideālais laiks, lai pasūtītu neatkarīgu tehnisko un SEO auditu pamatīgai vietnes inventarizācijai. Šajā tehniskajā pamācībā parādīsim konkrētus inženiertehniskos un satura soļus, kā veikt sistēmas pilno revīziju, sakārtot pāradresācijas, konsolidēt vājo saturu, optimizēt MySQL datubāzi un sagatavot vietni jaudīgam jaunam biznesa cēlienam nākamajā gadā.

1. Solis - 404 kļūdu un bojāto iekšējo saišu audits

Meklēšanas autoritātes un indeksācijas nostiprināšanai, ko garantē ilgtermiņa SEO un GEO optimizācija, pirmais solis ir pilna vietnes pārmeklēšana ar rīkiem Screaming Frog vai Sitebulb. Katra iekšējā saite, kas ved uz neesošu lapu (404 Not Found), ir jāsalabo koda līmenī vai jāpāradresē ar pastāvīgo 301 kodu uz tematiski tuvāko aktuālo sadaļu.

• Pāradresāciju ķēžu (Redirect Chains) likvidēšana: Bieži vien vecā saite ved uz lapu, kas savukārt pāradresē uz vēl citu adresi (A -> B -> C). Katrs liekais lēciens palielina atbildes laiku par 100-300 ms un izšķērdē Googlebot pārmeklēšanas resursus. Visas pāradresācijas ir jāsavelk pa tiešo uz gala adresi (A -> C).
• Mākslīgo 404 kļūdu monitorings: Pārbaudiet Google Search Console pārskatu 'Not found (404)'. Ja sarakstā parādās saites no iepriekšējām mārketinga kampaņām ar augstu ārējo saišu skaitu, tās nedrīkst atstāt tukšas.
• Nginx līmeņa pāradresācijas: Izvairieties no smagiem WordPress pāradresāciju spraudņiem, kas katru pieprasījumu dzen caur PHP un datubāzi. Kritiskos ceļus nofiksējiet tieši Nginx servera konfigurācijā.

# Nginx konfigurācijā: veco kampaņu un sezonālo lapu 301 pāradresācijas
location = /melna-piektdiena-2024/ {
    return 301 https://marketmenow.eu/reklamas/google-ads/;
}

location = /vasaras-akcija/ {
    return 301 https://marketmenow.eu/pakalpojumi/;
}

location = /vecais-pakalpojums/ {
    return 301 https://marketmenow.eu/jaunais-pakalpojums/;
}

Aigars Armanovs Vadošais Tehnoloģiju & Mārketinga Arhitekts

"Nekad neatstājiet vecas kampaņu lapas vienkārši 'karājoties gaisā' vai izdzēstas bez pāradresācijas. Šīm lapām gada laikā ir uzkrāta autoritāte un atpakaļsaites. Pāradresējot tās uz galvenajām pakalpojumu lapām ar 301 kodu, jūs šo SEO svaru nododat savai pamatlapai un saglabājat Google uzticību."

2. Solis - Satura audits un 'zombiju' lapu konsolidācija (Content Pruning)

Daudzi uzņēmumi kļūdaini uzskata, ka vairāk lapu vietnē automātiski nozīmē vairāk apmeklētāju no Google. Realitātē notiek pretējais: vājas, 300 vārdu ziņas bez satura vērtības vai gadiem neapmeklēti raksti kļūst par 'zombiju lapām', kas atšķaida vietnes kopējo autoritāti un velk uz leju pat labākos materiālus.

• Datu atlase no Search Console un GA4: Eksportējiet visu vietnes URL sarakstu par pēdējiem 12 mēnešiem. Sašķirojiet lapas pēc klikšķu un seansu skaita. Lapas ar mazāk nekā 10 seansiem gadā ir galvenie kandidāti satura revīzijai.
• Satura kanibalizācijas novēršana: Ja uzņēmuma emuārā ir trīs atsevišķi raksti par vienu un to pašu tematu (piemēram, 'Kā izvēlēties mājaslapu', 'Mājaslapas izveides padomi' un 'Mājaslapas kļūdas'), tie savā starpā konkurē Google indeksā. Labākais risinājums ir apvienot visu vērtīgo informāciju vienā spēcīgā, izsmeļošā pīlāra ceļvedī, bet pārējās divas adreses pāradresēt ar 301 kodu.
• Lēmumu matrica (Update, Merge vai Delete): Katrai lapai jāpiešķir konkrēts statuss. Aktuālajām pakalpojumu lapām veiciet faktu un statistikas atjaunināšanu (Update). Dublējošam saturam izmantojiet apvienošanu (Merge). Novecojušus, neaktuālus pasākumu paziņojumus un sludinājumus izdzēsiet, pāradresējot uz mātes kategoriju (Prune).

3. Solis - Datubāzes tīrīšana no vecajām revīzijām un liekajiem datiem

WordPress pēc noklusējuma saglabā katru raksta melnrakstu, automātisko saglabāšanu un labojumu. Ja vietnē ir 100 raksti un katrs gada laikā labots 30 reizes, datubāzē glabājas 3,000 lieku rindu, kas padara wp_posts un wp_postmeta tabulas smagas un palēnina SQL vaicājumu izpildi. Tīrīšanu visdrošāk un efektīvāk veikt tieši caur WP-CLI:

# 1. Dzēst visas vecās rakstu revīzijas un automātiskos melnrakstus
wp post delete  --force

# 2. Dzēst beigušos un liekos transient datus no wp_options
wp transient delete --expired
wp transient delete --all

# 3. Iztīrīt nepiesaistītos metadatus (orphaned postmeta)
wp db query "DELETE pm FROM wp_postmeta pm LEFT JOIN wp_posts wp ON wp.ID = pm.post_id WHERE wp.ID IS NULL;"

# 4. Veikt visu tabulu defragmentāciju un indeksu optimizāciju
wp db optimize

4. Solis - Spraudņu revīzija, koda higiēna un ātruma audits

Gada laikā mājaslapā bieži tiek instalēti dažādi testa spraudņi, trešo pušu mārketinga pikseļi, logrīki un paplašinājumi, kas pēc akcijas beigām tiek aizmirsti. Katrs neaktīvs vai lieks spraudnis rada papildu drošības ievainojamības risku un palielina servera atbildes laiku. Vienlaikus veiktspējas atjaunošanai palīdz mērķtiecīga mājaslapas ātruma optimizācija, nodrošinot, ka vietne jaunajā gadā ielādējas acumirklī.

• Neaktīvo spraudņu pilnīga dzēšana: Vienkārša spraudņa deaktivizēšana (Deactivate) nav pietiekama. Neaktīvie spraudņi joprojām atrodas failu sistēmā un satur PHP failus, kas var kļūt par uzbrukuma mērķi. Ja spraudnis netiek lietots, tas ir pilnībā jāizdzēš.
• Trešo pušu ārējo skriptu revīzija: Pārskatiet Google Tag Manager un lapas galveni (Header). Atslēdziet veco mārketinga kampaņu pikseļus (vecos Hotjar ierakstītājus, kampaņu čatbota logrīkus vai pasākumu konversiju birkas), kas katrā lapas atvēršanā lieki noslogo lietotāja pārlūku ar 200-500 KB lieka koda.
• Gada skaitļu dinamiska atjaunošana: Pārliecinieties, ka kājenes autortiesību rindā gads tiek ģenerēts dinamiski ar PHP kodu <?php echo date('Y'); ?>, nevis ierakstīts kā statisks teksts, kas katru janvāri prasa manuālu pārrakstīšanu.

5. Solis - Servera vides gatavība un 'Disaster Recovery' tests

Gada nogales inventarizācijas noslēdzošais un atbildīgākais posms ir servera infrastruktūras un drošības pārbaude. Pārliecinieties, ka vietne darbojas ar aktuālo PHP versiju (vismaz PHP 8.2 vai 8.3), kas nodrošina par 15-20% ātrāku koda izpildi un novērš novecojušo bibliotēku drošības caurumus.

• Ārpusservera rezerves kopija (Off-site Backup): Pārliecinieties, ka rezerves kopijas netiek glabātas tajā pašā serverī, kur pati mājaslapa. Rezerves kopijai (datubāzei un failiem) ir automātiski jānonāk šifrētā ārējā glabātuvē (piemēram, AWS S3, Hetzner Storage Box vai privātā mākonī).
• Atjaunošanas tests (Disaster Recovery Drill): Rezerves kopija ir bezvērtīga, ja to nevar veiksmīgi atjaunot. Vismaz reizi gadā veiciet testa atjaunošanu staging vidē, lai būtu droši, ka avārijas gadījumā vietni var pilnībā atjaunot 30 minūšu laikā.
• SSL/TLS un drošības galveņu audits: Pārbaudiet HTTPS sertifikāta automātisko atjaunošanos (Let's Encrypt / Certbot) un pārliecinieties, ka Nginx konfigurācijā ir aktīvas modernas drošības galvenes (HSTS, X-Frame-Options, X-Content-Type-Options).

Tehniskās inventarizācijas un satura audita kopsavilkums

Kopsavilkums un jaunā gada biznesa starts

Mājaslapas tehniskā inventarizācija gada nogalē nav vienreizējs pienākums, bet gan profilaktiska apkope, kas atdala profesionāli vadītus uzņēmumus no tiem, kuru digitālā vide gadiem grimst tehniskajā parādā. Sakārtojot iekšējās saites, iztīrot datubāzi, konsolidējot saturu un pārbaudot drošības sistēmas decembrī, jūsu vietne jauno biznesa gadu sagaida ar maksimālu ātrumu, augstāku Google uzticību un gatavību konvertēt jaunus klientus jau no pirmajām janvāra dienām.

Biežāk uzdotie jautājumi par tehnisko inventarizāciju un auditu