Configuratie van de domain rating tool voor een blad en een cronjob
Een workflow die niemand hoeft te onthouden is beter dan een die iedereen van plan is uit te voeren. Met zes stappen ga je van een leeg blad naar een maandelijkse taak die zijn eigen kosten logt.
Redactieteam ASEOTools ·
Zes stappen, ongeveer een uur
01
Log in en kopieer de sleutel
Gebruik de Google-inlog op /auth/google.php. Het dashboard op /account.php bevat je sleutel, die begint met sk_ en wordt geleverd met $100 aan credit.
02
Maak één gratis testaanroep
Voer de overzichtactie uit zonder sleutel tegen je eigen domein. Als je JSON krijgt met ok ingesteld op true, werkt het netwerkpad.
03
Bouw de domeinlijst
Eén kolom in een blad, één domein per rij, geen https en geen paden. Tot 2.000 rijen gaan in één bulk_dr-aanvraag.
04
Roep bulk_dr aan vanuit het blad of een script
Stuur de lijst als een door komma's gescheiden GET-waarde of als een POST-lichaam. Sla het antwoord op in een tweede tabblad met een datumkolom.
05
Plan het maandelijks
Voer de taak een paar dagen na de eerste van de maand uit, nadat de maandelijkse indexverversing heeft plaatsgevonden. Een cronregel is genoeg. Controleer de uitvoer van de eerste maand handmatig tegen drie domeinen die je goed kent.
06
Log credits en alert bij laag saldo
Elk geauthenticeerd antwoord bevat _credits met de kosten en het resterende saldo. Schrijf beide naar een logregel en stuur jezelf een e-mail onder een drempelwaarde die je kiest.
De onderdelen, klaar om te plakken
Vervang door je eigen sleutel en bestandsnamen.
bash
# crontab: 06:00 on the 4th of each month
0 6 4 * * /usr/bin/curl -s -X POST \
-H "Authorization: Bearer sk_live_..." \
-d "domains=$(paste -sd, domains.txt)" \
"https://aseotools.com/api.php?action=bulk_dr" >> dr_log.jsonl
Houd de sleutel buiten het blad
Plaats de sleutel in Apps Script-eigenschappen, een omgevingsvariabele of het referentieopslag van je automatiseringstool. Iedereen met bewerktoegang tot een blad kan een sleutel die in een cel is getypt lezen, en een gelekte sleutel verbruikt je credit.
Waar deze configuratie faalt
Stilte is de gebruikelijke fout. Een cronjob die een fout geeft, ziet er hetzelfde uit als een die wel werkte.
Controleer de HTTP-code. Een 401 betekent dat de sleutel ontbreekt of fout is, en een 402 betekent dat de credit op is, dus alert op beide en los het op voordat het rapport van de volgende maand verschuldigd is.
Onthoud ook dat paginering is beperkt tot 50.000 rijen diep, en dat bulk_dr maximaal 2.000 domeinen per aanroep verwerkt. Langere lijsten vereisen chunking, wat één extra lus is en één credit per chunk kost.
Test eerst handmatig. Voer de cronregel uit in een terminal, lees het logboek en controleer of het saldo precies met de verwachte kosten daalde. Bekijk vervolgens hoe de cijfers vergelijken met een suite-plan en beslis hoe vaak je het moet uitvoeren.
Versieer je domeinlijst. Bewaar het bestand in een repository of een gedeelde schijf met geschiedenis, zodat je wanneer een nummer in maart verandert kunt zien of de lijst ook is gewijzigd. Voeg een notitiekolom toe voor domeinen die je bewust hebt toegevoegd, zoals een nieuwe concurrent of een klant die in die maand is toegetreden. Behandel de lijst als data met een eigenaar, want de goedkoopste bug is die je opmerkt in een diff.
Een lange lijst opsplitsen in chunks
Lange lijsten zijn waar een nette configuratie zijn limiet bereikt. Een bulkaanroep verwerkt maximaal 2.000 domeinen, dus een lijst van 5.000 vereist drie aanvragen, en de splitsing moet plaatsvinden voordat de eerste aanroep wordt gedaan.
Splits op basis van een stabiele regel, zoals de gesorteerde volgorde van de domeinkolom. Op die manier komt hetzelfde domein elke maand in dezelfde chunk terecht, en blijft de vergelijking geldig.
Lijsten met meer dan 2.000 rijen
Schrijf elke chunk als een apart blok naar het blad, met het chunknummer in de eerste kolom. Een mislukte chunk is dan eenvoudig te vinden.
Elke chunk kost één credit, dus een lijst van 5.000 rijen komt neer op 3 credits per run, wat $0,0003 is. Een domain rating tool is alleen zo nuttig als de lijst die hij leest, dus houd die lijst netjes.
Als de lijst groeit tot meer dan 5.000 rijen, herzie dan de indeling van het blad zelf. Een tabblad per maand houdt elke run leesbaar wanneer de rijen oplopen.
Een mislukte chunk opnieuw uitvoeren
Als chunk twee een fout retourneert, voer dan alleen chunk twee opnieuw uit. De hele lijst opnieuw uitvoeren zou credit verbruiken voor rijen die al zijn teruggekomen.
Log het chunknummer met de statuscode, zodat de heruitvoering één regel in het logboek is, in plaats van een zoektocht door het blad.
De chunk-map stabiel houden
Als de domeinlijst van volgorde verandert, verplaatsen de chunks zich en breekt de maand-op-maand-vergelijking. Sorteer de lijst voordat je hem opsplits, elke keer opnieuw.
Sla de chunk-map op naast de lijst.
Een eenvoudige test: kies een willekeurige chunk en tel het aantal rijen ervan opnieuw tegen de lijst. Een mismatch betekent dat de map is afgedreven, en dat is goedkoper om in het blad te vinden dan in het rapport.
Test één chunk handmatig en lees het volledige antwoord
Bevestig dat het saldo precies met de verwachte credits daalde
Controleer de statuscode voor elke chunk, niet alleen voor de eerste
Vergelijk drie domeinen die je goed kent met cijfers die je al vertrouwt
Stel een logboekbestandspad in en bepaal wie het elke maand leest
Schrijf de naam van de eigenaar bovenaan het blad
Wat een nuttige maandelijkse logregel bevat
Een logboek dat alleen ok zegt, is niet veel logboek. Elke run moet één regel schrijven die een vermoeide persoon in tien seconden kan lezen: de datum, de chunk, de status, de verbruikte credits en het saldo na de aanroep.
Voorbeeld: een regel die chunk vier laat zien, status 200, één credit verbruikt en het resterende saldo na de aanroep beantwoordt de meeste vragen een maand later zonder het antwoord te openen.
Velden die het loggen waard zijn
Log de datum, de lijstnaam, het chunknummer, de statuscode, de in rekening gebrachte credits en het saldo na de aanroep. Die zes velden dekken de meeste vragen die een maand later spelen.
Voeg alleen een vrije-tekstnotitie toe wanneer iemand iets handmatig heeft gewijzigd.
Alerts die niet met de wolf komen aanrennen
Alert direct bij een 401 of een 402, omdat beide betekenen dat de taak zijn werk niet kan doen. Een waarschuwing bij laag saldo moet de door jou gekozen drempelwaarde gebruiken, zodat deze één keer afgaat en aangeeft wat je als volgende moet doen.
Stuur één alert per run, niet één per rij, anders wordt de inbox ruis.
Configuratievragen
Werkt een Google Sheet als client?
Ja. De API is eenvoudige REST met open CORS en JSON-antwoorden, dus Apps Script of een IMPORTDATA-achtige aanroep kan het bereiken. Houd de sleutel in scripteigenschappen in plaats van in een cel die samenwerkers kunnen lezen.
Kan ik dit gebruiken met n8n of Make?
Ja, via een normale HTTP-aanvraagnode. Geef de sleutel door als een Authorization Bearer-header, parse het JSON-antwoord en schrijf het _credits-veld naar je logboek zodat je de uitgaven per run kunt zien.
Waarom toont het logboek een hogere kosten dan ik verwachtte voor deze domain rating tool?
Tel de aanroepen, niet alleen de lijstgrootte. Een chunk per run, een retry of een testaanroep voegt elk zijn kosten toe, en het _credits-veld in elk antwoord geeft de exacte figuur voor die aanroep.
Moet de sleutel in de cronregel zelf staan?
Het is eenvoudiger, maar iedereen die de crontab kan lezen, kan de sleutel lezen. Laad deze uit een bestand met beperkte rechten of uit een omgevingsvariabele die voor de taak is ingesteld, en houd het buiten gedeelde logs.
Wie merkt op wanneer de taak vastloopt
Een maandelijkse taak draait zonder dat iemand ernaar kijkt. Dat is het punt van automatiseren, en dat is ook waarom een fout weken onopgemerkt kan blijven.
Noem de persoon die het logboek leest en de persoon die de taak oplost. Twee namen zijn beter dan één. Vakanties gebeuren. De runbook legt uit hoe je de lijst in de eerste plaats kiest.
Tijd besteed aan configuratie versus onderhoud
De eerste run kost de meeste van het uur, omdat de sleutel, het blad en de testaanroep allemaal aandacht nodig hebben. Daarna zou de routine elke maand slechts een blik nodig hebben, geen herbouw.
Als het onderhoud toeneemt, is de lijst meestal de oorzaak. Een lijst die elke week verandert, heeft een eigenaar, een versie en een regel voor toevoegingen nodig.
Een fout zichtbaar maken
Een ontbrekende rij in de uitvoer is makkelijker te zien dan een stille fout. Vergelijk het aantal rijen met de lengte van de lijst bij elke run en schrijf een waarschuwing wanneer ze verschillen.
Houd die waarschuwing in hetzelfde logboekbestand, zodat de persoon die het logboek leest het als eerste ziet.
Plannen rond de indexverversing
De index ververst ongeveer één keer per maand, dus een run op de eerste dag van de maand kan cijfers uit de vorige build lezen. Een paar dagen later uitvoeren, zoals de bovenstaande stappen suggereren, geeft de verversing de tijd om te landen.
Kies elke maand dezelfde dag zodat de reeks vergelijkbaar blijft, en schrijf die dag in een opmerking op de cronregel.
Wanneer stoppen met automatiseren
Een taak die één keer per kwartaal draait, rechtvaardigt misschien geen cronregel. Een blad en een kalenderherinnering kunnen genoeg zijn, en een halfgeautomatiseerde routine is slechter dan een duidelijke handmatige.
Automatiseer pas wanneer dezelfde stappen meerdere cycli achter elkaar schoon zijn uitgevoerd.
