Så använder du relaterade frågor för att hitta användbara artikelmöjligheter

En fråga är användbar endast när den pekar på en specifik uppgift som läsaren vill utföra. ”Vad är X?” kan kräva en definition, ”Hur väljer jag X?” kräver jämförelsekriterier, ”Varför misslyckades X?” kräver en orsaksanalys och ”Kan jag använda X med Y?” kräver information om kompatibilitet eller begränsningar.

Skriv in spåret i en frågelogg innan du bestämmer vad som ska publiceras:

Håll formuleringen åtskild från din tolkning. ”Hur jämför jag A och B?” är belägg för en viss formulering. ”Läsarna behöver en köpguide” är en slutsats som fortfarande behöver prövas.

En funktion för relaterade frågor eller en offentlig communitytråd kan visa vilket språk människor använder. Den berättar inte vilka personerna är, om de genomförde uppgiften eller om formuleringen representerar en stor målgrupp. Se den som en hypotes om ett informationsbehov.

Kontospecifika belägg har ett annat ursprung. I dokumentationen om resultatrapporten i Search Console säger Google till exempel att rapporten kan gruppera en webbplats data efter sökfrågor och sidor samt visa klick, exponeringar, klickfrekvens och genomsnittlig position. Det gör rapporten användbar för att kontrollera om en webbplats redan får exponeringar eller klick för en grupp frågor – men bara för den egendom och period som analyseras. Den ersätter inte offentlig research när webbplatsen saknar relevanta data.

Offentliga aggregerade verktyg har också begränsningar. I sin FAQ om Google Trends-data förklarar Google att Trends använder ett anonymiserat, kategoriserat och aggregerat urval av sökningar, normaliserar resultaten för jämförelser och kan visa ”0” för termer med mycket låg volym. Google säger också att Trends är en datapunkt bland flera, inte en vetenskaplig opinionsundersökning. Därför bör en svag eller utebliven Trends-signal inte automatiskt utesluta en tydligt användbar uppgift, och en topp bör inte automatiskt motivera en sida.

Använd en enkel bedömning:

Samla inte in privat kontoinnehåll, identifiera inte enskilda frågeställare, kopiera inte känslig supporttext till ett offentligt underlag och se inte ett inloggat förslag som representativt för allmänheten.

När du verifierar efterfrågan undersöker du om en verklig läsaruppgift är tillräckligt tydlig, relevant och möjlig att besvara – inte om ett verktyg förutspår ett garanterat antal besök. Använd flera måttliga signaler:

Googles vägledning i Search Central om att skapa hjälpsamt, tillförlitligt och människocentrerat innehåll är en användbar kvalitetskontroll. Den frågar om innehållet ger omfattande och fullständig information och om läsarna lämnar sidan med tillräcklig kunskap för att nå sitt mål. Använd detta som ett redaktionellt test, inte som en rankinggaranti.

Bestäm en lägsta nivå för belägg innan du börjar skriva. För en vanlig ny sida krävs en tydlig uppgift, en relevant målgrupp, en trovärdig källa eller en direkt förstahandssignal samt ett dokumenterat innehållsgap. Höj kraven när ämnet förändras snabbt, får stora konsekvenser, är beroende av kontoåtkomst eller kräver påståenden som webbplatsen inte kan verifiera. Om uppgiften är tydlig men beläggen är svaga, lägg den på en bevakningslista i stället för att fylla en sida med spekulationer.

Relaterade frågor skiljer sig ofta språkligt trots att de efterfrågar samma resultat. Omvänt kan två frågor innehålla samma sökord men kräva olika sidor. Gruppera dem efter vad läsaren vill kunna göra när hen är klar.

Använd den här metoden i fem steg:

En praktisk grupperingstabell kan se ut så här:

Skapa inte separata sidor enbart för att ett spår börjar med ”hur”, ett annat med ”kan” och ett tredje med ”bäst”. Den avgörande frågan är om läsarens uppgift, förutsättningar och svarstruktur skiljer sig väsentligt åt.

Efter grupperingen granskar du webbplatsens tillhandahållna innehållsförteckning och jämför titlar, omfattning, målgrupp, aktualitet och vilka uppgifter sidorna löser. Om ingen innehållsförteckning finns dokumenterar du att kontrollen av dubblerat innehåll är ofullständig; påstå inte att ämnet saknas på hela webbplatsen och hitta inte på interna länkar.

Använd följande beslut:

Ett användbart underlag bör ange både vad sidan ska göra och vad den inte ska göra. Till exempel: ”Förklara hur redaktörer kan jämföra två alternativ för ett definierat användningsområde; ge inte en allmän lista över alla funktioner och hävda inte att ett alternativ alltid är bättre.” Tydliga avgränsningar hindrar ett frågespår från att växa till en allmän och repetitiv artikel.

Poängsätt varje kandidat från 0 till 2 inom fem dimensioner:

Använd totalsumman som stöd för arbetsflödet, inte som trafikprognos:

Även ett högt resultat ger inte tillstånd att publicera. Redaktörer måste kontrollera att källorna är aktuella, att användningen är tillåten, att integriteten skyddas och att produkt- och policygränser följs, samt att den färdiga artikeln faktiskt löser uppgiften.

Anta att en redaktör noterar det offentliga spåret ”Varför slutar den här konfigurationen fungera efter en uppdatering?” Spåret är inte i sig ett fullständigt artikelunderlag. Först identifierar redaktören läsaren som någon som underhåller konfigurationen och formulerar sedan uppgiften som ”identifiera felet och återställa det förväntade beteendet”. Versionen eller datumet för ändringen blir ett nödvändigt villkor.

Om webbplatsen har en verifierad egendom kontrollerar redaktören relaterade grupper av sökfrågor och sidor i Search Console, granskar godkända supportteman utan att kopiera personuppgifter och letar efter aktuell förstahandsdokumentation. Om en befintlig felsökningssida behandlar samma fel men saknar villkoret om uppdateringen väljer redaktören att uppdatera den. Om flera sidor upprepar samma granskningssteg väljer redaktören att slå ihop dem. Om lösningen kräver ett kontospecifikt ingripande hänvisar redaktören vidare. Om ingen tillförlitlig förklaring går att verifiera avstår redaktören eller väntar med frågan för vidare research. Först om uppgiften är särskiljande, möjlig att besvara och saknas i innehållsförteckningen väljer redaktören att skapa en sida.

Exemplet visar beslutsprocessen; det hävdar inte att frågan har en viss sökvolym eller att en uppdatering orsakade något specifikt fel.