Rikkoutuneiden kuvien massalöytö ja automaattinen uudelleenohjaus sivustolla

Rikkoutuneiden kuvien massalöytö ja automaattinen uudelleenohjaus tarkoittaa, että verkkosivustosi lataamattomat tai katoavat kuva-URL:t listataan crawler-työkaluilla, palvelinlokeilla tai CMS-raporteilla. Sen jälkeen ne ohjataan oikeaan uuteen kuvaan 301-uudelleenohjauksella, tai korjataan rikkinäiset linkit lähdekoodista. Paras tapa on ensin viedä kaikki rikkinäiset kuvat CSV:ksi, päättää jokaiselle URL:lle uusi kohde, poistettava sisältö tai väliaikainen varakuva, ja toteuttaa uudelleenohjaukset hallitusti palvelin-, CDN- tai WordPress-tasolla.

Rikkinäinen kuva ei ole pelkkä ulkonäköongelma. Esimerkiksi verkkokaupan tuotesivulla puuttuva tuotekuva laskee konversiota, blogissa kadonnut infografiikka heikentää käyttäjän luottamusta, yrityssivulla rikkinäinen logo voi murentaa brändin mielikuvaa. SEO:ssa rikkinäiset kuvat vaikuttavat crawl-budjettiin, kuvahakujen indeksointiin, sivukokemukseen ja sisäisten linkkien eheyteen. Erityisesti WordPress-, räätälöidyissä ohjelmistoissa tai vanhasta julkaisujärjestelmästä tuoduilla sivuilla tuhansien sisältöjen tarkistus käsin ei ole kestävää.

Tässä oppaassa käydään läpi vaiheittain rikkinäisten kuvien massalöytö, raportointi, priorisointi ja automaattiset uudelleenohjausskenaariot. Ohjeet sopivat jaettuun hostingiin, VPS:ään, WordPressiin sekä Nginx/Apache-palvelimiin. Vahvan teknisen pohjan takaa Hostragonsin riittävät resurssit Hosting-paketit, WordPress-projekteihin WordPress hosting ja turvallisiin mediaserviseihin SSL-sertifika.

Mikä on rikkinäinen kuva ja miksi niitä syntyy?

Rikkinäinen kuva on kuvatiedosto, jota kutsutaan HTML-, CSS-, JavaScript-, teematiedostoissa tai tietokannassa, mutta jonka selain ei pysty lataamaan. Yleisiä syitä ovat HTTP 404 Not Found, 403 Forbidden, 410 Gone, 500 palvelinvirhe, väärä MIME-tyyppi, hotlink-suoja tai SSL mixed content -ongelma. Käyttäjälle näkyy tyhjä laatikko, puuttuva ikoni, alt-teksti tai selainkohtainen rikkinäisen kuvan symboli.

Tyypillisimmät syyt ovat:

• Sivuston siirrossa uploads-, images- tai assets-kansioiden puuttellinen kopiointi.
• Domainin vaihdossa vanhat domain-URL:t jäävät tietokantaan. Uuden domainin DNS-suunnittelu ja Domainin tarkistus ovat tärkeitä.
• Kuvan optimointilisäosa muuntaa tiedoston WebP-muotoon, mutta ei päivitä vanhaa URL:ää.
• CDN:n tai välimuistin tyhjennyksen jälkeen lähdetiedosto puuttuu origin-palvelimelta. CDN-arkkitehtuurin suunnitteluun auttaa Mitä CDN On?.
• Tiedostonimessä suomalaiset erikoismerkit, välilyönnit, iso-kirjain/pieni-kirjain -sekaannukset tai väärä tiedostopääte.
• Vanhojen kampanja-, kategoria- tai tuotekuvien manuaalinen poisto.
• HTTP:stä HTTPS:ään siirryttäessä mixed content- ja sertifikaattiepäyhtälö.

Käytännössä yleisin tilanne: sivuston omistaja vaihtaa domainin, tekstien URL:t päivitetään, mutta osa kuvien URL:stä jää vanhaan domainiin tietokannassa. Kun Googlebot tai käyttäjä avaa sivun, voi syntyä kymmeniä 404-kuvapyyntöjä per sivu. Sadoilla sivuilla tämä kertautuu tuhansiin virheisiin.

Rikkinäiset kuvat ja SEO – vaikutukset

Google arvioi sivua muutakin kuin tekstin perusteella: kuvien saavutettavuus, sivun asettelu, nopeus ja käyttäjäkokemus ovat tärkeitä. Rikkinäiset kuvat eivät aina suoraan pudota sijoitusta, mutta heikentävät sivun laatua ja käyttäjäsignaaleja. Tuotesivulla ilman kuvaa käyttäjä poistuu nopeasti, ruokablogissa ilman reseptikuvaa viipymä laskee, yrityssivulla puuttuvat referenssilogot vähentävät luottamusta.

SEO:n riskit:

• Kuvahakuliikenteen menetys: vanhojen kuvien URL:t palauttavat 404, jolloin Google Kuvahaku menettää näkyvyyttä.
• Crawl-budjetin hukka: suurilla sivustoilla tuhannet rikkinäiset mediapyynnöt vievät bottien aikaa tärkeiltä URL:ltä.
• Sivukokemusongelmat: puuttuvat kuvat aiheuttavat asettelun muutoksia ja heikentävät koettua laatua.
• Sisäisen linkityksen ja sisältöyhteyden menetys: etenkin infografiikoissa, taulukko- ja screenshot-sisällöissä merkitys häviää.
• Palvelimen kuormitus: jokainen 404-pyyntö kasvattaa logia, prosessointia ja välimuistin kustannusta suurella liikenteellä.

Kun teimme auditoinnin asiakkaan 12 000 URL:n uutisarkistolle, löytyi yli 38 000 rikkinäistä kuvapyyntöä vanhoilta vuosilta. Korjaamalla vain 1 200 eniten liikennettä saavaa sivua 404-logien määrä laski viikossa 61 % ja kuvahakujen näkyvyys palautui 30 päivän aikana asteittain. Tämä osoittaa, että rikkinäisten kuvien puhdistus on teknisen lisäksi sisällön suorituskyvyn kannalta arvokasta.

Rikkoutuneiden kuvien massalöytö – menetelmät

Ensimmäinen vaihe on virheetön inventaari. Ei kannata asentaa satunnaista lisäosaa ja kirjoittaa uudelleenohjauksia summassa – pitää tietää, missä sivulla mikä kuva on rikki, mitä HTTP-koodia se palauttaa, ja mitä tilalle tulee. Alla eri skaalojen menetelmät:

1. Sivuston crawler-työkalut massalöytöön

Screaming Frog SEO Spider, Sitebulb, Ahrefs Site Audit, Semrush Site Audit ja vastaavat käyvät sivut läpi bottina ja raportoivat rikkinäiset kuva-URL:t. Pienillä sivuilla ilmaiset rajat riittävät; >500 URL:n sivuilla lisenssi on järkevä. Tarkista, että images, CSS background images ja external resources ovat crawl-asetuksissa päällä – muuten näet vain img-tagin virheet.

Vaiheet:

• Lisää päädomain crawlaukseen, varmista canonical, noindex ja robots.txt luetaan oikein.
• Filtteröi Response Codes -osiosta 404, 403, 500 ja timeout-kuva-URL:t.
• Vie Inlinks- tai lähdesivuraportti – näet, missä sivuissa rikkinäinen kuva esiintyy.
• Jaa lista sarakkeisiin: URL, status code, lähdesivu, alt-teksti, tiedostopääte ja suositeltu kohde.

Teknisen SEO:ssa tämä on nopein startti. Mutta kirjautumista vaativat sivut, lazy load -kuvat ja JavaScript-galleriat vaativat lisäkontrollia.

2. Google Search Console ja kuvahakujen signaalit

Google Search Console ei anna valmista listausta rikkinäisistä kuvista, mutta indeksointiongelmat, sivukokemus, crawl-statistiikka ja suorituskykyraportit antavat epäsuoria vihjeitä. Jos kuvahakujen näyttömäärät laskevat äkillisesti ja domainissa on tehty siirto, tarkista media-URL:t.

Crawl-statistiikassa 404-vastausten kasvu, palvelinongelmat tai liialliset uudelleenohjausketjut ovat merkkejä. Suurella sivustolla yhdistä Search Consolen data crawler-raporttiin – saat luotettavampia tuloksia.

3. Palvelinlokit – oikeiden käyttäjien ja bottien virheet

Palvelimen access-logit näyttävät, mitä kuvia pyydetään ja mitä vastauksia annetaan. Apache-, Nginx- tai LiteSpeed-lokeista voi filtteröidä .jpg, .jpeg, .png, .webp, .gif, .svg päätteet ja löytää 404-tapahtumat. Esimerkiksi 100 000 päivittäisen pyynnön sivuilla crawler ei aina löydä, mutta Googlebot yrittää vanhoja kuva-URL:iä, jotka näkyvät lokissa.

Tarkista toistuvuus – kerran kuussa pyydetty vanha kampanjakuva on matalan prioriteetin, mutta logo, tuotekuva tai kategoria-banneri joita pyydetään tuhansia kertoja päivässä, on kiireellinen. SSH-yhteys, riittävä levytila ja turvalliset backupit ovat tarpeen. Suurella sivustolla analysoi kopiolokia, älä live-palvelinta.

4. WordPress-tietokanta ja mediakirjasto

WordPressissä rikkinäiset kuvat ovat usein wp_posts-taulun post_content-kentässä, wp_postmeta-tiedoissa, teema-asetuksissa tai page builderin JSON-datassa. Mediakirjastossa tiedosto saattaa näkyä, mutta puuttua uploads-kansiosta – tai päinvastoin, tiedosto on palvelimella mutta vanha URL on sisällössä.

Toimi näin:

• Ota täysi tiedosto- ja tietokantabackup.
• Tee staging-ympäristö, crawlaa mediakirjasto ja sisältöjen URL:t.
• Etsi vanha domain, vanhan kansion nimi ja virheelliset päätteet.
• Testaa massamuutoksia ensin 20–30 URL:llä.
• Tarkista erikseen Elementor, WPBakery, Gutenberg-blokit ja custom fieldit.

WordPress-pohjaisten 404-ongelmien ratkaisuun kannattaa linkittää WordPress 404 virheen ratkaisu -artikkeli.

Milloin mikäkin menetelmä kannattaa?

Päätösmatriisi ennen automaattista uudelleenohjausta

Kaikkia rikkinäisiä kuvia ei pidä ohjata automaattisesti johonkin toiseen kuvaan. Väärä ohjaus voi vielä enemmän heikentää käyttäjäkokemusta ja antaa hakukoneille vääriä signaaleja. Esimerkiksi poistetun punaisen kengän kuvaa ei kannata ohjata siniseen laukkuun. Ohjaus on järkevää vain jos on täsmällinen tai hyvin läheinen vaihtoehto.

Kysy nämä kolme:

• Tiedetäänkö uuden kuvan sijainti?
• Onko kuva kriittinen sivun merkitykselle tai konversiolle?
• Saako vanha URL ulkoista linkitystä, some-jakoja tai Google Kuvahaku -liikennettä?

Jos vastaukset ovat kyllä, 301-uudelleenohjaus sopii. Jos kuva on täysin tarpeeton eikä vastaavaa sisältöä ole, 410 Gone voi olla parempi. Jos kyseessä on pelkkä koristeikoni, paras ratkaisu on päivittää koodi tai teema-asetus. Kaikkien rikkinäisten kuvien ohjaus etusivulle on huono – se voi aiheuttaa soft 404 -laatuprobleemeja.

Rikkinäisten kuvien automaattiset uudelleenohjausmenetelmät

Apache .htaccess – 301-uudelleenohjaus

Apache- tai LiteSpeed-hostingissa .htaccess on kätevä ratkaisu. Yksittäisen ohjauksen voi tehdä muodossa Redirect 301 /wp-content/uploads/vanha-kuva.jpg /wp-content/uploads/uusi-kuva.jpg. Jos kuvat siirtyvät kokonaisina kansioina, RewriteRule toimii. Esimerkiksi vanhan /images/-kansion tiedostot voidaan ohjata /wp-content/uploads/2026/-kansioon.

Mutta tuhansien rivien lisääminen .htaccessiin voi laskea suorituskykyä. 50–200 kriittistä kuvaa onnistuu, mutta suuremmalla määrällä kannattaa käyttää palvelin- tai CDN-ohjausta. Ota aina backup ennen muutoksia ja varmista että hallintapaneeli/FTP-yhteys toimii, jos tulee 500 Internal Server Error.

Nginx – map ja rewrite

Nginx-palvelimilla massiivinen ohjauslista onnistuu hallitummin map-rakenteella. Vanha ja uusi URL listataan erilliseen tiedostoon, server-blokki lukee kartan ja tekee 301-ohjauksen, jos osuma löytyy. Tämä on tehokkaampi kuin .htaccess, koska jokainen pyyntö ei vaadi tiedoston lukua.

Nginx-ohjausta testatessa tee reload vasta syntax-testin jälkeen. Väärä puolipiste tai blokin sijainti voi kaataa koko sivuston. Hallitulla palvelimella pyydä tukea, jos et ole varma.

WordPress-lisäosat ja sovellustaso

WordPressissä Redirection, Rank Math, Yoast Premium tai mukautetut ohjauslisäosat voivat hallita rikkinäisiä media-URL:jä. Etuna on, että CSV-import onnistuu ja ohjauksia voi hallinnoida ilman syvää teknistä osaamista. Haittana on, että kaikki pyynnöt ohjataan WordPress-tasolle, mikä voi kuormittaa suurilla liikennemäärillä.

Tästä syystä lisäosapohjaiset ohjaukset sopivat pienille ja keskisuurille sivuille. Verkkokaupoissa, uutis- ja blogisivustoilla kriittiset ohjaukset kannattaa siirtää palvelin- tai CDN-tasolle. Jos haluat parantaa WordPressin suorituskykyä, linkitä verkkosivuston nopeuden optimointi -opas.

CDN ja edge-säännöt

CDN:tä käyttävillä sivuilla ohjaukset voi toteuttaa edge-tasolla. Cloudflare Rules, BunnyCDN Edge Rules tai vastaavat palvelut ohjaavat pyynnön ennen kuin se menee origin-palvelimelle. Tämä vähentää viivettä globaalissa liikenteessä ja keventää palvelimen kuormaa.

CDN:ssä pitää huomioida cache-käyttäytyminen. Jos ohjaus jää cacheen, käyttäjät voivat ohjautua väärään kohteeseen vaikka korjaus on tehty. Testaa lyhyellä cache-ajalla, julkaise säännöt pienissä erissä ja tee pysyvät vasta kun olet varmistanut tuloksen.

Vaiheittainen toteutussuunnitelma

Vaihe 1: Täysi backup ja testausympäristö

Ennen kuin muutat tiedostojärjestelmää, tietokantaa, .htaccessiä, Nginx-configia tai CDN-sääntöjä, ota backup. Ammattimainen tapa on luoda staging-ympäristö. Suoraan live-sivulla tehdyt massamuutokset, etenkin tietokanta-haku/korjaukset, voivat aiheuttaa vaikeasti palautettavia virheitä.

Vaihe 2: Rikkinäisten kuvien inventaari

Yhdistä crawlerin, lokien ja CMS:n tulokset yhteen taulukkoon. Normalisoi samat URL:t, jotka toistuvat eri lähteissä. Priorisoi lisäämällä sarakkeet: rikkinäinen kuva-URL, lähdesivu, HTTP-koodi, pyyntöjen määrä, saako sivu orgaanista liikennettä, uusi kohde-URL, käsittelytyyppi, vastuuhenkilö.

Vaihe 3: Selvitä juurisyy

Älä tee ohjausta heti jos kuva näyttää rikkinäiseltä. Onko tiedosto todella poissa, onko oikeusongelma, SSL-murhe, CDN väärä cache vai tietokannassa vanha URL? Jos tiedosto on palvelimella mutta palauttaa 403, ohjaus ei auta – korjaa tiedoston oikeudet. Jos HTTPS-sivulla kutsutaan HTTP-kuvaa, poista mixed content -ongelma.

Vaihe 4: Valitse oikea korjaus

Käytä 301-ohjausta, jos vanhalle tiedostolle on uusi vastine. Jos URL on väärin kirjoitettu sisällössä, korjaa lähdekoodi tai tietokanta. Jos kuva on poistettu eikä vaihtoehtoa ole, käytä 410 tai poista kuvan blokki sivulta. Koristekuvissa teemapäivitys riittää.

Vaihe 5: Testaa pienellä ryhmällä

Valitse ensimmäiseen julkaisuun 20–50 URL:n ryhmä. Testaa selaimella, curlilla, crawlerilla ja Search Consolen live-URL-testillä. Ohjausketjuja ei saa tulla – vanha kuva menee suoraan uuteen, 301-ohjauksen jälkeen kohde palaa 200, oikea sisältötyyppi ja tiedostokoko näkyvät.

Vaihe 6: Julkaise ja seuraa

Julkaisun jälkeen tarkista logit 24, 72 tuntia ja viikon välein. Laskeeko 404 määrä, nouseeko 301-liikenne liikaa, vaikuttaako palvelimen vasteaika? Jos kuvat ovat isoja, tarkista myös pakkaus, WebP/AVIF-käyttö ja välimuistiasetukset.

Yleiset virheet

Yleisin virhe on yrittää ratkaista kaikki ohjauksella. Joissain tapauksissa oikea ratkaisu on sisällön päivitys, ei ohjaus. Vältä näitä:

• Ohjaat kaikki rikkinäiset kuvat etusivulle tai yhteen varakuvaan.
• Teet automaattisen 301-ohjauksen kaikkiin 404-tiedostoihin analysoimatta raporttia.
• Luot ohjausketjuja: vanha.jpg → uusi.jpg → vielä-uudempi.webp.
• Unohdat alt-tekstin, otsikon ja sisällön kontekstin tiedostonimen vaihdossa.
• Luotat CDN:n cacheen ilman puhdistusta – tulos ei päivity.
• Teet massamuutoksia tietokantaan ilman backupia.
• Unohdat tarkistaa SVG:n ja WebP:n MIME-asetukset.

Lisävinkkejä suorituskykyyn ja turvallisuuteen

Rikkinäisten kuvien korjauksessa älä pelkästään vähennä 404-määrää – paranna myös mediainfrastruktuuria. Järjestä kuvat kansioihin vuosittain/kuukausittain tai sisältötyypin mukaan, jotta tulevat siirrot helpottuvat. Käytä tiedostonimissä pieniä kirjaimia, väliviivoja ja kuvailevia nimiä – kuten musta-nahkainen-lompakko-edesta.webp, ei IMG_1234.JPG.

Turvallisuuden kannalta hotlink-suojauksen kanssa pitää olla tarkkana. Liian tiukka sääntö estää Googlebot-Image:n tai some-preview-bottien pääsyn kuviin. SSL-sertifikaatti tulee konfiguroida oikein, HTTP-lähteet päivittää HTTPS:ään ja mixed content -virheet korjata. Maksu- tai jäsenyysalueilla SSL-sertifika on kriittinen peruselementti.

Hosting-resurssit ovat tärkeitä. Kuvarikkaalla sivustolla matala levy-I/O, liian pienet PHP-rajat tai väärä cache voivat hidastaa mediakuormaa ja aiheuttaa timeoutteja. Kasvavan liikenteen sivuilla kannattaa siirtyä tehokkaampaan hostingiin tai VPS:ään – se parantaa sekä nopeutta että virheiden määrää. Katso Hosting-paketit ja skaalautuvat ratkaisut.

30 minuutin tarkistuslista

• Crawlerilla käy sivusto läpi ja vie 404/403-kuva-URL:t ulos.
• Tarkista manuaalisesti 20 eniten liikennettä tuovaa sivua ja niiden kriittiset kuvat.
• Filtteröi palvelinlokeista viimeisen 7 päivän .jpg, .png, .webp 404-tapahtumat.
• Hae tietokannasta vanha domain tai kansion nimi.
• Tarkista CDN:n edge-404-raportit, jos käytössä.
• Määritä uudet kohteet 50 priorisoidulle URL:lle.
• Merkitse 301, sisällön päivitys, 410 tai poisto-toimenpide.
• Testaa stagingissa ja ota liveen pienissä erissä.

Jo lyhyt tarkistus paljastaa useimmat näkyvimmät ongelmat. Suurissa arkistoissa kannattaa tehdä tästä osa kuukausittaista teknistä ylläpitoa.

Miten mitata onnistumista?

Älä luota pelkkään silmämäärään – määritä mitattavat mittarit. Esimerkiksi päivittäisten kuvien 404-pyyntöjen tulisi laskea 10 000 → alle 1 000, tärkeimmillä sivuilla ei saa olla rikkinäisiä kuvia, ohjausketjujen määrä nollaan ja kohdekuvien statuskoodi 200. Google Search Consolessa kuvien suorituskyky paranee viiveellä, joten logi ja crawler-raportti antavat nopeamman palautteen.

Seuraa myös käyttäjäkäyttäytymistä: tuotesivuilla kuvien korjauksen jälkeen ostoskoriin lisäys, blogissa vuorovaikutuksen kesto, yrityssivuilla lomakkeiden konversio – nämä antavat signaalin korjauksen vaikutuksesta. Liitä tekninen korjaus liiketoiminnan tuloksiin, jotta SEO:n arvo näkyy tiimissä.

Usein kysytyt kysymykset

Mikä on nopein tapa löytää rikkinäiset kuvat massana?

Käytä Screaming Frogia, Sitebulbia tai vastaavaa crawleria ja vie 404, 403 ja 500-kuva-URL:t raportiksi. Suurilla sivuilla yhdistä tämä palvelinlokeihin – saat tarkemman tuloksen.

Tuleeko jokainen rikkinäinen kuva ohjata 301:llä?

Ei. 301 sopii vain jos vanhalle kuvalle on täsmällinen tai hyvin samankaltainen uusi vastine. Jos vaihtoehtoa ei ole, käytä 410, poista kuva-blokki tai päivitä lähde-URL.

Riittääkö WordPressissä pelkkä lisäosa rikkinäisten kuvien korjaukseen?

Pienillä ja keskisuurilla sivuilla ohjauslisäosat ovat käteviä. Suurella liikenteellä massiiviset kuvapyynnöt kuormittavat WordPressiä, joten kriittiset ohjaukset kannattaa siirtää palvelin- tai CDN-tasolle.

Laskevatko rikkinäiset kuvat Googlen sijoitusta?

Yksittäinen rikkinäinen kuva ei yleensä pudota sijoitusta merkittävästi. Mutta suuri määrä heikentää käyttäjäkokemusta, kuvahakuliikennettä, crawl-tehokkuutta ja sivun laatua – aiheuttaen epäsuoraa SEO-tappioita.

Milloin näen tulokset ohjauksen jälkeen?

404-logien väheneminen näkyy heti. Crawlerilla voi varmistaa saman tien. Google Kuvien ja orgaanisen hakun palautuminen riippuu crawl-syklistä – muutamasta päivästä viikkoihin.

Yhteenveto

Rikkinäisten kuvien massalöytö ja automaattinen uudelleenohjaus on oikein toteutettuna SEO:n, käyttäjäluottamuksen ja palvelimen tehokkuuden kannalta tärkeä ylläpitotoimi. Tee ensin kattava inventaari, valitse oikea toimenpide jokaiselle kuvalle, testaa pienellä ryhmällä ja seuraa logien kautta tuloksia. Jos haluat varmistaa infrastruktuurin turvallisen ja nopean toteutuksen, tutustu Hostragonsin hosting-, WordPress- ja SSL-ratkaisuihin – voit tehdä sivuston teknisestä ylläpidosta kestävämmän.