Behöver ert företag hjälp med att implementera AI? Kontakta oss och få prisoffert här →
AI Skolan
januari 22, 2026

PostgreSQL + Gmail: robots.txt-kontroll före crawl

Rickard Andersson Partner, Nodenordic.se

Du behöver bara crawla en enda otillåten sökväg för att skapa kaos. Ett klagomål. Ett nedtagningsmejl. Eller ännu värre: ett dataset du inte kan använda på ett säkert sätt.

Det här är den typen av problem SEO-ansvariga stöter på när teamet “bara behöver datan”, och det slår mot datateam och growth-operators också. Med automatiserade robots.txt-kontroller kan du stoppa varje URL innan den går in i din crawl-pipeline och samtidigt behålla en tydlig spårbarhet.

Den här guiden tar dig igenom ett arbetsflöde som kontrollerar URL:er mot din spärrlista och robots.txt-regler, och sedan mejlar beslutet (tillåt/avslå) så att du kan agera snabbt.

Så här fungerar den här automatiseringen

Här är hela arbetsflödet du kommer att sätta upp:

n8n Workflow Template: PostgreSQL + Gmail: robots.txt-kontroll före crawl

Varför det här spelar roll: att crawla fel URL (ens en gång)

URL-validering låter tråkigt tills det sabbar något viktigt. En kollega klistrar in en lista med “mål”, din scraper kör över natten, och nästa morgon inser du att halva listan var blockerad av robots.txt eller kom från källor ni lovat att aldrig röra. Nu är ditt dataset kontaminerat, teamet diskuterar vad som måste raderas, och någon frågar om det här skapar juridisk eller compliance-risk. Det är ärligt talat här “vi ska vara försiktiga” faller. Risken är inte bara själva crawlen. Det är den efterföljande återanvändningen av data du aldrig borde ha samlat in.

Det eskalerar snabbt. Här är var det brister i riktiga arbetsflöden.

  • Folk kopierar URL:er från kalkylark, SERP:ar, Slack-trådar och RSS-flöden, och ingen vet vilka som är säkra.
  • Robots.txt-regler ändras, så en URL som var okej förra månaden kan vara förbjuden den här veckan.
  • Manuella kontroller blir inkonsekventa, särskilt när team har bråttom att leverera en rapport eller träna ett internt RAG-system.
  • Det är svårt att bevisa vad du kontrollerade, när du kontrollerade det och varför systemet tillät eller avslog URL:en.

Det du bygger: en URL-“grindvakt” som mejlar tillåt/avslå

Det här arbetsflödet fungerar som en efterlevnads-kontrollpunkt för URL:er som du placerar framför valfri crawl-, scrape- eller länkhanteringspipeline. Det startar när en URL skickas in (oftast från ett uppströms arbetsflöde, men det kan även köras schemalagt för test). Arbetsflödet normaliserar URL:en, extraherar basdomänen och kontrollerar först din PostgreSQL-tabell för “spärrade källor”. Om det finns en träff stoppar det där och returnerar ett blockerat resultat. Om den inte är spärrad slår arbetsflödet upp robots.txt i PostgreSQL; om den saknas eller är äldre än cirka 3 dagar hämtar det en ny version och sparar den. Därefter utvärderar det URL:en mot robots-reglerna med den User-Agent du valt, och kan valfritt be en AI-modell tolka knepiga robots.txt-kommentarer så att du får ett mer konservativt, mänskligt beslut. Till sist paketerar det resultatet (allow_link, allow_baseUrl, hämtningsmetadata) och skickar beslutet via Gmail.

Flödet är enkelt i praktiken. Arbetsflödet börjar med indata-tolkning och en blacklist-kontroll i databasen. Därefter använder det cachad robots.txt när det går och uppdaterar vid behov. Sist skapar det en tydlig tillåt/avslå-payload som du kan mejla, logga eller skicka vidare till en crawler som bara accepterar “tillåtna” URL:er.

Det du bygger

Förväntade resultat

Säg att ditt team validerar 200 URL:er innan en crawl. Manuellt tar även en snabb process kanske 2 minuter per URL mellan att kontrollera robots.txt, leta efter uppenbara varningsflaggor och dokumentera beslut, vilket blir runt 6 timmar. Med det här arbetsflödet kan du lägga listan i en uppströms pipeline och få tillåt/avslå-utdata ungefär på den tid det tar att hämta några robots-filer, ofta under 15 minuter för hela batchen. Det är större delen av en arbetsdag tillbaka, plus färre misstag.

Innan du börjar

  • n8n-instans (prova n8n Cloud gratis)
  • Alternativ för egen drift om du föredrar det (Hostinger fungerar bra)
  • PostgreSQL för att lagra spärrlistan och robots-cachen.
  • Gmail för att skicka tillåt/avslå-notiser till teamet.
  • API-nyckel för AI-modell (hämta den från Mistral, Groq eller Google Gemini).

Kunskapsnivå: Medel. Du kopplar upp inloggningar, justerar några inställningar (User-Agent, cache-tid) och testar med riktiga URL:er.

Vill du att någon bygger detta åt dig? Prata med en automationsexpert (gratis 15-minuters konsultation).

Steg för steg

En URL kommer in från din pipeline. Arbetsflödet kan triggas som ett underarbetsflöde (Execute Workflow Trigger) så att valfri crawler, RSS-processor eller “URL-intag”-automatisering kan anropa det. För testning finns också en schemalagd körväg som matar in en exempel-URL.

Arbetsflödet normaliserar domänen och kontrollerar din spärrlista. Ett kodsteg extraherar bas-URL:en, och sedan skapar/frågar PostgreSQL-noder blocklist-tabellen. Om domänen matchar returneras en “omedelbar avslå”-payload så att ditt uppströms arbetsflöde kan stoppa innan det gör några anrop.

Robots-regler cachelagras, uppdateras och utvärderas. Arbetsflödet frågar en robots-tabell i PostgreSQL, kontrollerar om den cachade robots.txt fortfarande är aktuell (cirka 3 dagar) och använder HTTP Request för att hämta robots.txt när den saknas eller är för gammal. En kodbaserad parser utvärderar tillåt/avslå med den User-Agent du anger, och därefter kan ett AI Agent-steg granska robotstexten (inklusive kommentarer) i kontexten av ditt angivna automationsmål.

Du får ett tydligt beslut som du kan skicka vidare vart som helst. Arbetsflödet bygger ett tillåt- eller avslå-svar, slår ihop det till en slutlig payload (inklusive hämtningstidsstämplar och flaggor som robots_fetched) och skickar sedan ett mejl via Gmail. Det gör även en upsert av robots-cachen tillbaka till PostgreSQL så att nästa kontroll går snabbare.

Du kan enkelt ändra cachefönstret (3 dagar som standard) för att uppdatera robots.txt oftare eller mer sällan utifrån dina behov. Se hela implementationsguiden nedan för anpassningsalternativ.

Steg-för-steg-guide för implementation

Steg 1: konfigurera den schemalagda triggern

Konfigurera arbetsflödets startpunkter så att compliance-kontrollerna körs enligt schema eller via ett överordnat arbetsflöde.

  1. Öppna Scheduled Run Initiator och konfigurera det schema ni vill köra (t.ex. varje timme eller dagligen).
  2. Aktivera Scheduled Run Initiator om ni vill ha tidsbaserade körningar (den är för närvarande inaktiverad).
  3. Låt Workflow Entry Trigger ligga kvar för att möjliggöra att det här arbetsflödet kan anropas av andra arbetsflöden.
  4. Bekräfta att körordningen startar från Workflow Entry TriggerFetch Base Address och Scheduled Run InitiatorTest Entry Stub.

⚠️ Vanlig fallgrop: Om Scheduled Run Initiator förblir inaktiverad körs arbetsflödet endast när det triggas av ett annat arbetsflöde via Workflow Entry Trigger.

Steg 2: anslut Postgres för blocklista och robots-data

Konfigurera databasnoderna som hanterar tabellerna för blocklista och robots-cache. Dessa noder är kritiska för compliance-logiken.

  1. Öppna Create Blocklist Table och anslut er databas. Credential Required: anslut era Postgres-credentials.
  2. Upprepa samma Postgres-credential-anslutning för alla blocklist- och robots-noder: Query Blocklist Table, Create Robots Table, Query Robots Table, Upsert Robots Table (och de inaktiverade Utility-noderna).
  3. Verifiera att blocklist-flödet körs i ordning: Fetch Base AddressCreate Blocklist TableQuery Blocklist TableBlocklist Match?Return Blocked Result.
  4. Verifiera att robots-cacheflödet körs i ordning: Create Robots TableQuery Robots TableRobots Cache Valid?.
  5. Behåll de inaktiverade utility-noderna (Utility: Remove Robots Table, Utility: List Robots Records, Utility: List Blocklist Rows, Utility: Remove Blocklist, Utility: Manual Robots Upsert, Utility: Manual Blocklist Upsert, Utility: Manual Blocklist Create, Utility: Manual Robots Create) för underhåll och felsökning.

Dessa Postgres-noder är grupperade efter funktion; se till att varje Postgres-nod delar samma databasanslutning för att undvika miljöer som inte matchar.

Steg 3: konfigurera hämtning av robots.txt och regelutvärdering

Konfigurera kedjan för hämtning av robots.txt och parsning av regler som avgör om en länk får crawl:as.

  1. Säkerställ att Robots Cache Valid? routar till Map Robots Check Inputs vid cacheträff och till Set Robots Check Data vid cachemiss.
  2. Konfigurera Set Robots Check Data för att förbereda mål-URL och user-agent-värden som behövs för robots-hämtning.
  3. Öppna Retrieve Robots File och bekräfta att den begär robots.txt-URL:en. Den här noden fortsätter vid fel och routar till Default Disallow Flag om hämtningen misslyckas.
  4. Verifiera att Retrieve Robots FileMap Robots Check InputsEvaluate Robots RulesAssess Link Permission körs i sekvens.

⚠️ Vanlig fallgrop: Om Retrieve Robots File misslyckas kommer Default Disallow Flag att styra Build Result Payload med ett deny-svar—validera felhanteringsbeteendet innan produktion.

Steg 4: konfigurera AI-länkanalys

Konfigurera val av AI-modell och extraktionspipeline som används för att analysera länkar när robots-reglerna tillåter vidare kontroller.

  1. Anslut språkmodellsnoder till Select AI Model: Mistral Chat Engine, Groq Chat Engine och Gemini Chat Engine.
  2. Credential Required: anslut era Mistral Cloud-credentials i Mistral Chat Engine.
  3. Credential Required: anslut era Groq-credentials i Groq Chat Engine.
  4. Credential Required: anslut era Google Gemini-credentials i Gemini Chat Engine.
  5. Behåll Select AI Model ansluten som språkmodellkälla för Extract Link Details (credentials läggs till i chat engine-noderna, inte i Extract Link Details).
  6. Bekräfta beslutsvägen: Assess Link PermissionExtract Link DetailsSecondary Permission CheckCompose Allow Output eller Compose Deny Output.

Om Extract Link Details ger fel använder arbetsflödet den andra utgången till Fallback False Payload. Testa den här vägen för att säkerställa att den matchar er compliance-policy.

Steg 5: konfigurera output-payload och persistens

Färdigställ svarspayloaden och persist robots-data för framtida cachekontroller.

  1. Verifiera att Compose Allow Output och Compose Deny Output båda matar in i Build Result Payload.
  2. Säkerställ att Build Result Payload skickar vidare till Upsert Robots Table för att persistera robots-resultat.
  3. Bekräfta att Upsert Robots TableFinalize Response returnerar den slutliga payloaden.
  4. Gå vid behov igenom Return Blocked Result och Fallback False Payload för att linjera deras output-struktur med Finalize Response.

Steg 6: testa och aktivera ert arbetsflöde

Kör ett fullständigt test för att validera varje väg innan ni aktiverar produktionsscheman.

  1. Använd knappen Execute Workflow för att köra arbetsflödet manuellt med start från Workflow Entry Trigger.
  2. Bekräfta att en lyckad körning visar att data rör sig genom Create Blocklist TableQuery Blocklist Table och Create Robots TableQuery Robots Table.
  3. Validera AI-outputs genom att kontrollera data som produceras av Extract Link Details och den resulterande payloaden i Finalize Response.
  4. Aktivera Scheduled Run Initiator för att starta schemalagda körningar efter lyckade tester.
🔒

Lås upp fullständig steg-för-steg-guide

Få den kompletta implementeringsguiden + nedladdningsbar mall

Felsökningstips

  • Gmail-inloggningar kan gå ut eller behöva specifika behörigheter. Om det slutar fungera, kontrollera det anslutna Google-kontot i n8n Credentials och autentisera igen om token verkar gammal.
  • Om du använder Wait-noder eller extern rendering varierar processtiderna. Öka väntetiden om nedströms noder fallerar på tomma svar.
  • Standardprompter i AI-noder är generiska. Lägg in er tonalitet tidigt, annars kommer du redigera utdata för alltid.

Snabba svar

Hur lång tid tar det att sätta upp den här automatiseringen för robots.txt-kontroller?

Cirka en timme om PostgreSQL och Gmail redan är anslutna.

Krävs kodning för de här robots.txt-kontrollerna?

Nej. Du klistrar mest in inloggningar och ändrar några fält som User-Agent och cache-tid.

Är n8n gratis att använda för det här arbetsflödet för robots.txt-kontroller?

Ja. n8n har ett gratis alternativ för egen drift och en gratis provperiod på n8n Cloud. Cloud-planer börjar på 20 USD/månad för högre volym. Du behöver också räkna med API-användning för AI-modellen, vilket oftast är några cent per batch om du inte kör väldigt stora volymer.

Var kan jag hosta n8n för att köra den här automatiseringen?

Två alternativ: n8n Cloud (hanterat, enklast att komma igång) eller egen drift på en VPS. För egen drift är Hostinger VPS prisvärd och hanterar n8n bra. Egen drift ger obegränsade körningar men kräver grundläggande serverhantering.

Kan jag anpassa det här arbetsflödet för robots.txt-kontroller för andra användningsfall?

Ja, och det bör du förmodligen. Du kan ändra User-Agent-indatan och automationGoal-texten som AI:n använder, och du kan justera logiken för “robots cache valid” om du vill uppdatera dagligen istället för var 3:e dag. Många team byter också ut Gmail mot ett ärende- eller loggmål, samtidigt som PostgreSQL-tabellerna och tillåt/avslå-payloaden behålls exakt som de är.

Varför fungerar inte min Gmail-anslutning i det här arbetsflödet?

Oftast beror det på en utgången OAuth-token eller att fel Google-konto är anslutet i n8n. Anslut Gmail-credential igen och kör sedan en enskild test-URL för att bekräfta att den kan skicka. Om det fortfarande misslyckas, kontrollera att era Google Workspace-inställningar tillåter integrationen, och håll koll på rate limits om du mejlar hundratals resultat på en gång.

Vilken volym kan det här arbetsflödet för robots.txt-kontroller hantera?

Om du kör egen drift finns ingen exekveringsgräns; det beror mest på serverstorlek och hur många nya domäner som kräver hämtning av robots.txt.

Är den här automatiseringen för robots.txt-kontroller bättre än att använda Zapier eller Make?

Ofta, ja. Det här arbetsflödet har ett riktigt databasskikt (PostgreSQL) för att cachelagra robots.txt och underhålla en spärrlista, vilket är svårt att göra snyggt i enklare “tvåstegs”-verktyg. Du får också rikare förgreningar och konservativa standardval (som “avslå om hämtning av robots misslyckas”), utan att betala extra för varje väg. En annan praktisk punkt: att köra det som ett underarbetsflöde gör det lätt att återanvända i flera crawl-pipelines. Zapier eller Make kan fortfarande vara bra för enkla notiser, men de är sällan rätt ställe att göra compliance-grindvaktslogik. Prata med en automationsexpert om du är osäker på vad som passar.

Det här arbetsflödet ger dig ett konsekvent ja/nej-beslut innan din crawler ens kör, plus en logg på varför. Sätt upp det en gång, så blir dina länk-pipelines betydligt lugnare.

Kontakta oss

Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.

×

Använd mall

Få direkt tillgång till denna n8n-arbetsflödes JSON-fil

Få prisoffert redan idag!
Få prisoffert redan idag!

Berätta vad ni behöver hjälp med så hör vi av oss inom en arbetsdag!

Få prisoffert redan idag!
Få prisoffert redan idag!

Berätta vad ni behöver hjälp med så hör vi av oss inom en arbetsdag!

Launch login modal Launch register modal