Teknisk baslinjerevision

Fas P2 · Steg A — Förstå
Tidsram: 2–4 timmar för en lätt genomgång, 1–2 arbetsdagar för en standardgenomgång eller 3–8 arbetsdagar för en djupgående genomgång.
Ägare: den tekniska SEO-ansvarige. Utveckling, analys, innehåll och lokaliseringsägare bidrar med bevis och accepterar åtgärder inom sina områden.

En teknisk baslinjerevision fastställer om sökmotorer kan nå, tolka och välja de webbadresser som verksamheten förväntar sig att de ska visa. Dess omfattning täcker genomsökningskontroller, HTTP-svar, indexering, kanoniska webbadresser, länkar, rendering, internationell målgruppsanpassning och säker leverans. Resultatet är ett prioriterat fyndregister med namngivna ägare och acceptanstester, inte ett poängvärde.

Varför denna fas kommer här

Att publicera på en webbplats med genomsöknings- eller indexeringsproblem förvärrar skadan. Sökmotorer upptäcker ofta ett upprepat fel över nya webbadresser snabbare än de utvärderar och belönar innehållet. En trasig kanonisk mall kan peka varje artikel någon annanstans; en robots-regel kan dölja en katalog; klientrenderad navigering kan skapa föräldralösa sidor för en icke-JavaScript-klient. Varje ny sida förstorar den påverkade uppsättningen och gör reparationen mer riskfylld.

Åtgärda grunden först. Ordningen är genomsökbarhet → indexerbarhet → innehållskvalitet → prestanda eftersom varje lager är en port. Genomsökbarhet innebär att en robot kan upptäcka och begära en webbadress; indexerbarhet innebär att den nåbara webbadressen är kvalificerad för inkludering. Först därefter bör innehållskvalitet och prestanda bedömas. En snabb sida blockerad av robots.txt kan inte konkurrera, och titeltaggar spelar ingen roll på onåbara sidor.

Denna fas förbrukar omfattningen, prioritetsresor, marknader och risker från Upptäckt och mål . Att köra den tidigare ger en genomsökning utan affärskontext. Att hoppa över den låter forskning och produktion rikta sig mot mallar som inte på ett tillförlitligt sätt kan komma in i indexet.

Indata och utdata

Indata definierar den avsedda webbplatsen, inte bara vad en robot hittar. Utdata talar om för nästa ägare vilka webbadresser som är säkra att testa och vilka som fortfarande är blockerade.

| Utdata | Baslinje för genomsökning och index | Registrerar kvalificerade webbadresser, genomsökta webbadresser, statusfördelning, webbplatskartetäckning, indexeringsförhållande, antal föräldralösa sidor och djupfördelning. | | Utdata | Beslut om blockerande beroenden | Anger om publicering får fortsätta, endast fortsätta för opåverkade mallar, eller pausa tills namngivna blockeringar klarar omtest. | | Utdata | Överlämningspaket | Ger nästa fas ett rent webbadressurval, olösta undantag, renderingsbevis och accepterade begränsningar. |

Välj revisionsdjup

Välj djup före genomsökning. Uppskattningar förutsätter att åtkomst är redo och exkluderar implementering.

Checklistan

Arbeta i ordning. En misslyckad port kan ogiltigförklara senare prover, så registrera felet och dess omfattning innan du fortsätter.

1. Bekräfta att målet är produktion

Vad du ska göra: verifiera schema, värd, robots-fil, analys-egendom, Search Console-egendom och värd för webbplatskarta. Varför det spelar roll: staging kan se rent ut medan produktion fortfarande är trasig. Hur du gör det: lös den överenskomna kanoniska värden, jämför prioriterade sidor och svarshuvuden, och registrera genomsökningsursprunget. Verktyg: webbläsare, robotkonfiguration, Search Console-väljare. Klart när: registret anger den bekräftade produktionsursprunget och egendomen, utan staging-värdnamn i utsäden eller exportfiler.

2. Testa robots.txt före genomsökning

Vad du ska göra: inspektera varje produktionsvärds /robots.txt och refererade webbplatskartor. Varför det spelar roll: en disallow-regel förhindrar genomsökning innan innehåll kan utvärderas. Hur du gör det: jämför Disallow-mönster med den avsedda inventeringen, testa matchande och icke-matchande webbadresser, och skilj på genomsökningsblock och noindex. Verktyg: rått svar och robot-testare. Klart när: robots returnerar 200, avsedda block har orsaker, indexerbara prover är tillåtna och ett oavsiktligt block utlöser ett kritiskt fynd.

3. Stäm av webbplatskartor med verkliga webbadresser

Vad du ska göra: jämför inskickade webbplatskartor med den kanoniska, indexerbara inventeringen. Varför det spelar roll: en webbplatskarta bör namnge webbadresser som webbplatsen vill ska väljas, inte omdirigeringar, fel eller dubbletter. Hur du gör det: normalisera poster, jämför antal per mall, prova sedan tillägg och utelämnanden i Webbplatskartor och indexering . Verktyg: https://app.amicited.com/reports/google-search/sitemaps-indexing och genomsökningsexportfiler. Klart när: täckning är minst 95 %, 0 poster omdirigerar eller ger fel, och varje lucka har en orsak eller ägare.

4. Mät statuskodsfördelning

Vad du ska göra: klassificera svar som 2xx, 3xx, 4xx eller 5xx. Varför det spelar roll: fel stoppar hämtning och omdirigeringar lägger till hopp. Hur du gör det: följ och rapportera omdirigeringar, segmentera per mall och jämför med Bing-genomsökning . Verktyg: https://app.amicited.com/reports/bing-webmasters/crawl, robot och övervakning. Klart när: indexerbara webbadresser returnerar 200; interna fel, loopar och kedjor är noll; och avsiktliga omdirigeringar är dokumenterade.

5. Ta bort omdirigeringskedjor och loopar

Vad du ska göra: spåra omdirigeringar till deras slutliga svar. Varför det spelar roll: hopp saktar ner upptäckt; en loop når aldrig innehåll. Hur du gör det: exportera sökvägar, uppdatera interna länkar till slutliga kanoniska webbadresser och konsolidera regler. Verktyg: omdirigeringsrapport och kontroll av svarshuvuden. Klart när: interna länkar går direkt, äldre omdirigeringar tar ett hopp och ingen loop eller kedja finns kvar.

6. Fastställ det kvalificerade indexeringsförhållandet

Vad du ska göra: jämför Googles indexstatus med medvetet kvalificerade webbadresser. Varför det spelar roll: att inkludera omdirigeringar, filter, dubbletter eller noindex-sidor gör förhållandet meningslöst. Hur du gör det: bygg den kvalificerade nämnaren, inspektera prioritetsprover i URL-inspektion , och gruppera undantag per mall. Verktyg: https://app.amicited.com/reports/google-search/url-inspection, Search Console och inventering. Klart när: minst 90 % är indexerade eller varje lucka har en grundorsaksägare; under 80 % är ett större fynd.

7. Verifiera kanonisk korrekthet

Vad du ska göra: jämför deklarerade, slutliga och Google-valda kanoniska webbadresser. En kanonisk webbadress är den föredragna versionen bland liknande webbadresser. Varför det spelar roll: en felaktig konsoliderar signaler bort från den avsedda sidan. Hur du gör det: testa unika sidas självreferenser, avsiktliga korskanoniska webbadresser och konsekvens över HTML, webbplatskartor, omdirigeringar och länkar. Verktyg: kanonisk rapport och https://app.amicited.com/reports/google-search/url-inspection. Klart när: 100 % av unika indexerbara sidor anger en absolut, 200, indexerbar kanonisk webbadress, med varje vald avvikelse förklarad.

8. Hitta dubblett- och nära-dubblettkluster

Vad du ska göra: gruppera webbadresser med identiskt eller väsentligen överlappande huvudinnehåll och samma sökändamål. Varför det spelar roll: dubbletter delar upp interna signaler och tvingar sökmotorer att välja en version som verksamheten kanske inte föredrar. Hur du gör det: jämför exakta hashvärden, normaliserad textlikhet, titlar, kanoniska webbadresser, parametrar och malländamål; välj sedan konsolidering, differentiering, noindex eller borttagning. Verktyg: robots dubblettrapporter, sidinventering och Google Search-sidor . Klart när: inget kluster innehåller mer än en oförklarad kanonisk indexerbar webbadress som tjänar samma avsikt, och varje accepterad variant har ett distinkt ändamål registrerat.

9. Hitta föräldralösa sidor och mät länkdjup

Vad du ska göra: sammanfoga robotens webbadresser med webbplatskartor, analys, Search Console, CMS-exporter och bakåtlänkar för att hitta sidor utan genomsökningsbar intern länk. Mät den kortaste klickvägen från startsidan. Varför det spelar roll: en föräldralös sida kan förekomma i en webbplatskarta men ändå få lite intern kontext eller auktoritet; överdrivet djup gör upptäckt bräcklig. Hur du gör det: jämför källor, inspektera katalogmönster i Katalogvy , och spåra navigering, brödsmulor, nav och kontextuella länkar. Verktyg: https://app.amicited.com/reports/directory och en multi-källa genomsökning. Klart när: avsett antal föräldralösa sidor är noll, prioritetssidor är inom tre klick från startsidan, andra avsedda indexerbara sidor är inom fem, och varje undantag har en avsiktlig upptäcktsväg.

10. Jämför renderad och icke-JavaScript HTML

Vad du ska göra: jämför det initiala serversvaret med sidan efter att JavaScript har körts. Varför det spelar roll: en webbläsare kan visa innehåll och länkar som en icke-JavaScript-klient aldrig får. Hur du gör det: hämta representativa sidor med inaktiverade skript, inspektera rå HTML, jämför sedan rubriker, huvudtext, länkar, kanonisk webbadress, robots-direktiv, strukturerad data och status efter rendering. Verktyg: robot i HTML- och renderade lägen plus webbläsarens utvecklingsverktyg. Klart när: det initiala svaret innehåller det primära innehållet, kanonisk webbadress, index-direktiv och genomsökningsbar navigering som behövs för att upptäcka prioritetssidor; eventuellt JavaScript-enda beroende är uttryckligen accepterat och testat över mallar.

11. Validera hreflang där tillämpligt

Vad du ska göra: verifiera annotationer som kopplar samman språkliga eller regionala motsvarigheter. Varför det spelar roll: ofullständiga eller motstridiga kluster kan få sökmotorer att ignorera målgruppsanpassning och visa fel marknadsversion. Hur du gör det: testa giltiga språkområdeskoder, absoluta kanoniska webbadresser, självreferenser, ömsesidiga returlänkar, x-default där den har en verklig fallback-roll, och indexerbarhet för varje mål. Verktyg: robots hreflang-rapport och webbadressprover. Klart när: ogiltiga koder, saknade självreferenser, saknade returer, icke-kanoniska mål, omdirigeringar och fel är alla noll. Om webbplatsen inte har lokaliserade motsvarigheter, registrera “ej tillämpligt” snarare än att uppfinna annotationer.

12. Testa paginering och genomsökningsvägar

Vad du ska göra: verifiera att flersidiga kategori- eller arkivsekvenser exponerar genomsökningsbara länkar och användbara unika webbadresser. Varför det spelar roll: oändlig scrollning eller knapp-only-laddning kan dölja djupare objekt, medan kanonikalisering av varje sida till sida ett kan ta bort distinkt inventering från upptäckt. Hur du gör det: inaktivera JavaScript, följ nästa- och numrerade länkar, inspektera status, kanonisk och robots-direktiv, och testa sista sidan och ogiltiga parametrar. Verktyg: icke-renderad genomsökning och webbläsare. Klart när: varje avsett objekt är nåbart via ankarlänkar, varje användbar sida självkanonikaliserar, ogiltiga sidnummer returnerar ett lämpligt fel snarare än en mjuk 200, och ingen sekvens skapar ett obegränsat webbadressutrymme.

13. Kontrollera mobilparitet

Vad du ska göra: jämför mobil och stationär dator leverans för innehåll, länkar, metadata, direktiv, strukturerad data och svarsstatus. Varför det spelar roll: Google utvärderar främst den mobila representationen; att dölja meningsfullt innehåll eller länkar endast på mobil ändrar vad det kan förstå. Hur du gör det: genomsök med användaragenter för stationär dator och smartphone och jämför representativa mallar, inte bara visuella skärmbilder. Verktyg: parade genomsökningar, mobil URL-inspektion och webbläsarens responsiva läge. Klart när: allt indexerbart innehåll och genomsökningsbara länkar som krävs för mening och upptäckt är likvärdiga, med noll mobil-only-block, kanoniska skillnader eller felsvar.

14. Tvinga HTTPS och ta bort blandat innehåll

Vad du ska göra: verifiera säker leverans, värd-omdirigeringar, certifikat, kanoniskt schema, interna webbadresser och resurser som laddas över HTTP. Blandat innehåll innebär att en HTTPS-sida begär en osäker resurs. Varför det spelar roll: osäkra förfrågningar kan blockeras, exponera användare och skapa inkonsekventa webbadressignaler. Hur du gör det: genomsök alla HTTP-varianter, inspektera certifikattäckning och webbläsarens säkerhetsfel, och sök efter renderade resursförfrågningar. Verktyg: robot, webbläsarens säkerhetspanel och serverkonfiguration. Klart när: varje HTTP-sida omdirigerar en gång till sin matchande HTTPS-webbadress, alla kanoniska webbadresser och interna länkar använder HTTPS, certifikat är giltiga för varje aktiv värd, och aktiva eller passiva förfrågningar om blandat innehåll är noll.

Verktyg i AmICited

Använd produktrapporter som checklistebevis, inte som en ersättning för genomsökning.

• Webbplatskartor och indexering på https://app.amicited.com/reports/google-search/sitemaps-indexing visar inskickad webbplatskartas status, varningar, fel och indexeringsåtgärder.
• URL-inspektion på https://app.amicited.com/reports/google-search/url-inspection ger Googles live-utlåtande för provtagna webbadresser och den valda kanoniska webbadressen.
• Bing-genomsökning på https://app.amicited.com/reports/bing-webmasters/crawl visar Bings robotaktivitet och webbadress-specifika problem.
• Google Search-sidor på https://app.amicited.com/reports/pages hjälper till att välja högvärdiga landningssidor och separerar sidor med synlighet från sidor som saknas i sökdata.
• Katalogvy på https://app.amicited.com/reports/directory avslöjar sektionsnivåmönster och stöder djup- och föräldralösa undersökningar.
• Datahälsa på https://app.amicited.com/features/data-health/ registrerar om anslutna bevis är tillräckligt kompletta för att stödja välgrundade beslut.

Beslutsregler

Tröskelvärden skapar fynd; de ersätter inte omdöme. Segmentera efter mall och affärsbetydelse: tio fel i kassakategorin kan vara viktigare än tusen trasiga arkivtaggar.

| Kontroll | Tröskel för fynd | Standardallvarlighetsgrad |

|—|—|—| | Robots | En avsedd indexerbar webbadress blockerad, eller robots otillgänglig/icke-200 | Kritisk när omfattningen är en prioritetsmall | | Webbplatskartetäckning | Mindre än 95 % av avsedda kanoniska indexerbara webbadresser inkluderade; någon omdirigering, 4xx, 5xx, blockerad eller icke-kanonisk post | Större; kritisk för systemisk utelämning | | Indexering | Mindre än 90 % av kvalificerade webbadresser utan förklarade undantag; mindre än 80 % är alltid ett fynd | Större; kritisk när en release orsakade nedgången | | Kanoniska webbadresser | En unik sida utan kanonisk webbadress, flera kanoniska webbadresser, ett icke-200-mål eller ett oavsiktligt mål; något systemiskt självreferensfel | Större eller kritisk beroende på omfattning | | Svar | Någon intern 4xx eller 5xx; mer än 5 % av genomsökningsbara interna webbadresser omdirigerar | Större; utbredd 5xx är kritisk | | Omdirigeringar | Någon loop eller kedja på två eller fler hopp; någon intern länk till en omdirigering | Större för loopar/kedjor, mindre för isolerade inaktuella länkar | | Dubblering | Mer än en oförklarad kanonisk indexerbar webbadress som tjänar väsentligen samma avsikt | Större när den är mallövergripande | | Föräldralösa sidor och djup | Någon avsedd föräldralös sida; prioritetswebbadress djupare än 3 klick; annan avsedd webbadress djupare än 5 | Större för prioriterade eller mallmönster | | JavaScript | Primärt innehåll, kanonisk webbadress, index-direktiv eller upptäcktslänkar saknas i initial HTML utan ett accepterat testat beroende | Kritisk för påverkade mallar | | Hreflang | Någon ogiltig kod, saknad ömsesidig länk, icke-indexerbart mål, omdirigering eller fel | Större när lokalisering tillämpas | | Paginering | Objekt onåbara utan JavaScript, alla sidor kanonikaliserade till sida ett, eller obegränsade parameterkombinationer | Större | | Mobilparitet | Saknat primärt innehåll/länk, motstridigt direktiv/kanonisk webbadress, eller mobil-only-fel | Kritisk när systemisk | | HTTPS | Ogiltigt certifikat, HTTPS-nedgradering eller aktivt blandat innehåll; någon intern HTTP-länk | Kritisk för certifikat/aktivt innehåll; större annars |

Prioritera med påverkan × ansträngning × förtroende. Poängsätt påverkan från 1–5 baserat på påverkade kvalificerade webbadresser och affärsresor. Poängsätt ansträngning från 1–5 som en enkelhetsfaktor, där 5 betyder en liten, reversibel förändring och 1 betyder ett stort riskfyllt program; registrera också den ärliga uppskattningen i timmar eller dagar. Poängsätt förtroende som 0,5 för en rimlig hypotes, 0,75 för upprepade bevis eller 1,0 för en återskapad grundorsak. Produkten ger ett ordningshjälpmedel, inte falsk precision.

Tillämpa beroendeöverstyrningen: en åtgärd som frigör annat arbete övertrumfar ett större poängvärde som inte gör det. Att ta bort ett robots-block före lansering kommer före att polera indexerade titeltaggar. På samma beroendenivå, åtgärda mallövergripande orsaker före symptom.

Leverans: det prioriterade fyndregistret

Lämna över ett gemensamt register, inte en robothämtningsexport. Använd en rad per grundorsak och bifoga webbadressprover separat.

Registret är komplett när kritiska och större fynd har ägare och uppskattningar, blockeringar har en sekvens, hypoteser är märkta och publiceringsbeslutet är explicit.

Vad går fel

En rapport på 200 punkter som ingen kan agera på

Robothämtningsexporter blandar ihop observationer med beslut. Gruppera upprepade webbadresser under mallen eller regeln som orsakar dem, tillhandahåll ett representativt prov och tilldela en ägare. Tvåhundra trasiga webbadresser som produceras av en navigeringskomponent är ett grundorsaksfynd med en mätbar omfattning, inte tvåhundra uppgifter.

Rapportera symptom istället för orsaker

“Sidan indexeras inte” är ett symptom. Orsaken kan vara en oavsiktlig kanonisk webbadress, en föräldralös mall, tunna parametervarianter, ett mobilt fel eller en JavaScript-only-länk. Ett fynd är inte redo för prioritering förrän det identifierar den kontrollerbara orsaken eller tydligt märker nästa diagnostiska test.

Granska staging av misstag

Staging kan ha olika robots-regler, autentisering, data, mallar, funktionsflaggor och värdbeteende. Registrera produktionsursprunget och Search Console-egendomen överst i varje export. Om en genomsökning måste köras mot staging för releasesäkring, märk den som en separat jämförelse och slå aldrig samman dess mätvärden med produktionsbaslinjen.

Undvik också att räkna avsiktliga undantag som förluster, behandla webbplatskarteinkludering som bevis på indexering, testa bara startsidan, eller prioritera enbart efter webbadressantal. Definiera den kvalificerade uppsättningen, segmentera efter mall och behåll acceptansbevis.

Nästa fas

Nästa fas, AI-tillgänglighet och agentberedskap , behöver ett tekniskt stabilt urval. Lämna över den avsedda indexerbara inventeringen, rena representativa webbadresser för varje prioritetsmall, rå och renderad HTML-jämförelse, robots- och svarsbevis, kanoniska beslut, kända undantag och registret över öppna fynd.

Påstå inte att webbplatsen är “tekniskt frisk”. Ange vilka mallar som klarade genomsöknings- och indexeringsportarna, vilka som fortfarande är blockerade och om publicering kan fortsätta. Nästa ägare accepterar när de kan testa AI-specifika användaragenter och extraktion utan att återupptäcka olösta sökgenomsökningsdefekter.

FAQ

Hur ofta bör vi upprepa en teknisk baslinjerevision?

Kör den före en migrering, omdesign, domänändring eller ett större publiceringsprogram, upprepa sedan påverkade kontroller efter lansering. Övervaka kontinuerligt och upprepa en standardgenomgång när mallar, navigering, rendering eller regler för kanoniska webbadresser ändras.

Vilket indexeringsförhållande bör en frisk webbplats ha?

För medvetet kvalificerade webbadresser är 90 % eller mer utgångsförväntningen, 80–90 % behöver förklaring och under 80 % är ett fynd. Exkludera omdirigeringar, dubbletter, filter och avsiktliga noindex-sidor från nämnaren.

Kan vi publicera innehåll medan tekniska åtgärder pågår?

Endast när nya webbadresser är genomsökbara, indexerbara, kanonikaliserade, internt länkade och inte påverkas av felet. Om upptäckt eller urval blockeras, pausa; nya webbadresser utökar bara städarbetet.

Behöver vi en genomsökningsrobot om Search Console är ansluten?

Ja. Search Console rapporterar vad Google observerade; en genomsökningsrobot testar den nuvarande webbplatsen och avslöjar länkar, svar, djup, kanoniska webbadresser och dubbletter. Ingen ersätter den andra.

Vem äger åtgärder som hittas i revisionen?

SEO-ansvarig äger registret och acceptanskriterierna. Utveckling äger vanligtvis server-, renderings-, omdirigerings-, kanoniska- och HTTPS-åtgärder; innehållsteam kan äga dubblerings- och länkningsfrågor. Varje punkt behöver en namngiven person.