Räknare för backlänkar till en SaaS-dashboard, steg för steg
En fungerande räknare kräver en server-rutt och en liten komponent. Denna guide bygger båda, med de felstatus som de flesta första versioner glömmer bort.
AlfaLinks redaktionella team ·
Omfattning för denna guide
Vi utgår från en Node- eller Python-backend och valfritt front-end-ramverk. Varje begäran nedan träffar den dokumenterade API:et, och bas-URL:en är din varumärkes egen: alfalinks.net/api.php.
Fem steg, i den ordning vi skulle leverera dem
01
1. Skapa nyckeln och lagra den som en hemlighet
Logga in med Google på /auth/google.php, kopiera sk_-nyckeln från kontosidan och placera den i din servermiljö. Front-end ser den aldrig.
02
2. Lägg till en proxy-rutt
Exponera något som /internal/links?domain=... som validerar domänen, anropar vårt API och returnerar endast de fält som din UI använder. Validering är viktigt eftersom användare skriver in vad som helst.
03
3. Börja med den kostnadsfria åtgärden
Åtgärden overview kostar inget, så den första versionen av räknaren har ingen faktureringsrisk alls. Gå över till betalda åtgärder när en skärm behöver dem.
04
4. Rendera tre statusar
Laddar, data och otillgängligt. Otillgängligt täcker HTTP 401, HTTP 402 och ett nätverksfel, och det ska aldrig visa en nolla.
05
5. Lägg till färsghetslabeln
Vårt index uppdateras ungefär en gång i månaden. En grå rad som lyder 'länkdataloga uppdateras månatligt' förhindrar supportärendet som börjar med 'Jag lade till en länk igår'.
Proxy-rutten, i Node
Kort nog att läsas på en skärm. Cachen är en vanlig Map här; byt ut mot Redis när du kör mer än en process.
js
const cache = new Map();
const MONTH = 30 * 24 * 3600 * 1000;
app.get('/internal/links', async (req, res) => {
const domain = String(req.query.domain || '').toLowerCase().trim();
if (!/^[a-z0-9.-]+\.[a-z]{2,}$/.test(domain)) return res.status(400).json({ok:false});
const hit = cache.get(domain);
if (hit && Date.now() - hit.t < MONTH) return res.json(hit.v);
const r = await fetch(`https://alfalinks.net/api.php?action=overview&q=${domain}`);
if (!r.ok) return res.status(502).json({ok:false});
const v = await r.json();
cache.set(domain, {t: Date.now(), v});
res.json(v);
});
Att lägga till en DR-badge när räknaren fungerar
Räknaren är den lätta halvan. Badgen kräver ett extra anrop.
För en tabell med kunddomäner, skicka ett enda bulk_dr-anrop med upp till 2 000 domäner istället för ett anrop per rad. Det kostar 1 kredit oavsett radantal, och svaret mappar varje domän till sitt 0-100-värde, vilket du lagrar bredvid den cachade översikten.
Matcha domäner på den normaliserade värdnamnet. Ta bort schemat, sökvägen och ett inledande www, eller så missar hälften av dina rader sökningen och visar tomrum.
Nya användare läser sällan en konfigurationssida. De vill se om funktionen är ansträngningen värd, och en räknare för backlänkar som visar ett verkligt värde svarar på det snabbare än något formulär. Lägg värdet först. Konfiguration kommer därefter.
Eftersom den kostnadsfria översiktsåtgärden inte kräver någon nyckel, kan din första skärm visa ett värde innan användaren har konfigurerat något alls.
Vad krävs för den första renderingen?
Endast en domän och ett kostnadsfritt anrop. Tänk dig en ny användare som skriver in sin egen webbplats i onboarding och ser räknaren dyka upp inom samma sidvisning. Det enda värdet gör mer för att starta konfigurationen än en lista med steg gör, så behåll resten av konfigurationen bakom det.
Användaren ser vad de kommer att få innan någon ber om ett kort, en nyckel eller ett andra formulär. Inget på den första renderingen ska se ut som en portvakt.
Var ska konfigurationsprompten placeras?
Rätt efter värdet, inte före det. En kort rad som 'Anslut en domän för att spåra detta varje månad' passar under räknaren. Om samma prompt sitter ovanför värdet läser användarna det som en portvakt och lämnar.
Spåra vilka användare som slutför varje konfigurationssteg. En liten trakt visar var folk slutar, och en ändring i formulering flyttar ofta det värdet mer än en ny funktion skulle göra.
Testning innan lansering
Testa de olycksaliga vägarna först. De lyckade vägarna testar sig själva.
Återkalla nyckeln i staging och bekräfta att kortet visar 'otillgängligt' snarare än nolla. Töm sedan en testbalans för att utlösa en 402, och klistra in en felaktig inmatning som en domän med ett schema och en efterföljande sökväg, för att bevisa att valideraren avvisar den innan någon kredit spenderas.
En kort rökprovrutin hör hemma i CI. Ett kostnadsfritt overview-anrop på nytimes.com, kört nattligen, berättar för dig att rutten och nyckeln fortfarande fungerar.
Vem får slå upp vilken domän, och till vilken kostnad
En räknare som accepterar vilken sträng som helst är en öppen dörr till din balans. Bestäm vem som kan be om vad innan rutten går live, och skriv svaret i koden snarare än i en wikisida som ingen öppnar.
Tre frågor dyker upp varje gång: vilka domäner, vilken gräns och var nyckeln finns.
Vilka domäner ska en användare få skriva in?
Endast de som arbetsytan har anspråk på, plus alla offentliga sökningar du valt att erbjuda. Säg att en arbetsyta äger två webbplatser. Rutten kan acceptera dessa två och avvisa allt annat med ett tydligt meddelande, vilket håller en klient från att spendera krediter på domäner som inte är deras.
Värdnamnskontrollen i rutten är minimum. Den bevisar att inmatningen ser ut som en domän, inte att användaren äger den, så behåll anspråkslistan i din egen databas som en separat tabell.
Hur stoppar du att en användare tömmer balansen?
Placera en kvot per arbetsyta i din egen lagring och räkna anrop där. Balansen på vår sida är en enda förbetald pool, så den kan inte berätta vilken kund som spenderade vad. Sökningssidans noteringar täcker den offentliga sidan av samma problem. När en arbetsyta når sin gräns, returnera ett enkelt meddelande och låt cachen fortsätta svara med det den redan innehåller.
Välj gränsen från aritmetiken i noteringarna per användare, inte från en gissning, och granska den när ett plan ändras. Testa rutten med en andra arbetsyta innan du litar på kvoten.
Ska webbläsaren någonsin hålla nyckeln?
Nej. Nyckeln finns på din server, och webbläsaren anropar din rutt. Den uppdelningen är också vad som gör en kvot möjlig, eftersom varje fakturerat anrop passerar genom kod du kontrollerar. Om en nyckel någonsin visas i en levererad bundle, rotera den samma dag och kontrollera balansloggen för anrop du inte gjorde. Vissa team lagrar nyckeln i en konfigurationsfil som front-end läser vid byggtid, och den filen hamnar i buntet. Håll nyckeln borta från allt byggsteget kan se, och kontrollera de levererade filerna en gång innan varje release.
De kostnadsfria åtgärderna kan anropas från en offentlig sida utan en nyckel, och det är det enda fallet där webbläsaren kan prata direkt med API:et.
Vad räknaren ska säga, och vad den inte ska säga
Säg mindre än du vet. En räknare märkt 'backlänkar' inbjuder till frågan 'varför visar Ahrefs ett annat värde?', och det ärliga svaret är att två crawlers ser två snitt av webben.
Märka värdet med dess källa och månad istället. Något som 'Refererande domäner, AlfaLinks-index, oktober 2026' är längre, men det avslutar argumentet innan det börjar och det läser bra i ett litet kort.
Avrunda för visning. En användare som ser 12 481 på måndag och 12 481 på fredag litar mer på verktyget än en som ser svaj, och vår månatliga uppdatering ger dig den stabiliteten gratis.
HTTP-koder är de som API:et returnerar; UI-kolumnen är vårt förslag.
Signal
Betydelse
Vad användaren ser
Vad du gör
HTTP 401
Saknad eller felaktig nyckel
'Länkdataloga otillgänglig'
Sök på dig själv: deploy-bugg
HTTP 402
Krediterna tog slut
'Länkdataloga otillgänglig'
Ladda upp med USDT (TRC-20)
ok: false
Begäran avvisad
Inline-försök-igen-länk
Logga domänen och åtgärden
Timeout
Nätverksproblem
Cachade värdet om du har ett
Försök igen en gång, dra sedan tillbaka
Att hålla räknaren ärlig i support och loggar
En räknare misslyckas tyst mycket oftare än den misslyckas högt. Logga tillräckligt för att svara på frågan en kund ställer näst, och håll persondata helt borta från loggen. Korta rader vinner. En rad som svarar på ett supportärende sparar mer tid än någon varning du kunde skriva.
De flesta supporttrådar om en räknare är en av tre frågor, så planera loggen kring dem. Håll dessa tre frågor i din runbook, bredvid stegen för att rotera en nyckel.
Vad ska varje loggrad registrera?
Åtgärden, domänen, statuskoden, cacheåldern och kreditbalansen som kom tillbaka. De här fem fälten svarar på de flesta supportfrågor. Säg att en användare frågar varför deras räknare visar ett gammalt värde. Cacheåldern och indexmånaden berättar för dig om problemet är cachen eller etiketten.
Lämna API-nyckeln borta från varje rad, inklusive felspårningar. Maskera den i loggern, eftersom en läckt rad kan tömma hela kontot.
Hur vet du att räknaren är frisk varje vecka?
Övervaka tre siffror: andelen otillgängliga statusar, kreditbalansens trend och cache-hit-rate. En plötslig ökning i otillgängliga statusar pekar vanligtvis på ett nyckel- eller balansproblem. En långsam nedgång i balansen pekar vanligtvis på en cache-nyckel som är för specifik.
Varje läsning har en annan lösning, vilket är varför en enda dashboard-titel för alla tre sällan hjälper någon. Lägg de tre läsningarna på en rad i din veckonotering, med det senaste värdet och förändringen sedan föregående vecka. Siffror som läses isolerat inbjuder till gissningar, medan en kort trend håller samtalet på samma fakta.
