SEO-arbeidsflyten din er for smart for sitt eget beste: Spørsmål og svar for byråer

Sammendrag

De fleste byråer taper ikke SEO-gevinster fordi de mangler ekspertise; de taper dem fordi hver klient blir til et skreddersydd vitenskapsprosjekt. Løsningen er en bevisst kjedelig, repeterbar arbeidsflyt: samme revisjonsskelett, samme operasjonssekvens og samme rapporteringsstruktur for hver klient. Denne spørsmål-og-svar-guiden går gjennom de praktiske beslutningene – hvor du starter, hvordan du prioriterer, hva du rapporterer, hva du automatiserer, og hvordan du motstår blanke taktikker. Den dekker grunnleggende elementer som robots.txt, XML-sitemaps og kanoniske tagger, og går deretter videre til brukerintensjon, Core Web Vitals og strukturerte data. Du vil lære hvorfor mer skjema ikke alltid er bedre, og hvorfor en fast prosess faktisk avdekker hver klients unike behov. Målet er å gjøre SEO-arbeidet ditt repeterbart nok til å overleve klient nummer ti.

Den mest verdifulle SEO-ressursen din er ikke en smart ny teknikk. Det er en bevisst kjedelig, repeterbar prosess som tvinger deg til å gjøre de samme grunnleggende tingene i samme rekkefølge for hver klient. Jeg har sett byråteam behandle hvert nytt oppdrag som et unikt vitenskapsprosjekt. Klienten spør: «Hva bør vi gjøre først?» og du improviserer en skreddersydd prioriteringsliste. Du diskuterer om du bør fikse hjemmesiden først eller kategorisidene. Du bruker en time på å forklare hvorfor denne klients situasjon er annerledes. Og seks måneder senere, når noen spør hvorfor du valgte disse prioriteringene, er det ingen som husker det. Løsningen er ikke mer sofistikert SEO-kunnskap. Det er en arbeidsflyt som er så konsistent at den føles kjedelig – og den kjedeligheten er akkurat det som gjør at den overlever kontakt med en tiende klient.

Denne artikkelen er et spørsmål og svar om den arbeidsflyten, skrevet for personen som må få SEO og ytelse til å fungere repeterbart for et byrå, ikke bare for et enkelt prosjekt. Spørsmålene er de som team faktisk stiller når de innser at de drukner i kundespesifikk kompleksitet. Svarene er bevisst kjedelige. Det er poenget.

Hvorfor faller SEO-prosessen min stadig fra hverandre mellom klienter?

Fordi du behandler hvert oppdrag som et problem fra bunnen av. Klient A har en ti år gammel blogg med duplisert innhold og et sitemap som ikke har blitt oppdatert siden i fjor. Klient B har en helt ny nettside med en ren gjennomgang, men ingen interne lenker mellom relaterte sider. Klient C har en rask nettside som ikke rangerer fordi ingen skrev for det folk faktisk søker etter. Hver enkelt ser ut til å kreve en unik strategi – og hver enkelt får en unik, improvisert en.

Det fungerer til du har mer enn to eller tre klienter. Da blir din egen prosess flaskehalsen. Du kan ikke huske hvorfor du prioriterte én ting for Klient A, og du kaster bort en uke på å lære deg selv konteksten på nytt. Den praktiske handlingen er å definere en fast operasjonssekvens før du i det hele tatt ser på en klients nettsted: gjennomgå, sammenlign mot en baseline, fiks gjennomsøkbarhet og indeksering, fiks hastighet, fiks innhold, mål, rapporter. Bruk samme skjelett hver gang, og bare avvik fra det når noe spesifikt blokkerer et trinn.

Forskningen på dette er nesten kjedelig i sin konsistens. Googles egen veiledning ruter fortsatt team gjennom grunnleggende elementer som gjennomsøkbarhet og indeksering før alt annet. Tekniske SEO-definisjoner over hele feltet lister de samme kjerneroppgavene – robots.txt, XML-sitemaps, kanoniske tagger – som utgangspunkt. Når alles liste ser lik ut, er det ikke listen som skiller deg. Det er om du utfører i samme rekkefølge uten dramatikk.

Så slutt å improvisere. Skriv ned skjelettet. Gjør det til en mal. Når en klient spør: «Bør vi gjøre noe annerledes fordi vi er en e-handelsnettsted?» er svaret vanligvis «Nei. Du må fortsatt være gjennomsøkbar, indekserbar, rask og relevant. La oss starte der.» De spesifikke e-handelsbekymringene – fasettnavigasjon, produktvarianter, paginering – kommer senere, etter at grunnleggende elementer er solide. En mal hindrer deg ikke i å ta tak i dem; den hindrer deg bare i å hoppe over det kjedelige for å komme dit.

Hvor begynner jeg i det hele tatt når hver klient har et forskjellig rot?

Start med de tre filene og taggene som bestemmer om noe annet du gjør betyr noe: robots.txt, XML-sitemap og kanoniske tagger. Ikke fordi de er glamorøse – de er den minst glamorøse delen av SEO – men fordi søkemotorer trenger en pålitelig vei inn. Hvis en klients robots.txt ved et uhell blokkerer hele nettstedet, eller en kanonisk tag peker hver side til hjemmesiden, vil ingen mengde innholdsarbeid eller hastighetsoptimalisering vises i rangeringene.

Et vanlig mønster: en klient bruker uker på å skrive om hjemmesideteksten, og oppdager så at en gjenværende noindex-direktiv fra en staging-server fortsatt var live i produksjon. Å fikse den ene taggen kan gjøre mer for synlighet enn hvert ord som ble skrevet om i samme periode. Et annet mønster: sitemapet lister 4000 nettadresser når nettstedet faktisk har 200 sider med innhold. Søkemotorer ser nå et omfattende, stort sett tomt nettsted, og gjennomsøkingsbudsjettet brukes på sider som ikke hører hjemme. Å rydde opp i det sitemapet lærer deg mer om kundens nettsted enn noen søkeordundersøkelse.

Et tredje mønster oppstår når en klients CMS har vært gjennom noen redesign: gamle kanoniske tagger peker til omdøpte kategorisider, så søkemotoren mottar motstridende signaler om hvilken nettadresse som representerer den «ekte» siden. Dette er ikke et subtilt problem. Det tilsvarer å sende en viktig pakke til to forskjellige adresser og håpe at én ankommer. Du må løse den kanoniske konflikten før du kan stole på noe annet du måler.

Den praktiske handlingen: kjør en rask revisjon av disse tre før du ser på noe annet. Du trenger ikke en skreddersydd metodikk for hver klient; du trenger en teknisk SEO-revisjon som alltid begynner med de samme helsesjekkene på gjennomsøkingsnivå. Hvis revisjonen din er repeterbar, blir «hvor begynner jeg» et ikke-spørsmål. Du starter der, for hver klient, uten å diskutere det.

Dette hjelper deg også med å avgrense oppdraget. Når en klient ber deg gi et tilbud på «SEO», er det første du kan si: «vi begynner med en teknisk helsesjekk som dekker robots.txt, sitemaps og kanoniske tagger, og går deretter videre til innhold og ytelse.» Den setningen fungerer for en tannlege, et programvareselskap og en logistikkleverandør. Det spiller ingen rolle hva klienten selger; veien inn til nettstedet er den samme.

Hvordan bestemmer jeg hvilken fiks som betyr mest dette kvartalet?

Dette er spørsmålet som feller de fleste byråteam, fordi svaret høres ut som det burde være skreddersydd. Men hvis du har gjort det første trinnet riktig – sikre gjennomsøkbarhet og indeksering – handler ikke neste beslutning om kundens bransje. Det handler om hvilket stadie i trakten nettstedet deres svikter på.

Tabellen nedenfor er tommelfingerregelen jeg har funnet mest nyttig:

Når kundens nettsted er...	Den repeterbare prioriteringen er...	Hvorfor det fungerer
Ikke synlig i søkeresultatene i det hele tatt	Gjennomsøkingshelse og indeksering	Ingenting annet betyr noe hvis sider ikke er i indeksen
Synlig, men rangerer ikke	On-page-relevans og brukerintensjon	Søkemotorer belønner sider som svarer på søket
Rangerer, men posisjonene synker	Core Web Vitals og sidehastighet	Google har bekreftet hastighet som en rangeringsfaktor; LCP, INP og CLS er de målbare opplevelsessignalene
Rangerer, men får ikke klikk	Strukturerte data og metabeskrivelser	Nøyaktige etiketter i søkeresultatene, inkludert rike resultater, kan løfte synligheten før en bruker klikker

Forbeholdet er at klienter sykler gjennom disse stadiene. Et nettsted kan være uindeksert, tregt og irrelevant på samme tid. Men poenget med en repeterbar prosess er at du ikke tar opp rekkefølgen til vurdering hver gang. Du har en standard: gjennomgå først, deretter indeksering, så innholdsintensjon, så hastighet, så skjema. Hvis du har en spesiell grunn til å hoppe frem, greit – men det må være bevis.

Tenk på en klient som rangerer på fjerdeplass for hovedsøkeordet sitt, men som har sunket i to måneder. Siden er gjennomsøkbar, indeksert og på budskapet. Den mest sannsynlige påvirkningen er opplevelse – sidehastighet og Core Web Vitals. Hvis hjemmesiden er tung med uoptimaliserte bilder, kan siden tape posisjon fordi Googles rangeringssystem vektlegger brukeropplevelse mer enn før. Den repeterbare handlingen er å kjøre en Core Web Vitals-vurdering før klienten begynner å skrive om innhold som allerede var relevant.

Tenk nå på en klient hvis sider er indeksert, men klikkfrekvensen er forferdelig. De rangerer på side én, men ingen klikker. I så fall kan strukturerte data – spesielt den typen som gir rike resultater som produktpris, vurdering eller FAQ – utnytte pikslene Google gir deg på en fundamentalt bedre måte. Det er en annen oppgave enn å fikse lastetid, og den fortjener sitt eget trinn i arbeidsflyten.

Dette rammeverket løser også debatten mellom «teknisk» og «innhold»-arbeid. De konkurrerer ikke. De er sekvensielle stadier i samme arbeidsflyt. Og fordi stadiene er faste, kan du bruke energien på prioritering av SEO- og ytelsesarbeid på de få beslutningene som faktisk varierer – som om du skal fikse hreflang-rotet eller duplikatkategorisidene først – i stedet for å ta stilling til hele veikartet på nytt.

Hva bør jeg faktisk ha med i en kunderapport?

Kunderapporten er der kjedelige prosesser bryter sammen. Du bruker timer på ekte arbeid – fikse robots.txt, rydde i sitemap, løse kanoniske konflikter – og så dumper du det i en 40-siders PDF med alle gjennomsøkingsfeil du fant. Klienten skummer gjennom den, blir engstelig, og det neste møtet brukes på å forklare hvorfor rapporten din ikke er en gjøremålsliste.

Den praktiske handlingen: rapporter bevisene, ikke innsatsen. Bruk én side med fire kvadranter: gjennomsøkingshelse, indeksering, hastighetssignaler og innholdshull. For hver, vis hva som endret seg, hva som ikke gjorde det, og hva du vil gjøre videre. Hvis en beregning beveget seg i riktig retning, si det på enkelt språk. Hvis den ikke gjorde det, si at du fortsatt jobber med det. Inkluder deretter en separat kort liste over de tre viktigste fiksene for neste måned.

Mikro-eksempel: i stedet for å liste 400 gjennomsøkingsfeil i rapportens brødtekst, merk dem som «ignorerbare – gamle PDF-er» eller «krever handling – ødelagte interne lenker til levende sider.» Klienten trenger ikke hele regnearket; de trenger å vite hvilke feil som betyr noe og hvilke som er bakgrunnsstøy. Den samme logikken gjelder for Core Web Vitals. Å si «LCP er nå innenfor anbefalt område» er mer nyttig enn å presentere en graf over hver beregning. Enda bedre, knytt på forretningsresultatet: «lastetiden for hjemmesiden ble forbedret, noe som samsvarer med Googles bekreftede rangeringsfaktor for hastighet.»

Et andre mikro-eksempel kommer fra en vanlig byråsvikt: å sette «vekst i indekserte sider» i rapporten mens kundens hovedproduktside fortsatt ikke er indekserbar. Rapporten bør alltid organiseres rundt kundens forretningsmål, ikke rundt beregningene du tilfeldigvis har samlet inn. Hvis kundens mål er å selge flere widgets, er «/widgets-siden er nå indekserbar» en meningsfull rad. «Vi så 12 nye sider i sitemapet» er ikke det.

Unngå å rapportere beregninger du ikke kan påvirke. Hvis byrået ditt ikke kontrollerer serveren, skaper det å rapportere serverresponstider hver måned en diskusjon uten en beslutning. Rapporten din bør alltid avsluttes med en tydelig «neste handling» for både deg og klienten – ikke et resultatkort.

Hvor mye av dette bør jeg automatisere?

Automatiser innsamlingen, ikke vurderingen. Gjennomsøkingsrapporter, oppetidssjekker og Core Web Vitals-overvåking kan alle kjøres etter en tidsplan. Det er en stor tidsbesparelse, spesielt når du administrerer flere kundenettsteder. Automatiseringen bør mate inn i den faste prosessen din, ikke erstatte den.

Men en automatisert rapport som dumper 400 gjennomsøkingsfeil i et regneark hjelper ingen. Vurderingen – hvilke feil som trenger et menneske, hvilke som er støy, og hvilke som må eskaleres – er der ekspertisen din ligger. Hvis du automatiserer innsamlingen og deretter bruker de samme triageringsreglene uke etter uke, kan du komme gjennom hvilken som helst klient på en time.

For byråkonteksten spesifikt er automatisering mest verdifull når den produserer en unntaksrapport. Sett opp en planlagt gjennomgang som bare sender deg e-post når noe ryker: en ny noindex på en pengeside, et sitemap som sluttet å løse, en økning i 404-er. På den måten går du ikke gjennom et statisk øyeblikksbilde hver uke; du venter på at noen utløser en alarm. Den kjedelige, repeterbare delen er alarmen. Den delen som fortsatt trenger et menneske, er å bestemme om du skal involvere klienten i samtalen eller fikse det stille.

Et generelt AI-skriveverktøy eller en allsidig sidegenerator kan være fristende for å produsere innhold i stor skala, men samme regel gjelder: bruk dem der de fjerner repeterende arbeid, og behold prioriteringen menneskelig. Målet er ikke å eliminere de kjedelige delene. Det er å gjøre de kjedelige delene raskere slik at du har mer tid til delene som virkelig krever resonnering – som å bestemme om du skal ta tak i taksonomioverhalingen eller foreldreløse sider først.

Vil ikke en fast prosess gjøre at jeg går glipp av det som er unikt for hver klient?

Dette er en rimelig bekymring. Hvis du bruker samme skjelett for en lokal rørlegger og et globalt SaaS-selskap, ignorerer du ikke da de åpenbare forskjellene? Svaret er nei, fordi skjelettet ikke er strategien. Det er sikkerhetsnettet.

En fast prosess betyr at du ikke går glipp av noindex-taggen på rørleggerens kontaktside fordi du var for opptatt med å tenke på lokale søkeord. Det betyr at du ikke glemmer å sjekke om SaaS-selskapets blogginnlegg er internt lenket til produktsidene deres fordi du var fokusert på skjema. De unike delene av hver klient – deres marked, deres konkurrenter, deres innholdshull – kommer i fokus først etter at du har ryddet unna grunnstøyen.

Det spesielle dukker vanligvis opp i innholdsfasen, ikke i gjennomsøkingsfasen. Når du kartlegger brukerintensjon mot kundens eksisterende sider, finner du hullene som betyr noe for den spesifikke virksomheten. En rørleggers hull kan være «ingen lokale tjenesteområdesider.» Et SaaS-selskaps hull kan være «intet prisrelatert innhold for sammenligningssøk.» Prosessen bringer disse hullene frem fordi den tvinger deg til å se på hver side som et svar på et spørsmål, i stedet for som et stykke eiendom som skal optimaliseres.

Så prosessen gjør deg ikke blind for unikhet. Den forsterker den faktisk. Du bruker mindre tid på improviserte tekniske undersøkelser og mer på den strategiske vurderingen som klienter betaler for.

Er ikke mer strukturerte data alltid bedre?

Nei. Dette er et godt sted å ta en pause og være kontrær. Strukturerte data har blitt et moteord for byråer fordi det lover rike resultater og bedre synlighet. Men å bruke skjema på hver side er ikke en repeterbar beste praksis – det er en måte å skape et støyende sett med påstander som søkemotorer kan ignorere.

Det riktige spørsmålet er ikke «kan vi legge til strukturerte data?» men «representerer denne siden noe søkemotorer kan oppsummere som et rikt resultat?» En produktside kan legitimt markere pris og tilgjengelighet. En kontaktside med en fysisk adresse kan bruke LocalBusiness. Et blogginnlegg om et emne trenger vanligvis ikke mer enn et Article-oppmerking – og ofte ikke engang det. Å legge til FAQ-skjema på en side som faktisk ikke inneholder en tydelig FAQ, vil mer sannsynlig bli ignorert eller regnet som oppmerkingsmisbruk enn å oppnå et rikt resultat.

Forskningen er konsekvent her: strukturerte data er kode som hjelper søkemotorer med å forstå innhold mer effektivt og kan føre til rikere resultater, spesielt ettersom AI-drevet søk vokser. Men det fungerer bare når det nøyaktig beskriver det som er på siden. Den repeterbare arbeidsflyten din bør inkludere et trinn som sier: «For hver sidetype, spør om et rikt resultat finnes og om siden virkelig kvalifiserer.» Det er en mye mer nyttig regel enn «legg til skjema på alt.»

Tenk på en klient med en nettbutikk. Den åpenbare fristelsen er å legge til Organization-skjema på hver side fordi «det handler om selskapet.» Men sidene som faktisk vil ha nytte av det, er produktsidene, der Product-skjema kan vise pris og tilgjengelighet. Å legge samme oppmerking til hjemmesiden, kontaktsiden og hvert blogginnlegg hjelper ikke; det gjør bare oppmerkingen vanskeligere å revidere. Den repeterbare handlingen er å kartlegge skjematyper til sidemaler, ikke til sider individuelt.

For en dypere implementeringssjekkliste, se denne veiledningen for implementering av strukturerte data. Den gir deg en repeterbar måte å bestemme side for side, i stedet for mal for mal.

Hva er den virkelige flaskehalsen i moderne SEO?

Den virkelige flaskehalsen er ikke teknisk. Det er relevans og tillit. Moderne SEO-trender legger vekt på brukerintensjon fremfor søkeordstopping, og søkemotorer belønner i økende grad innhold som er relevant, autoritativt og pålitelig (E-E-A-T). Du kan fikse alle tekniske problemer på et nettsted og likevel tape fordi innholdet ikke samsvarer med det søkere ønsker.

Et vanlig mikro-eksempel: en klient vil rangere for «beste CRM for småbedrifter», men søkeresultatene domineres av sammenligningsguider, ikke produktsider. Hvis du optimaliserer produktsiden med perfekte tittel-tagger og skjema, vil den fortsatt ikke rangere, fordi intensjonen bak søket er forskning, ikke kjøp. Den repeterbare handlingen er å kartlegge hvert målsøkeord til den faktiske søkeintensjonen før du skriver et brief. Hvis intensjonen er informativ, trenger du en guide. Hvis den er transaksjonell, trenger du en produktside.

Dette er også der E-E-A-T kommer inn, og det er det vanskeligste å systematisere. Du kan ikke forfalske autoritet med en raskere server eller en skjemablokk. Det kommer fra innholdskvalitet, forfatterekspertise og eksterne signaler som tilbakekoblinger og omtaler. Arbeidsflyten din bør inkludere et trinn for å vurdere om kundens innhold har substans til å fortjene en rangering – ikke bare den tekniske beredskapen til å bli gjennomsøkt.

I praksis betyr dette at den repeterbare prosessen din bør inkludere en innholdsrevisjon som ser på hver side som et svar på et spørsmål: Finnes denne siden? Svarer den på søket bedre enn de nåværende ti beste resultatene? Har klienten autoriteten (byline, sitater, originale data) til å støtte påstandene? Hvis ikke, er det tekniske arbeidet bortkastet. Innholdshullanalysen er der du finner de største gevinstene for de fleste klienter, og det er ofte trinnet byråer hopper over når de sitter fast i gjennomsøkingsfeil-helvete.

Hva sier jeg når en klient ber om noe trendy?

En klient leser om AI-generert innhold eller den nyeste skjemafunksjonen og vil ha det umiddelbart. Prosessen din er forsvaret ditt. Svaret er ikke «nei, det er dårlig.» Svaret er «her er hvor det passer inn i sekvensen vår.»

Hvis en klient spør om å generere 200 AI-blogginnlegg, er det målte svaret å spørre hvilken brukerintensjon disse innleggene vil tjene, hvem som vil skrive dem med nok ekspertise til å etablere E-E-A-T, og om nettstedet for øyeblikket er raskt nok til å levere dem godt. Vanligvis er den virkelige flaskehalsen noe annet.

Hvis en klient spør om en nettsted-redesign fordi «nettstedet ser gammelt ut», sier prosessen: er det nåværende nettstedet gjennomsøkbart og indekserbart? En redesign som ødelegger robots.txt eller fjerner kanoniske tagger, vil angre måneder med arbeid. Bedre å fikse det tekniske grunnlaget først, og deretter redesigne med en migreringssjekkliste.

Den repeterbare handlingen er å holde en «parkering»-liste. Når en klient foreslår noe trendy, legg det til i listen og si at det vil bli vurdert i neste kvartalsvise gjennomgang, etter at de nåværende prioriteringene er fullført. Dette avviser ikke ideen; det gir den en formell plass i arbeidsflyten. Og det forhindrer at trenden kaprer teamets tid før det kjedelige arbeidet er gjort.

Dette kan virke som en myk ferdighet snarere enn en SEO-ferdighet, men det er limet som holder prosessen intakt. Uten det vil hver klient trekke deg i en annen retning, og den repeterbare prosessen din vil kollapse under vekten av unntak.

Så hvordan ser den kjedelige prosessen ut i praksis?

Her er hele greia, kondensert:

1. Det samme revisjonsskjelettet, for hver klient. Start med robots.txt, XML-sitemap og kanoniske tagger. Deretter gjennomsøkingshelse. Så indeksering.
2. En gjentatt operasjonssekvens. Gjennomgå, indeksering, innholdsintensjon, hastighet, strukturerte data, rapport.
3. En triageringsregel for feil. Nei, jeg skal ikke fikse hver 404. Jeg fikser de som blokkerer hovednavigasjon eller peker til sider med høy verdi.
4. En én-sides kunderapport. Bevis, ikke innsats. De tre viktigste fiksene for neste måned.
5. En månedlig gjennomgangsrytme. Ikke daglig. Ikke kvartalsvis. Månedlig gir nok tid til at endringer vises i søkemotorens oppførsel.

Det siste trinnet er der mange byråer driver bort. De distribuerer fiks, og sjekker så rangeringer hver uke og får panikk. Men søkemotorer trenger tid til å gjennomsøke på nytt, indeksere på nytt og vurdere sider på nytt. En månedlig gjennomgang gir prosessen din et naturlig pusterom. Du gjør endringer, lar dem virke, og måler og justerer deretter.

En måned er også nok tid til å samle meningsfulle data. Hvis du sjekker ukentlig, ser du støy. Hvis du sjekker kvartalsvis, går du glipp av problemer. Månedlig er søtpunktet for en prosess som må fungere på tvers av flere klienter uten å fortære teamet ditt.

Hvis du mener alvor med dette, er neste steg å bygge en basismal for hastighet og ytelse som du gjenbruker på hver klient. Core Web Vitals-veiledningen er et godt sted å starte. Den går gjennom de samme tre beregningene – LCP, INP, CLS – som et fast sett med sjekker, i stedet for en ny undersøkelse hver gang.

Konklusjon

Verdien du tilfører som byrå er ikke å finne opp en ny SEO-religion for hver klient. Det er å komme med en forutsigbar, repeterbar prosess som fanger de samme landminene i samme rekkefølge, hver gang. Klienten med den gjenværende noindex-taggen og klienten med det oppblåste sitemapet får begge samme første gjennomgang. Klienten med et innholdshull får samme intensjonskartleggingsøvelse. Klienten hvis nettsted er tregt, får de samme Core Web Vitals-sjekkene.

Den repeterbarheten er det som lar deg skalere. Det er det som lar et junior teammedlem ta over en klient og vite nøyaktig hva de skal gjøre. Og det er det som lar deg si «nei» til en blank ny taktikk som ikke passer inn i prosessen, uten å føle at du går glipp av noe. Det mest sofistikerte du kan gjøre for kundene dine, er å være kjedelig med vilje – og å gjøre grunnleggende ting i samme rekkefølge, hver eneste gang.

Når en klient spør om du bør hoppe rett til en redesign eller en innholdsoppdatering, kan du svare trygt fordi du vet nøyaktig hvor det passer inn i sekvensen. Prosessen gir deg en prinsipiell måte å utsette arbeid som ennå ikke er berettiget. Og når klienten presser på for noe trendy, kan du peke på bevisene: nettstedet er ikke engang fullt indekserbart ennå, så en ny landingssidebygger vil ikke løse noe. Det kjedelige svaret er ofte det riktige.