Opsætning af SEO-adgang og -sporing

Opsætning af adgang, sporing og datakilder er målingsporten for SEO-engagementet. Det beviser, at teamet kan indhente auditbeviser, skelne pålidelige data fra forurenede data og gentage baselinen senere.

Fase: P1 · Trin A — Forstå. Tidsramme: to til fem arbejdsdage, med anmodninger sendt før kickoff, hvor det er muligt. Ejer: SEO-lederen er ansvarlig; klientens projektansvarlige koordinerer invitationer, mens ansvarlige for analyse, teknik, e-handel og CRM verificerer deres systemer.

Hvorfor denne fase kommer her

Den foregående opdagelses- og målfastsættelsesfase etablerer siden, markederne, forretningsresultaterne, interessenterne og de spørgsmål, som engagementet skal besvare. Denne fase omsætter dette omfang til observerbare systemer. Hvis opdagelsesarbejdet viser, at kvalificerede demoforespørgsler er vigtige, skal sporingsopsætningen identificere den hændelse og det CRM-stadium, der repræsenterer én. Hvis opdagelsesarbejdet identificerer Storbritannien og USA som separate markeder, skal dataopsætningen bevare lande-, tidszone- og valutakontekst frem for at blande dem.

Det kommer før auditen, fordi du ikke kan auditere noget, du ikke kan måle. En crawler kan afsløre statuskoder og links, men ikke hvilke forespørgsler der mistede visninger, hvilke sider der genererede kvalificeret omsætning, eller om en konvertering blev affyldt to gange. Disse fakta findes i klientens søge-, analyse-, log- og forretningssystemer.

At starte auditen mens adgang stadig er “i gang” skaber forsinkelse på det tidspunkt, hvor førstehåndsbeviser burde bekræfte tidlige hypoteser. Analytikere kan udfylde hullet med antagelser og bevare disse antagelser i baselinen.

At køre denne fase senere ødelægger også sammenligninger. Hvis sporing repareres halvvejs, bruger “før” og “efter” forskellige målesystemer. Reparér integriteten, markér diskontinuiteten, og indfang derefter baselinen.

Inputs og outputs

Inputs fortæller ejeren, hvad der skal være tilgængeligt før verifikation. Outputs er kontrakten med den tekniske baseline-audit: den næste ejer skal ikke jagte legitimationsoplysninger eller gætte på, om et nul betyder “ingen” eller “ikke målt.”

Fase-inputs og -outputs

Adgangs- og sporings-tjeklisten

Hvert punkt nedenfor angiver, hvad der skal gøres, hvorfor det er vigtigt, hvordan det gøres, hvilket værktøj der er involveret, og hvilket bevis der afslutter det. “Anmodet” er en arbejdsgangsstatus, aldrig en færdigbetingelse.

1. Etablér det kanoniske omfang og adgangsregisteret

Hvad skal gøres: Opret én række for hver egenskab og hvert system i scope. Inkludér domæne-egenskaben og alle relevante URL-prefiks-varianter i Google Search Console; Bing Webmaster Tools; analyseværktøj; tag-administrator; CMS; hosting og CDN; rå eller bearbejdede serverlogfiler; e-handels- eller CRM-backend; samtykkeplatform; og eksisterende værktøjer til rangering, crawling eller rapportering.

Hvorfor det er vigtigt: En vag række mærket “GSC-adgang” kan skjule en manglende protokol, host, butik eller internationalt underdomæne.

Hvordan og værktøj: Start fra opdagelsens domæne- og markedskort. Notér system, konto-/egenskabsidentifikator, påkrævet rolle, administrator, tiltænkt bruger, anmodningsdato og årsag. Brug navngivne firma-konti og den mindste rettighed, der kan hente de påkrævede beviser; del ikke delte adgangskoder i registreret.

Færdig når: Hvert system i scope har en administrator og kontrollant, hver egenskab er navngivet præcist, og ingen kritisk række forbliver blot “skal identificeres.”

2. Verificér Google Search Console-egenskabsdækning

Hvad skal gøres: Bekræft den verificerede domæne-egenskab og inspicér alle operationelt relevante URL-prefiks-egenskaber.

Hvorfor det er vigtigt: Adgang til https://www.example.com/ beviser ikke synlighed for https://example.com/ eller et butiksunderdomæne. Den forkerte variant kan få sider og forespørgsler til at fremstå fraværende.

Hvordan og værktøj: I Google Search Console åbner du Performance, vælger den aftalte nylige datoperiode, henter forespørgsels- og siderækker, inspicerer indeksering og sitemaps, og noterer egenskabsidentifikatoren. Sammenlign egenskabens omfang med opdagelsens domænekort. Tilslut den matchende kilde i AmICited via Datakilder og bekræft, at Google Search-forespørgsler returnerer nylige rækker.

Færdig når: Registreret indeholder domæne-egenskaben, alle nyttige varianter, rolle, testet rapport, række-/datobevis og verifikationsdato. En rapport uden rækker undersøges frem for at blive accepteret som bevis.

3. Verificér Bing Webmaster Tools uafhængigt

Hvad skal gøres: Bekræft den korrekte side i Bing Webmaster Tools og hent søge- og crawldata.

Hvorfor det er vigtigt: At se en side på en konto beviser ikke, at den tilsluttede identitet kan læse aktuelle Bing-søge- og crawldata.

Hvordan og værktøj: Åbn den valgte side, hent en nylig søgeperformancerapport og inspicér crawl-information. Tilslut Bing i AmICiteds datakilder, åbn derefter Bing-søgeperformance og kontrollér, at klik, visninger, klikrate og gennemsnitlig position har en reel rapporteringsperiode.

Færdig når: Den forventede side er navngivet i registreret, og både udbyderens rapport og AmICited-rapporten returnerer plausible datoer eller en dokumenteret legitim ingen-data-tilstand.

4. Valider analyseværktøj og tag-administrator-indsamling

Hvad skal gøres: Test sidevisninger, samtykkeadfærd, vigtige hændelser, dobbelt affyring, henvisningsattribution og tværsite-rejser.

Hvorfor det er vigtigt: To container-installationer kan fordoble hændelser; et betalingsdomæne kan genstarte sessioner; samtykkeændringer kan skabe et niveau-skift uden relation til SEO.

Hvordan og værktøj: Brug analyseværktøjets realtids- eller debug-visning og tag-administratorens forhåndsvisningstilstand. Kør en kontrolleret session med en unik kampagnemarkør gennem én vigtig rejse. Registrér hver forventet hændelse én gang, dens parametre, kilde/medium, landingsside, sessionskontinuitet og samtykketilstand. Sammenlign tag-administrator-installation med hårdkodet tags og plugins i CMS’et.

Færdig når: Én kontrolleret handling producerer én forventet hændelse, intet kritisk tag affyres to gange, tværsite-navigation bevarer sessionen, og samtykkeadfærd matcher den godkendte politik. Gem testtidsstemplet og hændelsesbeviset.

5. Afstem konverteringer med systemet med autoritative data

Hvad skal gøres: Kortlæg analyseværktøjets konverteringer til ordrer, leads eller kvalificerede stadier i e-handelsplatformen eller CRM’et. Et system med autoritative data er den autoritative backend, der bruges til at bekræfte, at forretningshændelsen faktisk fandt sted.

Hvorfor det er vigtigt: En tak-sigeldsvisning er ikke automatisk en ordre, og en formularindsendelse er ikke automatisk et kvalificeret lead. Tavs hændelsesfejl kan vende tilsyneladende landingssideperformance på hovedet.

Hvordan og værktøj: Vælg mindst tre kendte test- eller nylige poster, hvor det er tilladt, spor deres identifikatorer og tidsstempler gennem analyseværktøjet og backend’en, og dokumentér annulleringer, refusioner, spam og offline-ændringer. Gem kun den minimale identifikator, der er nødvendig.

Færdig når: Hver primær konvertering har en ejer, udløser, backend-modstykke og afstemningsresultat. Enhver uforklarlig talforskel ud over tærsklerne nedenfor blokerer brug af konverteringsrater som baseline.

6. Bekræft CMS-, hosting-, CDN- og logadgang

Hvad skal gøres: Verificér læseadgang til publiceringskonfiguration, omdirigeringer, caching, implementeringer, edge-regler og serveranmodningslogfiler. Serverlogfiler er optegnelser, der produceres når klienter—herunder søge- og AI-crawlere—anmoder om ressourcer fra infrastrukturen.

Hvorfor det er vigtigt: Auditen kan have brug for at skelne en indholdsdefekt fra en skabelon, omdirigering, firewall eller edge-cache-regel. Crawl-analyse kan ikke vise, hvad Googlebot historisk har anmodet om, hvis logfiler bliver nødvendige senere.

Hvordan og værktøj: I hvert administrativt system åbner du én ufarlig konfigurationsskærm uden at ændre noget. For logfiler henter du en afgrænset 24-timers prøve indeholdende tidsstempel, anmodet sti, responsstatus og brugeragent; dokumentér opbevaring, tidszone og redigering. Bekræft om oprindelses- og CDN-logfiler overlapper eller repræsenterer forskellige anmodningslag.

Færdig når: Teamet kan lokalisere den aktive implementering og omdirigerings-/caching-kontroller og kan hente en parsebar logprøve—eller undtagelsesloggen registrerer, hvorfor logfiler ikke findes, den analytiske begrænsning og det godkendte alternativ.

7. Inventarisér eksisterende SEO-værktøjer og historiske brud

Hvad skal gøres: Opstil en liste over rangsporingsværktøjer, crawlere, dashboards, datalagre og tidligere agenturarbejdsområder, inklusive deres konfigurerede domæner, markeder og dataopbevaring.

Hvorfor det er vigtigt: Eksisterende værktøjer kan indeholde nyttig historik, men at kombinere uens definitioner af “synlighed,” “rangering” eller “konvertering” skaber en trend, som intet enkelt system har målt.

Hvordan og værktøj: Træk én repræsentativ rapport fra hvert værktøj. Registrér metrisk definition, land/enhed, nøgleord eller promptsæt, frekvens, ejerskab, eksportkapacitet og kendte migrerings- eller sporingsdatoer.

Færdig når: Hver bevaret kilde har en dokumenteret anvendelse og definition; redundante eller utilgængelige kilder er markeret som sådan, og kendte diskontinuiteter fremgår af baseline-noterne.

8. Tilslut og bevis AmICited-datakilder

Hvad skal gøres: Tilføj det kanoniske domæne, tilslut Google Search Console og Bing Webmaster Tools, og konfigurér alle relevante organiske, betalte og e-handelskilder.

Hvorfor det er vigtigt: Et tilsluttet badge beviser autorisation, ikke en komplet import. Rapporter bør afsløre, om kilden er aktuel, importerer, tom, fejlet eller kræver genforbindelse, før nogen fortolker dens tal.

Hvordan og værktøj: Åbn https://app.amicited.com/data-sources, tilslut de korrekte konti, læs hver statusribbon og åbn dens rapport. Vejledningen Datakilder forklarer, hvilke rapporter hver gruppe driver. For e-handelsrapportering, gennemgå Data Health , så målte indkøbsomkostninger ikke forveksles med antaget margin.

Færdig når: Hvert påkrævet kort viser den tilsigtede egenskab og en sund aktuel tilstand, og én reel downstream-rapport er blevet åbnet pr. forbindelse. Hvor en udbyder legitimt ingen data har, registrér hvorfor og hvilken rapport der beviste den tomme tilstand.

9. Konfigurér promptsporing, lande, tags og konkurrenter

Hvad skal gøres: Etablér en lille, repræsentativ baseline af køberspørgsmål, markeder og konkurrerende brands, før du skalerer biblioteket.

Hvorfor det er vigtigt: Promptresultater varierer efter motor og land. En umærket blanding af brand-, kategori- og use-case-prompter producerer et gennemsnit, ingen kan fortolke, mens de forkerte konkurrenter forvrænger strategiske sammenligninger.

Hvordan og værktøj: Åbn https://app.amicited.com/prompts. Følg vejledningerne til at tilføje prompter ved at indsætte en liste , vælge hvilke AI-motorer der skal spores og planlægge promptsporing . Tildel ét land og mindst ét formålstag til hver prompt. Åbn derefter https://app.amicited.com/competitors og administrér din liste over sporede konkurrenter , og adskil kommercielle rivaler fra udgivere, markedspladser og andre citerede kilder.

Færdig når: Hver baseline-prompt har et land, tag, udbydersæt og tidsplan; mindst én kørsel er gennemført; hver konkurrent har en grund til at være inkluderet; og ejeren kan filtrere data efter AI-model, land, tag og dato uden at producere en uforklarlig tom visning.

10. Fastfrys baselinen og underskriv overdragelsen

Hvad skal gøres: Indfang det aftalte målingsvindue, udeladelser, integritetsresultater og adgangsstatus i én dateret pakke.

Hvorfor det er vigtigt: Live-dashboards ændrer sig. Uden en fastfrosset definition kan senere teams ikke reproducere baselinen eller afgøre, om en ændring afspejler performance, konfiguration eller repareret sporing.

Hvordan og værktøj: Brug 28 komplette dage, hvor systemet understøtter det, tilføj de foregående 28 komplette dage for kontekst, og udelad delvise aktuelle dage. Eksportér eller indfang kildeoversigter, registrér tidszone/valuta, og knyt hvert tal til dets kilde og filtertilstand.

Færdig når: SEO-lederen og den ansvarlige for analyseværktøjet godkender den samme baseline-pakke, alle kritiske kontroller er grønne, og hver undtagelse har en konsekvens, workaround, ejer og deadline.

Værktøjer i AmICited

Disse produktions-trin verificerer forbindelserne og etablerer det overvågede marked. Vejledningerne indeholder interface-niveau instruktioner; denne fase registrerer, hvorfor hver handling hører til i engagementet og hvilke beviser der skal returneres.

1. Åbn https://app.amicited.com/data-sources for at tilføje og verificere forbindelser. Brug Datakilder til at fortolke grupper og synkroniseringsstatusser.
2. Åbn https://app.amicited.com/reports/google-search/queries og hent rigtige forespørgselsrækker. Brug Google Search-forespørgsler til at fortolke klik, visninger, klikrate og position.
3. Åbn https://app.amicited.com/reports/bing-webmasters og verificér den anden søgekilde. Brug Bing-søgeperformance til rapportkontrakten.
4. Åbn https://app.amicited.com/prompts for at konfigurere lande, tags, udbydere og tidsplaner. Brug Promptsporing til funktionsoversigten og akademivejledningerne til de præcise kontroller.
5. Åbn https://app.amicited.com/competitors for at gennemgå registrerede og manuelt sporede brands. Brug Konkurrentanalyse til at forstå, hvordan konkurrentsættet fodrer sammenligninger.
6. Åbn https://app.amicited.com/reports/data-health for handelsengagementer og brug Data Health til at kvalificere målt versus antaget dækning af indkøbsomkostninger. Dette erstatter ikke analyseintegritetstestene ovenfor; det besvarer et snævrere margin-kvalitetsspørgsmål.

Beslutningsregler

Tærskler er operationelle porte, ikke universelle love. De fortæller dette engagement, hvornår et tal er sikkert at baseline, hvornår det kræver en kvalifikation, og hvornår arbejdet skal stoppe.

Data- og adgangsbeslutningsregler

Nul trafik er ikke automatisk dårligt. En ny egenskab, et lav-volumen marked eller en virkelig ubenyttet kanal kan producere nul. Fejlen er et uforklarligt nul: et tal accepteret uden at kontrollere scope, indsamling, datoperiode og kildestatus.

Leverance: adgangs- og databeredskabspakken

Overdrag et regneark eller en kontrolleret tabel plus et kort baseline-notat. Adgangsregisteret skal have disse kolonner: system; konto/egenskab; scope; påkrævet rolle; adgangsindehaver; administrator; anmodningsdato; verificeringsdato; testet rapport; bevisplacering; status; udløb; og noter. Brug Ikke anmodet, Anmodet, Givet, Verificeret, Fejlet og Ikke relevant som distinkte statusser.

Data-integritetsfanen registrerer hver test, forventet og observeret adfærd, prøvevindue, resultat, ejer og saneringsdato. Baseline-notatet navngiver vinduerne, tidszone, valuta, filtre, konverteringsdefinitioner, udeladelser, diskontinuiteter og anvendte rapporter. Inkludér ikke adgangskoder, gendannelseskoder, personoplysninger eller genbrugelige adgangstokens.

Pakken er accepteret, når en anden analytiker kan reproducere rapporterne, forstå alle kvalifikationer og begynde uden at skulle anmode om kritisk adgang.

Hvad går galt

• Den forkerte Search Console-variant er verificeret. Analytikeren modtager en URL-prefiks-egenskab, ser plausible data og overser et underdomæne eller en protokol. Forhindr det ved at afstemme hver egenskab med opdagelsens domænekort og foretrække domæne-egenskaben for komplet dækning.
• Konverteringssporing har været tavst i stykker i måneder. Et dashboard viser stadig sessioner, så ingen tester forretningshændelsen. Fang det med en kontrolleret konvertering og backend-afstemning før beregning af enhver konverteringsbaseline.
• Serverlogfiler anmodes først, når crawl-analyse har brug for dem. Opbevaring har måske allerede fjernet det nyttige vindue, eller infrastrukturen kan kræve en sikkerhedsgennemgang. Identificér ejeren, felterne og opbevaringen nu, selvom log-analyse først finder sted i næste fase.
• Halvt givet adgang behandles som komplet. Et login virker, men den påkrævede egenskab, rapport, eksport eller container gør ikke. Afslut kun mod en reel rapport.
• Et forbindelsesbadge erstatter et datatjek. OAuth lykkes, mens den forkerte egenskab, udløbet scope eller en fastlåst import fodrer rapporten. Åbn downstream-rapporten og registrér dens seneste komplette dato.
• Markeder og valutaer blandes. Omsætning summeres på tværs af valutaer, eller landespecifikke prompt-svar gennemsnittes sammen. Bevar kildeenhederne og mærk hver baseline-del.
• Historiske dashboards stoles på uden definitioner. Et tidligere agenturs “synligheds”-score kan bruge forskellige nøgleord, enheder eller konkurrenter. Bevar nyttig historik, men sammenføj ikke uforlignelige serier.
• Tilladelser er bredere end opgaven kræver. Administratoradgang gives fordi det er bekvemt. Start med rapportlæsetilladelser og forhøj kun til en godkendt implementeringstrin.

Overdragelse til den tekniske baseline-audit

Den næste ejer modtager det verificerede adgangsregister, dataintegritetsrapport, AmICited-kildestatus, baseline-notat, systemejerkort, logprøve og undtagelseslog. Den tekniske baseline-audit kan derefter sammenligne crawl- og indekseringsbeviser med søgeefterspørgsel, crawler-anmodninger og forretningsresultater.

Overdragelsen er grøn, når alle kritiske systemer er verificeret, primære konverteringer består kontrollerede tests, kilde-friskhed er forstået, og baseline-filtrene kan reproduceres. En ikke-kritisk undtagelse må kun følge med fremad, når dens konsekvens, workaround, ejer og deadline er eksplicitte. Manglende serverlogfiler gør konklusioner om crawlerhistorik foreløbige. En forkert Search Console-egenskab, brudt primær konvertering eller uforklarlig dubletsporing blokerer den afhængige del af auditen.

FAQ

Ofte stillede spørgsmål