DEV Community: Stepan Nikonov

How to Deduplicate Leads in n8n Before They Reach Your CRM

Stepan Nikonov — Tue, 18 Aug 2026 16:07:37 +0000

Normalize each lead, compare the right identity keys, update an existing contact when the match is safe, and send ambiguous records to review instead of polluting the CRM.

Lead deduplication is not one filter. A reliable n8n workflow separates repeated submissions from repeated people, normalizes the values used for comparison, checks persistent records, and lets the CRM enforce uniqueness whenever the destination supports it.

Short answer: use a stable source ID to stop the same event twice, normalized email or phone to find an existing person, and a CRM-native create/update or upsert operation for the final write. Never auto-merge two records on name alone.

First identify which duplicate you are stopping

Duplicate type	Example	Best first control
Repeated item in one execution	A spreadsheet import contains the same row twice	Remove Duplicates on the current input
Repeated source event	A webhook or retry delivers submission `lead_8472` again	Persistent check on the stable source ID
Same person from another source	The same customer submits a website form after a Facebook form	Normalized identity lookup in the CRM
Conflicting identity	Email matches one contact while phone matches another	Human review, not an automatic merge

The Facebook Lead Ads workflow uses a Meta lead ID to stop one submission from creating several sheet rows. This guide goes further by handling several sources and an existing CRM full of contacts.

Choose identity keys before building nodes

Key	What it proves	Rule
Source record or submission ID	The same source event or object	Strongest key for replay protection, but not for matching a person across systems
Normalized email	Usually the same inbox	Good exact contact key when present and valid
Normalized phone	Usually the same reachable number	Useful with country context; shared business or family numbers need caution
Name	Only that the text looks similar	Use as review context, never as the only automatic merge key

Decide field ownership too. A new form may fill a missing phone number, but it should not silently replace a verified CRM email, owner, lifecycle stage, or consent value. Deduplication decides which record to use. A separate update policy decides which fields may change.

A practical n8n workflow shape

Lead trigger
  → Edit Fields: normalize keys
  → Remove Duplicates: current batch or repeated event
  → Data Table or CRM: persistent lookup
  → Switch: new / exact match / conflict
  → CRM: create or update
  → Data Table: record source key and CRM ID
  → Alert only when review or failure is needed

Start with one lead source and one CRM. The same pattern can later sit behind Facebook forms, website forms, imports, chat, and email without giving each source a different duplicate policy.

Step 1: normalize the fields once

Add an Edit Fields node immediately after the trigger. Preserve the original values for audit and display, then create separate comparison fields:

source_key
email_original
email_key
phone_original
phone_key
full_name
source
received_at

For an email comparison key, an n8n expression can trim whitespace and use lowercase:

{{ ($json.email || '').trim().toLowerCase() }}

Build source_key from the provider and its stable ID, for example facebook:lead_8472 or website:submission_193. Do not concatenate name and timestamp and call that stable.

For phone numbers, remove presentation punctuation and normalize with the correct country context. Simply stripping every non-digit character can make two different international numbers look deceptively similar.

Step 2: use Remove Duplicates for the narrow job it does well

For duplicate rows arriving together, configure Remove Duplicates → Remove Items Repeated Within Current Input, choose Selected Fields, and compare source_key. This is ideal for imports and batched records.

For the same source event arriving in later executions, the node also supports Remove Items Processed in Previous Executions. Use Value Is New and deduplicate on source_key. Scope can be the individual node or the workflow. Current n8n documentation says the default history size is 10,000 items.

Do not treat that history as your customer database. The history has a configured size, can be cleared, and only knows the values you gave that node or workflow. It cannot decide that two different source IDs belong to the same person.

Step 3: add a persistent lookup

Option A: n8n Data Table for a small lead ledger

A Data Table is a practical first version for a small business that does not yet have strong CRM lookup rules. Create a table such as lead_identity with these columns:

source_key
email_key
phone_key
crm_id
status
first_seen_at
last_seen_at

The current Data Table node can check whether a row exists, get rows, insert, update, and upsert using conditions. Search the strongest available key before the CRM write, then upsert the final crm_id only after the CRM succeeds.

n8n describes Data Tables as light to moderate storage. The default total limit across all tables in an instance is 50 MB, although self-hosted instances can change it. That makes a table useful as a compact identity ledger, not a replacement for a mature CRM or warehouse.

Option B: search the CRM directly

If the CRM already owns the customer record, query it first. The current n8n HubSpot node, for example, supports searching contacts and a Create/Update a contact operation. Other CRM nodes expose different operations, so check the destination's exact contract before copying a pattern.

Prefer a CRM record ID or custom unique source ID once you have one. HubSpot's current Contacts API can retrieve by email and batch upsert by email or a custom unique identifier. It also notes that partial upserts are not supported when email is the identifier, which is one reason not to send an incomplete payload blindly.

Step 4: route new, matched, and conflicting leads

Use a Switch node with three explicit outcomes:

No match: create the contact, then save the returned CRM ID with the source key.
One safe match: update only allowed fields and attach the new source or submission as an activity.
Conflict: do not create or merge automatically. Send the candidate record IDs and incoming values to an owner for review.

A conflict includes more than two search results. It also includes email matching contact A while phone matches contact B, or a source ID pointing to a record whose verified identity now disagrees with the payload. Preserve the lead and notify someone. Silent deletion is not deduplication.

Step 5: make the CRM write duplicate-safe

Use the destination's create/update or upsert operation when it can enforce a unique identifier. This is stronger than a separate search followed by create because two n8n executions can run at nearly the same time, both see no result, and both create a contact before either writes the ledger.

If the CRM cannot upsert atomically, use its unique-field constraint, serialize the critical section, or put the identity key in a database with a unique index. Catch the destination's duplicate response and retrieve the existing record instead of treating every conflict as an unrecoverable failure.

After a successful write, upsert the source key and returned CRM ID into the Data Table. Then send notifications or start follow-up. This ordering prevents the team from receiving a success alert for a contact that never reached the CRM.

Test with a small duplicate matrix

Test	Expected result
Same source ID delivered twice	One CRM record; the replay is stopped or attached without another create
Different source ID, same normalized email	Existing contact updated according to field rules
Same phone with different formatting	One candidate after country-aware normalization
Same name, different email and phone	New record or manual review, never an automatic merge by name
Email matches A, phone matches B	Conflict branch with both record IDs visible
Two identical executions started together	One destination record because the final write enforces uniqueness
CRM write fails	No success alert and no ledger row marked complete

Common mistakes

Comparing raw email or phone values without normalization.
Using name as a unique key.
Assuming a source submission ID identifies the same person across every channel.
Dropping duplicates without recording the new campaign, form, message, or timestamp.
Overwriting verified CRM fields with blank or lower-confidence form values.
Running search and create concurrently without a destination uniqueness control.
Using a temporary in-workflow list as the only long-term duplicate barrier.

Useful questions before publishing

Can Remove Duplicates replace a CRM lookup?

No. It is useful for repeated items and remembered values, but it does not understand an existing customer record, alternate email, shared phone, merge history, or field ownership.

Should email or phone be the main key?

Use the strongest verified identifier your process reliably collects. Email is often the simplest contact key. Phone can be useful after country-aware normalization. Keep a stable source ID for replay protection even when email is the CRM match key.

Should a duplicate lead be discarded?

Usually not. The person may have submitted a new service request or responded to a different campaign. Reuse the contact record, then preserve the new submission as an activity, note, deal, or source event.

Privacy and operating rules

Store only the identity fields needed for matching and follow-up.
Restrict Data Tables, execution data, and CRM credentials to the responsible project members.
Set retention rules for rejected and ambiguous records.
Do not place full lead payloads in chat alerts when a secure CRM link is enough.
Document who resolves conflicts and how quickly the review queue should be checked.

For retries around state-changing API calls, use the separate duplicate-safe n8n API retry pattern. That guide protects one operation from being repeated. This guide protects CRM identity across leads and sources.

Sources checked

Originally published on FloxoLab.

How to Back Up and Restore Self-Hosted n8n

Stepan Nikonov — Sat, 15 Aug 2026 21:21:07 +0000

A workflow export is not a full instance backup. Protect the database, encryption key, deployment configuration, and binary storage, then prove that they work together on an isolated restore.

A recoverable self-hosted n8n backup has four core parts: the database, the original encryption key, the deployment configuration and secrets, and any binary-data storage your executions still need.

Back up the persistent .n8n volume even when PostgreSQL stores the main database. n8n documents that this directory can still contain the encryption key, logs, and source-control assets.

What must be in the backup

Asset	Why it matters	Typical location
Database	Workflows, encrypted credentials, users, projects, settings, and retained execution data	`~/.n8n/database.sqlite` or PostgreSQL
Encryption key	Decrypts credentials stored in the database	`~/.n8n` settings or `N8N_ENCRYPTION_KEY`
Deployment config	Restores database connection, public URL, proxy, timezone, pruning, and execution behavior	Compose file, environment settings, secret references, proxy config
Binary data	Restores retained files handled by executions	Persistent filesystem, database, or configured external store
Custom and community nodes	Allows restored workflows to load the same node types and versions	Package list, custom-node directory, container image, or build manifest

Do not put the raw encryption key, database password, OAuth secrets, or an unredacted environment file in a public repository. Keep a sanitized deployment definition in version control and protect the actual secrets in a restricted password manager, secret store, or encrypted backup.

Choose the database path first

Self-hosted n8n uses SQLite by default. The database file is ~/.n8n/database.sqlite. PostgreSQL is the other supported database option. The backup and restore commands must match the database your instance actually uses.

SQLite: capture a consistent persistent volume

The simplest small-instance method is a short maintenance window: stop the n8n application, archive its persistent volume, then start it again. Stopping writes avoids treating an arbitrary live file copy as a consistent database backup.

docker compose stop n8n
docker run --rm \
  -v n8n_data:/data:ro \
  -v "$PWD/backups:/backup" \
  alpine tar czf /backup/n8n-data-2026-07-18.tgz -C /data .
docker compose start n8n

Replace the service and volume names with the names in your deployment. If downtime is not acceptable, use a storage snapshot or SQLite-aware backup process that guarantees a consistent result. Do not assume that copying database.sqlite while executions are writing to it is safe.

PostgreSQL: use a database dump

PostgreSQL's official documentation recommends pg_dump for logical backups. A custom-format dump works with pg_restore and is practical for restoring into a fresh database:

pg_dump --format=custom --file=n8n-2026-07-18.dump n8n

The dump does not replace the n8n persistent volume or explicit encryption key. It also does not capture the Compose file, environment settings, proxy configuration, or filesystem binary data. Store those as separate parts of the same dated backup set.

Add native n8n exports as a second recovery layer

n8n's Server CLI can export all database entity types. Its documentation positions this tooling for backups and migrations, including moves between SQLite and PostgreSQL. Execution-history data tables are excluded by default because they can be large.

docker exec -u node n8n \
  n8n export:entities \
  --outputDir=/home/node/.n8n/cli-backup

Workflow and credential exports are also useful for selective recovery or versioned copies:

n8n export:workflow --backup --output=backups/workflows/
n8n export:credentials --backup --output=backups/credentials/

Avoid decrypted credential exports for routine backups. n8n supports a --decrypted flag for migrations to a different secret key, but the resulting files expose every sensitive value in plain text.

A safe restore runbook

First restore into an isolated instance with no production webhooks, schedules, email sends, payment calls, or CRM writes. The first recovery test should never overwrite the only production copy.

Record the target. Use the same n8n version first, the same database type, and compatible custom-node versions.
Create fresh infrastructure. Prepare a new Docker volume or empty PostgreSQL database rather than clearing production.
Restore the original encryption key. Put the protected N8N_ENCRYPTION_KEY or original n8n settings in place before n8n reads the restored credentials.
Restore the database. Extract the stopped SQLite volume archive into the new volume, or restore the PostgreSQL dump into the new database.
Restore the surrounding state. Reapply deployment settings, binary storage, custom nodes, public URL settings, and reverse-proxy configuration.
Start without production traffic. Keep DNS, proxy routing, and outbound side effects isolated while checking startup and migration logs.
Verify the application. Confirm login, projects, workflows, credentials, node availability, required execution history, and retained binary files.
Run one safe test. Use test credentials or a non-destructive workflow and confirm that a credential can decrypt and authenticate.
Publish deliberately. Review which workflows should be published before switching traffic.

Restore SQLite into a new volume

docker volume create n8n_restore_data
docker run --rm \
  -v n8n_restore_data:/data \
  -v "$PWD/backups:/backup:ro" \
  alpine tar xzf /backup/n8n-data-2026-07-18.tgz -C /data

Point a separate restore Compose file at n8n_restore_data. Do not bind it to the production hostname or webhook route until the checklist passes.

Restore PostgreSQL into a fresh database

createdb n8n_restore
pg_restore --dbname=n8n_restore n8n-2026-07-18.dump

Real deployments may need explicit host, user, role, ownership, TLS, and schema options. Test the exact command your operator will use and document it without embedding the password.

Restore-test checklist

The backup job has a timestamp, size, success state, and failure alert.
The database and encryption key come from the same recoverable setup.
The restore starts on a separate hostname, volume, and database.
Credential nodes open without decryption errors and one test authentication succeeds.
Required custom or community nodes load at the expected versions.
Published workflows, schedules, and webhook paths are reviewed before traffic moves.
Required retained binary files can be opened.
The restore time and missing manual steps are recorded for the next test.

Common backup failures

Mistake	What breaks during recovery
Only exporting workflow JSON	The complete instance state is not restored
Database without the original key	Credentials remain encrypted but cannot be used
Copying a live SQLite file casually	The backup may not represent one consistent database state
Skipping binary storage	Retained documents or images may be missing
Restoring straight over production	A bad archive or wrong config can remove the working recovery path
Never testing the restore	Missing keys, permissions, packages, and manual steps appear during the incident

Sources

Originally published on FloxoLab.

Retry Failed n8n API Requests Without Creating Duplicates

Stepan Nikonov — Thu, 13 Aug 2026 04:15:40 +0000

A timeout can hide a successful order, lead, payment, or message. The safe retry pattern uses one stable operation key, retries only temporary failures, and records the confirmed result.

Turning on Retry On Fail in n8n does not prevent duplicates by itself. It repeats the failed node. If an API completed the first request but its response never reached n8n, repeating a POST with a new key can create the same object twice.

Decide whether the request is safe to repeat

HTTP defines GET, HEAD, OPTIONS, and TRACE as safe methods. PUT, DELETE, and the safe methods are idempotent by their intended semantics. POST is not automatically idempotent.

Real APIs add their own rules, so the provider's documentation remains the contract. A DELETE endpoint may be harmless to repeat, while a POST that sends an email, creates a payment, or reserves stock needs explicit duplicate protection.

Failure	Default action	Duplicate risk
Network timeout or reset	Retry the identical request with the same operation key	High, because the remote service may already have committed the action
429 Too Many Requests	Wait for the provider's limit window, then retry	Controlled only if the operation remains idempotent
500, 502, 503, or 504	Use a small bounded retry policy when the provider permits it	Potentially high for state-changing requests
400, 401, 403, or most 404s	Fix the request, credentials, permission, or resource first	Blind retries rarely fix the cause
409 Conflict	Inspect the API-specific error before deciding	May indicate an existing operation or key conflict

Step 1: create one key for one business operation

Build the key before the HTTP Request node from an ID that already belongs to the event: an order ID, checkout ID, lead ID, invoice ID, or source event ID. Include the action name so different operations on the same record cannot collide.

={{ 'create-order:' + $json.orderId }}

Keep this value unchanged across automatic node retries, manual execution retries, and later recovery runs. Do not use $now, the execution ID, or a freshly generated random value on each attempt. Those identify the attempt, not the operation, so the destination sees every retry as new work.

The key must also stay paired with the same endpoint and payload. If you correct the amount, recipient, or other business data, treat that as a deliberate new operation according to the provider's rules.

Step 2: use the API's idempotency feature first

If the destination API supports idempotency, send the stable key in the exact header or field its documentation specifies. Stripe, for example, accepts an Idempotency-Key header for POST requests and returns the stored result when the same request is repeated with the same key.

That header name is not universal. Some APIs use a request ID, client reference, deduplication ID, or provider-specific field.

Open the HTTP Request node and add the provider's documented idempotency header.
Map the stable operation key as its value.
Keep the method, URL, and request body identical on every retry.
Save the external object ID from the confirmed response for later reconciliation.

Adding an Idempotency-Key header only works when the destination implements that contract. An unknown header may simply be ignored.

Step 3: configure a bounded n8n retry

Every n8n node has a Retry On Fail setting. When enabled, n8n reruns the node after a failure until it succeeds or reaches the configured attempt limit. For a known transient endpoint, start with a small policy such as three tries and a short wait between tries. Increase it only when the provider's limit and incident behavior justify the extra traffic.

This built-in setting is best when every error produced by that node is safe to retry. If you need status-aware behavior, enable Include Response Headers and Status and Never Error in the HTTP Request node. The node can then pass the status code and headers to an IF or Switch branch instead of stopping on every non-2xx response.

Send 2xx responses to the success branch.
Send 429 and approved temporary 5xx responses to a Wait step and bounded retry path.
Send authentication, validation, permission, and unexpected responses to a review or alert branch.
Stop after the maximum attempt count. Never create an unbounded loop.

Step 4: slow down 429 retries

A 429 response means the client sent too many requests in the provider's current limit window. Some APIs include Retry-After as seconds or an HTTP date. Read and honor it when the provider documents that behavior. If the header is absent, use the API's published limit and increase the delay between attempts rather than retrying immediately.

The HTTP Request node also has Items per Batch and Batch Interval options. They control how many input items are sent in each batch and how many milliseconds n8n waits between batches. Use them to prevent a known burst from creating the 429 in the first place.

Step 5: add a persistent duplicate check when needed

When the API has no idempotency feature, keep a small request ledger. n8n's Data Table node can check whether a row exists, insert rows, update them, and upsert by conditions.

Column	Purpose
`request_key`	Stable ID for the business operation
`status`	`pending`, `succeeded`, `failed`, or `unknown`
`external_id`	ID returned by the destination when available
`updated_at`	Timestamp for recovery and stale-pending review

Use this sequence:

Check for a row with the request key.
If it already says succeeded, return the stored result and skip the API call.
If no row exists, record pending, then call the API.
On a confirmed 2xx response, update the row to succeeded and store the external ID.
On a timeout, keep the state as unknown until you query the destination or retry safely.

This ledger is useful for sequential or low-concurrency workflows, but a check followed by an insert is not an atomic lock. Two executions can check at the same moment and both see no row. For parallel production traffic, prefer destination-side idempotency or a database table with a unique constraint on request_key and an atomic claim operation.

Do not use workflow static data as a production lock

The $getWorkflowStaticData() helper looks convenient for storing processed IDs, but n8n labels it experimental, says the data should be small, and warns that it may behave unreliably under high-frequency executions. That makes it unsuitable as the main duplicate barrier for valuable orders, payments, leads, or outbound messages.

A production-safe request sequence

Validate that the event contains a stable source ID.
Create the operation key once.
Check any local success record.
Send the request with the provider's idempotency mechanism.
Retry only network failures, 429s, and provider-approved temporary errors.
Reuse the same key and payload for every attempt.
Store the external ID after confirmed success.
Route exhausted or uncertain outcomes to an Error Workflow or manual review queue.

If you do not yet know why the node failed, use the failed n8n workflow debugging guide. Once the retry budget is exhausted, use an n8n Error Workflow to send the failure to Telegram, Slack, Google Chat, email, or another incident channel.

Sources

Originally published on FloxoLab.

Product Photo to WooCommerce Listing with n8n and AI Vision

Stepan Nikonov — Tue, 11 Aug 2026 05:50:47 +0000

A private admin chat workflow for ecommerce: send a product photo, analyze the image, create a WooCommerce listing, attach the product image, and get the product URL back for review.

This is a small product-intake workflow, not a promise that AI can run an ecommerce store by itself. The useful part is narrower: a product photo becomes a reviewable WooCommerce product page without a person opening WordPress, uploading the image, writing the first description, and sending the review link by hand.

Photo in, review link out.

The workflow handles the repetitive first pass. A person can still check the title, price, category, and claims before using it in a real store.

Input	AI step	Output
Product photo in a private admin chat	Vision analysis creates listing fields	WooCommerce product URL for review

The generated product page

The result is a real WooCommerce product page in a temporary test store. For this demo, the workflow creates the product with the uploaded image, a short title, a short description, and a demo price. The screenshot still shows the store's default category because category mapping was not part of this prototype.

The generated WooCommerce page includes the uploaded image, product title, demo price, and short description.

The loop closes in the same chat

The operator sends a product photo into a private admin chat. After n8n creates the WooCommerce listing, the bot replies with the product URL so the person can inspect it immediately. Telegram is just the internal intake tool here, not a public FloxoLab contact channel.

The same private admin chat closes the loop: the product photo comes in, and the WooCommerce product URL comes back.

The workflow map

The n8n canvas stays simple: receive the photo, fetch the Telegram file, upload it to WordPress Media, analyze the image, create the WooCommerce product, and send a message back to the chat.

The workflow connects a private admin chat to WordPress Media, AI vision, WooCommerce product creation, and a return message.

The AI and tool setup

The image analysis step describes the visible product details. The AI agent then uses that analysis to prepare the product fields and call the WooCommerce tool. In this demo, the price is fixed and the text fields are intentionally short.

The AI agent turns image analysis into concise WooCommerce product fields.

Why this works for WooCommerce teams

This approach works well for WooCommerce because the store already has the pieces the workflow needs: media uploads, product creation, product status, categories, and product URLs. n8n can talk to WooCommerce through native nodes, so a small team can test a product-intake workflow without building a custom admin panel first.

For this demo I used a temporary WordPress and WooCommerce test store. That made it easy to validate the workflow quickly before thinking about a real client store.

What the AI is allowed to do

Use image facts — Listing text should come from the image analysis, not invented product claims.
Keep fields short — The title and description stay compact so a person can review them quickly.
Use demo defaults — This prototype uses a fixed demo price. A real store should pull price, stock, SKU, and category from a trusted source.
Avoid fake details — No sizes, materials, shipping promises, inventory, or brand claims should be added unless they are provided by the store.

Good fits

WooCommerce stores — Small shops that still create product pages manually from product photos or supplier images.
Ecommerce agencies — Teams onboarding new product lines that need a faster first draft before final merchandising review.
Catalog operations — Teams that repeatedly turn image inputs into product records, review queues, or marketplace drafts.
Admin chat intake — The intake chat could be Telegram, Messenger, or Viber depending on the team's daily tools. The important part is private operator intake, not a public support chatbot.

What I would improve next

Draft first — Create products as draft by default, then publish after approval.
Approval button — Add a review step so the operator can approve, edit, or reject a generated product before it goes live.
Better product data — Map SKU, category, price, stock, size, color, and supplier source from trusted tables instead of asking AI to infer them.
Duplicate checks — Search existing products before creating a new page, especially when supplier photos repeat across batches.
Clear failures — If a message has no photo, the file cannot be downloaded, or the image analysis is weak, send a clear error back to the chat.

Related guide

This build leans on an AI agent node rather than a fixed script. For the difference between chatbots, automation workflows, and agents, read AI Agents for Business: What They Actually Do (and 3 Ways to Use Them).

Bottom line

This workflow is useful because it turns a product photo into a reviewable WooCommerce listing without building a custom admin interface. A person should still check the title, category, price, and product claims before using it in a real store, but the blank-page work is already done: image upload, first draft, product page, and review link are prepared automatically.

Even with human review, the workflow can save the repetitive first pass: uploading the image, opening WooCommerce, creating the product, writing a short description, and sending the page link to the person responsible for approval.

Originally published on FloxoLab.

Form + AI Chat Intake with n8n

Stepan Nikonov — Sun, 09 Aug 2026 15:05:30 +0000

A practical workflow that turns a vague website message into something a human can actually act on: a lead record, a private alert, and a workflow map email.

This could have been a dramatic automation story about one workflow saving a business 150,000 hours. It is not. This is a practical demo of a smaller, more common problem: turning a vague website message into something a human can actually act on.

The workflow uses the same intake surfaces FloxoLab already has on the site: a contact form for structured requests and an AI chat for people who start with a messy question.

The form collects fields. The chat collects context.

The useful workflow is not the chatbot by itself. It is the handoff: what gets saved, who gets notified, and what the human can do next.

Inputs	AI step	Output
Contact form and AI chat	Groq returns JSON	Lead brief and map email

Real tools, test data, and why that matters

This workflow shows the working intake pattern: validation, AI response, lead record, private alert, and follow-up email.

Production versions usually need more testing, cleaner edge-case handling, more careful copy, and fields that match the team's real sales or support process. A demo proves the path. Production makes it boring enough to trust.

The workflow has two entry points: a structured contact form path and a conversational AI chat path.

1. Start with the boring form path

The contact form is the clean path. It already has the fields a human needs: name, email, current tools, budget range, and a short message. The workflow checks whether the email already exists, creates a Notion lead if it is new, sends a private alert, and returns a simple OK response.

The form gives the workflow structured fields before any AI is involved.

The form path is intentionally simple: check duplicate, create lead, notify, respond.

2. Let the chat handle messy first messages

The AI chat is for the person who does not know what to put in a form yet. It validates the message, keeps a short safe history, sends a compact instruction set to Groq, and expects a JSON response with reply text, email-offer state, and optional plan data.

The AI prompt is not magic. It is a set of instructions that can be rewritten when the first version does not work.

The chat asks for useful context, then offers to send a workflow map by email.

The AI path is narrow: validate, build messages, call Groq, extract a safe reply.

3. Decide when the workflow should act

The decision point is deliberately plain. If the model says the email is ready and the user has provided enough context, the workflow checks for duplicates, creates a lead, builds an email, and sends it. If not, it simply returns the chat reply.

The workflow should not create records or send emails just because a model replied. It needs an explicit state.

4. Give the human something useful

The useful handoff is not "a lead arrived." It is a lead record with enough context, a private alert that tells the builder what happened, and a first-pass workflow map the user can reply to.

The Notion table can stay tiny or grow into a fuller CRM with source, status, budget, urgency, owner, and next action fields.

The alert can go to Slack, email, or a private internal channel. The important part is that the right person sees it.

The email is a first-pass map, not a final quote: outcome, tools, steps, build range, monthly cost notes, and what to correct.

Demo vs production

A demo can prove the path in half a day. A production workflow needs better copy, fallback paths, duplicate handling, error alerts, cleaner logs, and privacy-safe fields.

Sometimes the hardest production bug is remembering to remove "This message was sent automatically with n8n." That sounds small, but it is exactly the kind of polish that separates a working demo from a workflow a business can comfortably use.

Fields are flexible. The Notion database can have five fields or twenty-five: source, budget, tool stack, urgency, owner, status, next action, or whatever the handoff needs.

Alerts are flexible. The notification can go to Slack, email, Telegram privately, a CRM task, or the channel the team actually checks.

The AI behavior is flexible. It can ask one question, collect missing fields, draft the first reply, or stop and ask a human to review. The prompt is editable.

What can be customized

I can spend 30 days trying to design the perfect intake workflow on paper, or build several working versions in half a day and learn from real messages. For small automations, the second path is usually more useful.

The CRM can be Notion, Airtable, HubSpot, Google Sheets, or something else. The email can be plain text or formatted. The AI model can be Groq, OpenAI, Claude, or no AI at all if the form fields are enough.

Bottom line

This is the kind of workflow automation Philippines teams can inspect: visible inputs, validation before action, AI that returns structured data, a human-readable lead record, and a clear next step.

It is not a giant AI sales machine. It is a small intake workflow that makes the first human response easier.

Originally published on FloxoLab.

AI Email Router with n8n

Stepan Nikonov — Fri, 07 Aug 2026 16:20:35 +0000

A practical n8n workflow that reads Gmail, normalizes the fields, adds basic rule signals, classifies the email with Groq, validates the result, routes a lead into a CRM sheet, alerts Slack, and logs the operation.

This workflow shows the practical parts of AI email routing in the Philippines: the input, the rules, the classifier, the validation step, the route, and the log.

The lead path is walked through in detail because it is enough to show the pattern. Support, invoice, spam, and review branches use the same structure: validate first, route second, act third, log last.

The slow part is not connecting nodes.

It is deciding what should happen, testing real emails, tuning labels, and making the workflow understandable enough for someone else to own.

Trigger	AI step	Detailed path
Unread Gmail message	Groq classifier returns JSON	Lead -> CRM -> Slack -> log

The full workflow map

The canvas has five possible routes. This page follows the lead route end to end, while keeping the other branches visible on the map.

The workflow uses rules, AI classification, validation, routing, action nodes, and one master Google Sheets log.

1. Start with a controlled test email

Before building the rest of the workflow, send yourself one test email for the scenario you want to prove. In this case, the test email is a lead inquiry asking about n8n automation services and pricing.

The Gmail Trigger is then tested and pinned. That gives every next node a stable input while the workflow is being built, instead of waiting for Gmail to trigger again.

The first checkpoint is simple: confirm that Gmail exposes the message id, subject, sender, snippet, labels, and payload.

2. Normalize fields once

Gmail gives useful data, but it is not shaped for the rest of the workflow. The Extract Fields node turns raw Gmail output into clean top-level fields: sender, sender name, domain, subject, body snippet, attachment names, MIME types, and a PDF flag.

Normalize once, then every later node can use clean expressions like sender, domain, subject, and has_pdf.

3. Add basic rule signals before AI

Basic Rules does not replace the classifier in this demo. It adds cheap, inspectable signals before the AI step: suspicious domains, no-reply senders, newsletter patterns, aggressive spam words, trusted domains, and attachment flags.

That makes the workflow easier to review. If the model later calls something spam, validation can check whether the rule-based signals agree before archiving anything.

The rules are intentionally editable. A real team would tune known spam domains, newsletter senders, and trusted domains over time.

4. Keep the AI classifier small

The classifier is called through an HTTP Request to Groq. Its job is narrow: return one label, one confidence score, and one short reason.

{
  "label": "lead",
  "confidence": 0.95,
  "reason": "The email is an inquiry about services and pricing from a potential client."
}

The AI does not create tickets, archive email, or decide the final business action. It only returns structured classification data.

5. Validate before routing

AI output is not safe to trust directly. It can return markdown, broken JSON, a low confidence value, or a label that is semantically correct but operationally unsafe.

Invalid JSON goes to review. The workflow should not fall over because the model wrapped JSON in markdown.
Confidence below 0.75 goes to review. If the model is unsure, a human should see it.
Spam needs rule confirmation. A spam label alone is not enough to archive a message.
Invoice without PDF goes to review. The action depends on attachments, not only on the AI label.

6. Route by validated route, not raw AI label

The router uses the validated route field. This keeps the Switch node simple: the safety decisions already happened in Validation.

Routes include support, lead, invoice, spam archive, and human review.

7. Lead path: CRM, Slack, and master log

The tested path for this demo is lead routing. The workflow writes a CRM row, posts a Slack alert, and then appends the operation to the master log.

Google Sheets receives the sender name, email, domain, subject, source, status, and created timestamp.

Slack gets a readable lead alert with the classification reason and confidence.

The CRM sheet is intentionally plain. For many small workflows, a clean table is enough for the first version.

The master log records completed routes: message id, timestamp, sender, label, confidence, reason, route, and action.

This demo log records completed workflow routes. A production version should add a separate Error Trigger workflow for failed executions.

Other branches use the same pattern

Fully testing every branch means preparing separate tables, statuses, dates, files, review rows, and sometimes real attachments. That setup work matters more than simply drawing lines between nodes.

support — Create a Notion or Airtable ticket, draft a reply, notify Slack, then log the completed route.
invoice — Save the PDF to Drive, add a row to an invoice sheet, notify admin, then log the route. If there is no PDF, send it to review.
spam — Archive only when rule signals and confidence agree. Otherwise send it to review.
review — Add uncertain messages to a human review queue instead of forcing the workflow to guess.

What this demo does not cover

This is a useful first version, not the final production checklist. A production build would add an Error Trigger workflow, retry rules, stricter credential ownership, more test messages, and clearer handoff notes for the person who owns the inbox.

It would also test each branch with real examples: a support question, a real invoice PDF, a marketing email, a spam candidate, and at least one messy message that should go to review.

The setup pieces can be scaffolded too, such as a Drive folder, Sheets logs, a CRM sheet, and a Notion ticket database. I covered that pattern in the Claude connectors guide.

Bottom line

This is the kind of workflow automation Philippines teams can inspect: one trigger, clean fields, editable rules, a small AI classifier, validation before action, visible branches, Slack alerts, and a master log.

It is not AI magic. It is a small operations workflow that becomes useful when the labels, thresholds, and ownership are tuned against real email.

Originally published on FloxoLab.

Screaming Frog Review (2026): The Technical SEO Crawler I Audit With

Stepan Nikonov — Thu, 06 Aug 2026 01:40:10 +0000

Screaming Frog is the tool I actually open to run a technical SEO audit, including the one on this site. It is not pretty and it is not for everyone, but for finding what is broken under the hood of a website, nothing else comes close at the price. Here is the full review: what it finds, the free version versus the paid licence, where it frustrates, and who really needs it.

4.6 out of 5

The short verdict

The industry-standard desktop crawler for technical SEO, and the best value in its class. It finds the template-level problems other tools miss, the free version covers small sites, and the licence is cheap for what it does. It is single-purpose, runs on your own machine, and has a learning curve, so it is a specialist's tool, not an all-in-one.

Most SEO tools show you a dashboard. Screaming Frog shows you the truth. It is a desktop crawler: you point it at a website and it walks every link the way a search engine would, then hands you a spreadsheet of everything it found, every URL, status code, title, redirect, canonical, and broken link. It is the difference between a tool telling you "your site health is 82" and a tool telling you "these 14 pages return 404, these 6 titles are duplicated, and this canonical points to the wrong URL". For the technical and on-page work I do, that second answer is the one I need.

What Screaming Frog actually does

It crawls, and it crawls thoroughly. The things I reach for it for, over and over:

Broken links and redirects. Every 404, every redirect chain, every loop, listed with the page it sits on. This alone is worth the download.
Titles, meta, and headings at scale. Missing, duplicate, too long, or too short, across the whole site at once, which is exactly the template-level problem a dashboard tool hides.
Canonicals, indexability, and directives. What is canonicalised where, what is noindexed, what robots and the meta tags actually say, so you can see why a page is or is not in the index.
Structured data and hreflang. Validates schema and international tags page by page, the kind of detail covered in the technical SEO fixes agencies won't touch.
XML sitemaps and crawl depth. Generate a sitemap, or see how many clicks deep your important pages sit, which affects how Google crawls them.
Integrations and rendering (paid). Pull in Google Analytics, Search Console, and PageSpeed data against each URL, render JavaScript, schedule crawls, and extract anything from the HTML with custom XPath.

Free versus paid: what you actually get

Here is what you actually get for each. Treat the prices as a snapshot from June 2026, and check the live page before buying.

Version	Price	Crawl limit	Advanced features
Free	$0	500 URLs	No
Paid licence	~$279 / £199 / €245 per year	Unlimited	Yes (JS rendering, scheduling, integrations, custom extraction)

The 500-URL free limit is more generous than it sounds. A typical small business site is well under 500 pages, so for a single small site, a spot check, or learning the tool, the free version genuinely does the job and costs nothing. You hit the wall when you crawl larger sites, audit many sites, or need JavaScript rendering and the API integrations. At that point the licence, per user per year, is one of the best-value purchases in SEO. The licence is per person, so a two-person team needs two.

Strengths and weak spots

It earns its 4.6, not a 5. Here is the balance, the strengths alongside the real frustrations.

What it does well

The deepest, most trustworthy technical crawl at this price.
Free version covers small sites with no catch beyond the 500-URL cap.
Finds template-level issues dashboards hide.
Integrations, rendering, and custom extraction on the paid tier.
No subscription lock-in to a web platform; the data is yours, locally.

Where it gives ground

Single-purpose: no rank tracking, no keyword research.
Steep learning curve; the interface is dense and unapologetically technical.
Desktop app: large crawls eat RAM and need memory configuration.
You read and interpret the data yourself; it does not hand you a prioritized plan.

The last point is the one that matters for a non-specialist. Screaming Frog tells you everything, which is exactly the problem if you do not already know what to ignore. It is a scalpel, not a checkup. It will happily show a small business owner ten thousand rows and no sense of which three actually hurt rankings.

Who should use it, and who should not

Use Screaming Frog if you do technical SEO yourself, as a freelancer, agency, in-house SEO, or a developer who wants the real state of a site. The free version is the right first download for a small site; the licence pays for itself fast once you audit regularly.

Look elsewhere if you want rank tracking, keyword research, or reporting, which Screaming Frog does not do; for that, an all-in-one like SE Ranking fits better, and many people run both. And if you are a small business owner who just wants the problems found and fixed once, without learning a crawler, buying the tool is the wrong purchase. That is what an audit is for.

The bottom line

Screaming Frog is the technical SEO crawler I trust and the one I run when I audit a site, this one included. For specialists it is close to essential, and cheap for what it does. For a small business owner it is a powerful free spot-check on a small site, and a poor purchase if you are not going to live in the data. Know which of those you are, and the decision is easy.

Common questions

Is Screaming Frog free?

Yes, with a limit. The free version of the Screaming Frog SEO Spider crawls up to 500 URLs, which is enough for a small site or a quick spot check. To crawl more than 500 URLs and unlock advanced features like JavaScript rendering, scheduling, and API integrations, you need the paid licence.

How much does Screaming Frog cost?

The paid licence is GBP 199, USD 279, or EUR 245 per year, per user, at the time of writing. The licence is annual and per person, so two people need two licences, with small discounts on bulk purchases of five or more.

Is Screaming Frog worth it for a small business?

For most small business owners, the free 500-URL version is enough for an occasional check, and you do not need the paid licence. The licence is worth it for anyone auditing sites regularly: freelancers, agencies, and in-house SEOs who crawl larger sites or need rendering and integrations. If you just want the problems found and fixed once, hiring an audit is often cheaper than buying and learning the tool.

What is the difference between Screaming Frog and SE Ranking?

They solve different problems. Screaming Frog is a deep technical crawler that inspects every URL on a site, but it does not track rankings or research keywords. SE Ranking is an all-in-one suite for rank tracking, keyword research, and reporting, with a lighter built-in audit. Many people use both: Screaming Frog for the deep technical crawl and an all-in-one tool for tracking and research.

Sources checked

Originally published on FloxoLab.

Lead Outreach Drafts with n8n, Airtable, Groq, and DeepSeek

Stepan Nikonov — Sat, 01 Aug 2026 16:34:42 +0000

A practical workflow that researches a company website, writes one short outreach draft from real context, and saves it to Airtable for human review before anything is sent.

Each company gets one draft based on its own website. The AI prepares the research and message. A person decides whether it is worth sending.

The bottleneck is not the AI.

It is the last 30 seconds of human judgment: read the draft, decide if the lead is worth contacting, edit if needed, then send or skip.

Lead source	Research step	Draft step
Airtable rows with pending websites	Groq Compound Mini visits the site	DeepSeek writes a short message

Screenshots use real public website research from a small test list. Third-party company names and URLs are redacted because those businesses are not FloxoLab clients and are not shown as endorsements. The visible FloxoLab row is included so the research and draft path can be inspected openly.

The result in Airtable

The final table is the review queue. Good rows get Status = Done, plus a draft message and research notes. Broken, parked, or unusable websites are routed to Status = Blocked or Status = Needs review instead of forcing a fake personalization.

Drafts and notes land in Airtable for review. The workflow prepares messages; a human still decides what happens next.

The full workflow map

The canvas starts with pending Airtable leads, loops through each row, researches the website, checks whether the research is usable, generates a draft only when the site is usable, saves the result, and waits three seconds before the next lead.

The useful parts are visible: input rows, research, parse checks, draft generation, Airtable update, failed-site routing, and pacing between leads.

Research the company first

The Research Company node calls Groq using groq/compound-mini. Its job is narrow: visit the public website and return factual JSON with a research status field. In this workflow, that field is expected to be done, blocked, or unclear.

The research prompt asks for what the company sells, how customers book or inquire, visible calls to action, and a few useful personalization facts. It explicitly tells the model not to invent content for broken or empty websites.

Groq Compound Mini handles the research step and returns structured context for the next model.

Draft from one real detail

The draft step uses DeepSeek to write a short message from the research. The instruction is intentionally restrained: 3-5 short sentences, under 80 words, one specific detail, no fake enthusiasm, no invented statistics, no generic "businesses like yours" line.

The draft is useful because it has context. It is still only a draft until someone reviews it.

Route bad inputs away from drafting

A practical outreach workflow should not pretend every website is usable. If parsing fails, Airtable gets Status = Needs review. If the website is blocked, broken, parked, or too thin, the row can be updated to Status = Blocked.

This route is what keeps the workflow honest: bad input becomes review work, not fake personalization.

Why the cost is low

This pattern is cheap to test because each row is a small research-and-draft job, not a long agent session. In my Groq account, 16 days of workflow testing showed Current Monthly Usage = $0.26. That included more than this one workflow and a day where I tested around 100 runs across different models. DeepSeek draft testing was under $0.10.

That is not a production guarantee. Real cost depends on website size, model choice, prompt length, retries, and how many leads you run. But for a small outreach test, the bigger cost is usually not model tokens. It is finding a clean lead list and spending the review time well. A small Upwork research task can produce a niche list of real businesses with websites and public contact paths for a low cost.

Airtable: stores the review queue, status, notes, and draft message.
Groq Compound Mini: researches each public website and returns compact factual JSON.
DeepSeek: writes one short draft from the research instead of a generic template.
Human review: protects the workflow from becoming an auto-send spam machine.

Good fits

Niche outreach — A freelancer or small team can review 20-50 researched leads instead of sending the same email to a scraped list.
Shopify wholesale — A store can research potential stockists, draft a note from their product fit, and approve only the contacts that look relevant.
Google Workspace follow-up — Form or Sheet rows can be enriched before a Gmail draft, Viber follow-up, or owner task is created.

What I would improve next

Approval status — Add Approved, Skipped, and Sent states in Airtable so sending is a separate decision after review.
Manual send step — After approval, n8n could send the message automatically through Gmail or another tool, then log the sent timestamp and message id.
Follow-up drafts — Add a 3-5 day follow-up draft for approved leads that did not reply, with a clear stop condition.
Do-not-contact list — Check every lead against skipped domains, existing contacts, unsubscribes, and companies that should never be contacted again.
Channel variants — For some Philippines workflows, the output might be a Gmail draft, LinkedIn note, Viber follow-up, WhatsApp draft, or owner task instead of an email.

Related guide

For the budgeting side of lead work, read How Much Does It Cost to Automate Lead Follow-Up in the Philippines?. It breaks down where the money actually goes once outreach turns into ongoing follow-up.

Bottom line

This workflow is useful because it avoids the weakest part of many outreach systems: a generic message sent to every company. It turns public website context into a draft that a person can review.

It is not a promise of sales results. It is a small, inspectable system for doing better first-contact prep: real research in, short draft out, human approval before send.

Originally published on FloxoLab.

RAG for Small Businesses: AI That Searches Your Company Knowledge

Stepan Nikonov — Thu, 30 Jul 2026 23:02:43 +0000

RAG sounds technical, but the useful idea is simple: let AI search selected company documents before it answers, instead of asking it to guess from a blank chat window.

Most small businesses do not have a knowledge problem because they lack information. They have one because the information is scattered. A price note is in one folder, a refund rule inside an old PDF, a support answer buried in email, a delivery process in someone's private notes. The owner, manager, or senior admin becomes the living search engine.

This is where RAG can be useful. Not as a black box AI agent. Not as a replacement for good operations. Just as a practical way to help a team search its own knowledge before asking AI to write an answer.

RAG is not the AI knowing everything. It is the AI looking at selected company information first, then answering from that context.

The actual business problem

A small team usually knows the answers. The slow part is finding the right answer at the right moment.

A new employee asks the same onboarding questions every week.
Sales needs the latest package details before replying to a lead.
Support has to search old conversations for a policy answer.
Operations keeps a checklist in one place and exceptions somewhere else.
The owner becomes the person everyone asks before making a small decision.

A normal keyword search helps only when the person knows the exact word to search for. Real questions are messier. Someone asks "can we still refund this?" while the document says "cancellation window." Someone asks "what do we include in the starter package?" while the pricing file says "basic implementation scope."

RAG in plain English

RAG means retrieval-augmented generation. In plain English: the system retrieves relevant information first, gives that information to the AI model, and then asks the model to generate an answer from that context.

That matters because a normal chatbot can write confidently without knowing your internal rules. A RAG assistant can be told to answer only from selected business documents and to say when the answer is not in the provided knowledge.

A simple RAG pattern: selected company documents become searchable knowledge, a team asks a question in chat, and the answer is grounded in retrieved context.

What a vector database does

A vector database helps search by meaning, not only by exact keywords. If someone asks about "refund rules" and the document says "cancellation and return policy," a semantic search can still find the right section. That is the useful part; the business does not need a lecture on embeddings before it can benefit from better internal search.

One practical detail matters: the embedding step is separate from the answer-writing step. An embedding model turns each approved document chunk into a vector. Qdrant stores and searches those vectors. A language model can then write an answer from the retrieved context. Those jobs should not be blurred together.

Where the tools fit

In a small RAG workflow, each tool should have one clear job.

n8n coordinates the workflow. It receives a question, triggers the search step, sends the retrieved context to the model, logs the result, and returns the answer to the team.

Qdrant stores searchable document chunks. It keeps selected company knowledge in a form that can be searched by meaning rather than exact wording.

An embedding model creates the vectors. This can be OpenAI’s embedding API or another dedicated embedding model. Its job is to convert the documents and the user’s question into comparable numerical representations.

A language model writes the answer. Groq or another LLM can be used here, but it should answer from the retrieved context rather than invent a policy that is not in the documents.

Slack gives the team a familiar interface. Questions and answers can stay inside a private internal channel instead of another dashboard nobody opens.

The stack itself is not the point. Qdrant, n8n, an embedding model, an answer model, and Slack are useful only when the workflow answers a real operational question faster and more consistently than manual search.

Business questions this can help with

A knowledge assistant is most useful when the answer already exists somewhere, but the team wastes time finding it.

Pain	Useful first version	Human check
New staff asks the same setup questions.	Search onboarding docs and SOPs from Slack.	Escalate missing or outdated answers.
Sales needs package and pricing details quickly.	Retrieve the latest service scope, inclusions, and limits.	Manager approves unusual discounts or exceptions.
Support repeats answers from old tickets.	Search FAQ, policy, and troubleshooting notes.	Agent reviews before sending to a customer.
Operations has checklists across files.	Find the relevant process step or exception rule.	Owner confirms edge cases.

This is why RAG can be a good fit for small team automation work. Many teams already run on Drive folders, PDFs, spreadsheets, Notion pages, email threads, and chat, and the first win is often not replacing those tools. It is making the right parts searchable.

For small businesses in the Philippines, the knowledge layer is often less polished than a formal company wiki. It may be a mix of Google Drive folders, Facebook Messenger threads, WhatsApp or Viber chats, Gmail, shared spreadsheets, and a few documents only one person knows about. A useful AI knowledge assistant should respect that reality: start with the approved files and processes, then connect to the team's actual tools only when the workflow is clear.

What this will not fix

RAG does not make bad documents good. If the source material is outdated, contradictory, or missing, the assistant should not pretend otherwise.

It will not decide company policy for you.
It will not clean years of messy files by itself.
It should not answer sensitive questions without access control.
It should not hide uncertainty behind a confident paragraph.
It still needs testing with real questions from the team.

A good version should be allowed to say: "I cannot find that in the provided documents." That answer is sometimes more valuable than a polished guess.

Start smaller than you think

The first version does not need every file the company has ever created.

A better starting set might be 10 to 30 useful documents: current pricing, service scope, refund policy, onboarding SOP, support FAQ, delivery checklist, and a few internal notes that people already ask about. That is enough to test whether the assistant retrieves useful context before you spend time connecting more systems.

The first build should also have a narrow promise: answer internal team questions from selected documents. Not update customer records, not send client replies, not make decisions without review.

Questions to map before building

Before turning this into a workflow, map the knowledge first.

Which documents are actually current?
Which questions does the team ask repeatedly?
Which answers are safe for internal use only?
Which answers should require manager approval?
Where should the assistant answer: Slack, email, Notion, or another tool?
What should happen when the answer is missing or uncertain?

These questions matter more than the model choice. A fast model connected to messy, unreviewed knowledge will still produce messy answers faster.

Bottom line

RAG is useful when the business already has answers, but the team loses time finding them. Start with a small, approved knowledge set, test real questions, and make the assistant show uncertainty instead of filling gaps with confident guesses.

The practical goal is not to make a chatbot sound impressive. It is to help a team find the right internal answer faster, with enough context for a human to trust, check, or improve it.

Want to see the workflow version? I built an inspectable Slack Knowledge Bot with n8n, Qdrant, and Groq that answers from approved Google Drive docs, shows sources, and marks low-confidence matches.

Sources

Originally published on FloxoLab.

How to Fix Core Web Vitals: LCP, CLS, and INP in Plain English

Stepan Nikonov — Sun, 26 Jul 2026 19:33:34 +0000

I took this site from a mobile score of 77 to 98, and to 100 on desktop. Here is what each Core Web Vital measures, what drags it down, and the fixes that actually moved the numbers, in plain language you can act on.

Core Web Vitals are three numbers Google uses to measure how a page feels to a real person: how fast the main content loads, whether the layout jumps around while it does, and how quickly the page reacts when you tap or click. They are part of Google's page experience signals, which means they work as a ranking tie-breaker. Between two pages that answer a query equally well, the faster, steadier one has the edge.

This guide explains each of the three, plus the supporting numbers you will see in the same report, and then shows the real fixes that took this site's mobile score from 77 to 98. Nothing here is theory. It is the same work I run on client sites in an SEO audit.

What a good result looks like

Here is where this site sits today, straight from Google's PageSpeed Insights: 98 on mobile and 100 on desktop, on the same code. The two tests look different because mobile is run on a throttled, slower simulated device, so it always has less room to work with. Mobile is the harder target, and since mobile traffic dominates most sites, its real-user data usually carries the most ranking weight, so it is the score worth chasing. Google measures mobile and desktop separately, so desktop still counts too.

Mobile: performance 98, LCP 1.9s, CLS 0, all vitals in the green.

Desktop: performance 100, LCP 0.5s, CLS 0, speed index 0.4s.

The three Core Web Vitals, one at a time

Everything on the scoreboard comes down to three real-user metrics. A page passes when 75 percent of real visitors fall inside the "good" band for each.

Metric	Measures	Good	Poor
LCP (Largest Contentful Paint)	Loading	2.5s or less	Over 4s
CLS (Cumulative Layout Shift)	Visual stability	0.1 or less	Over 0.25
INP (Interaction to Next Paint)	Responsiveness	200ms or less	Over 500ms

LCP: how fast the main thing loads

Largest Contentful Paint is the moment the biggest element in view finishes rendering, usually the hero image or the headline block. It is the reader's gut sense of "has this page loaded yet". What drags it down is nearly always one of four things: a heavy, uncompressed hero image, a slow server or host, render-blocking CSS and JavaScript that must run before anything paints, and web fonts that arrive late.

The fixes follow the causes. Compress and serve the hero as WebP at the right size, and preload it so the browser fetches it early. Use srcset so a phone pulls a small version and a desktop a larger one, instead of shipping one heavy file to every device. That is a separate lever from preloading: preload fetches the image sooner, srcset makes sure it is the right weight, and on a slow mobile connection the srcset part is often what saves the most. Cut or defer render-blocking scripts, and self-host your fonts instead of pulling them from a third-party domain. On this site LCP is 1.9s on mobile and 0.5s on desktop, and the single biggest lever was the hero image: right format, right size per device, preloaded.

CLS: whether the page holds still

Cumulative Layout Shift measures how much the content jumps around as the page loads. You have felt it: you go to tap a link, an image or banner loads above it, and the whole page shoves down. The usual culprits are images and embeds with no width and height set, ad or banner slots injected after load, and fonts that swap and reflow the text.

This is the most fixable vital, and the cheapest win on the list. Put explicit width and height (or an aspect ratio) on every image and iframe so the browser reserves the space before the file arrives. Give injected elements a fixed slot. Set font-display so a font swap does not reshuffle the layout. This site sits at a CLS of 0, and it got there almost entirely by adding size attributes to images.

INP: how fast the page answers you

Interaction to Next Paint replaced First Input Delay in March 2024. It measures the delay between you doing something, a tap, a click, a keypress, and the page actually showing a response, taking close to the worst interaction across the whole visit. A high INP is a page that feels sluggish and unresponsive, and the cause is almost always JavaScript hogging the main thread: heavy frameworks, big third-party scripts, and long tasks that block the browser from reacting. It is also the vital the most sites fail, so it is worth the attention.

The fix is to give the main thread less to do. Defer or split heavy JavaScript, hold third-party scripts off the critical path until the user needs them, and break long tasks into smaller pieces. The clearest example on this site is analytics: the Google tag does not load until the first interaction or the browser goes idle, so it never blocks that first tap. That one change keeps total blocking time, the lab stand-in for INP, at 40 milliseconds.

The other numbers in the report

The same Lighthouse report shows three more metrics. These are lab diagnostics, useful for finding problems, but they are not the vitals Google ranks on.

First Contentful Paint (FCP). When the first text or image appears. An early signal that something is happening.
Total Blocking Time (TBT). How long the main thread was blocked during load. It is the lab proxy for INP, so lowering TBT usually lowers INP for real users too.
Speed Index. How quickly the page visibly fills in. On this site it shows 3.5s on mobile and lands in the amber band, while every actual vital is green. That is a fair reminder that the overall score is a blend, and a single amber lab number is not worth panicking over when the real-user vitals all pass.

Lab data and field data are not the same

There are two ways to measure all of this, and mixing them up causes a lot of confusion. Lab data is a single simulated test, like the Lighthouse run in the screenshots above, on a fixed device and connection. It is repeatable and great for debugging. Field data is what real Chrome users actually experienced over the last 28 days, and it is what Google uses for ranking. You can see your own field data in the Core Web Vitals report inside Search Console.

The practical order: use the lab test to find and fix problems fast, then watch the field data in Search Console to confirm real users feel the change. A lab score can be perfect while the field still lags, especially on a page that only just got fixed, because the field window is a rolling average. Reading that report is part of the wider habit covered in how to read your monthly SEO report.

What actually moved this site from 77 to 98

The jump was not one clever trick. It was a short list of unglamorous fixes, each aimed at a specific metric:

Self-hosted the fonts. Pulling fonts from a third-party domain adds a connection and a render delay. Serving them from the same domain, preloaded, cut straight into LCP.
Deferred analytics off the critical path. The Google tag now loads on first interaction or idle instead of during load, which kept total blocking time, and therefore INP, low.
Responsive images in WebP. Every image ships as WebP at several sizes with srcset, so a phone downloads a small file and a desktop a larger one, never the wrong one.
Width and height on everything. Explicit dimensions on images and figures reserve their space, which is why CLS is 0.

None of that touched the design or the content. It is exactly the kind of finite, technical work that a small site needs once, not every month, which is the point I make in the technical SEO fixes agencies won't touch.

A quick checklist

Compress the hero image, serve it as WebP, and preload it.
Set width and height on every image, iframe, and embed.
Self-host fonts and set font-display so text does not reflow.
Defer analytics and other third-party scripts off the load path.
Test in the lab with PageSpeed Insights, then confirm in Search Console field data.

Frequently asked questions

What are Core Web Vitals?

Three metrics Google uses to measure real-world page experience: Largest Contentful Paint (LCP) for loading, Cumulative Layout Shift (CLS) for visual stability, and Interaction to Next Paint (INP) for responsiveness. They come from real Chrome users and feed into ranking as a page experience signal.

What is a good Core Web Vitals score?

A page passes when 75 percent of real users see LCP at 2.5s or less, CLS at 0.1 or less, and INP at 200ms or less. In the Lighthouse lab test the overall score is good from 90 to 100. This site scores 98 on mobile and 100 on desktop.

Why is my mobile score lower than desktop?

Lighthouse tests mobile on a throttled, slower simulated device and connection, so the same page has less CPU and bandwidth to work with. Mobile is the harder target, and because mobile traffic dominates most sites, its real-user data usually carries the most ranking weight, so it is the score to optimise for. Google measures mobile and desktop separately, so desktop still counts.

Do Core Web Vitals affect SEO rankings?

Yes, as a tie-breaker rather than a magic lever. Between two pages of similar relevance, the faster and steadier one has an edge. Fixing vitals will not outrank a far more relevant page on its own, but poor vitals can hold back a page that otherwise deserves to rank.

Sources checked

Originally published on FloxoLab.

Slack Knowledge Bot with n8n, Qdrant, and Groq

Stepan Nikonov — Fri, 24 Jul 2026 10:49:36 +0000

A practical workflow that turns approved Google Drive docs into a Slack assistant. It chunks selected files, stores embeddings in Qdrant, retrieves relevant context, asks Groq to answer only from that context, and replies with sources or a low-confidence note.

Many teams already have the answer somewhere: a pricing note, an onboarding doc, a service FAQ, a checklist, or a handoff process. The slow part is finding the right section while work is happening.

This workflow gives Slack a searchable knowledge layer. A team member asks a question, n8n searches an approved Google Drive folder through Qdrant, and Groq writes an answer from the retrieved context with source files attached.

The useful part is not a confident answer.

It is a traceable answer: what documents were searched, which sources were used, and whether the match was weak enough to treat with caution.

Knowledge source	Search layer	Team interface
Approved Google Drive Markdown files	Qdrant vectors from local embeddings	Slack mention with sources

Approximate running cost

For this demo, the software bill can stay very low. Ollama runs the embedding model locally. n8n can run as a free self-hosted community edition. Qdrant can run locally or start on a free cloud tier for testing. Groq is the main paid API part, and a small internal bot like this can often be tested on a small balance when question volume is modest.

Ollama embeddings: no API bill when the embedding model runs on your own machine or server. The cost is local compute.
n8n: free if self-hosted, with hosting and maintenance still owned by someone. n8n Cloud is paid if you want managed hosting.
Qdrant: local/self-hosted can be free to run as software. Qdrant Cloud also has a free tier for testing and prototypes, with paid usage when the project grows.
Groq: the answer generation step is usage-based. For a low-volume demo, a small balance such as USD 5 can be enough to test the pattern for a while, but real spend depends on model choice, prompt size, and usage volume.

Low software cost to start. Real cost is hosting, API calls, and whoever maintains it.

Groq: the answer generation step is usage-based. For a low-volume demo, a small balance such as USD 5 can be enough to test the pattern for a while, but real spend depends on model choice, prompt size, and usage volume.

Low software cost to start. Real cost is hosting, API calls, and whoever maintains it.

The full workflow map

The canvas has two lanes. The top lane refreshes the knowledge base: list files, filter approved text files, chunk them, embed them, delete old chunks for the same source, and upsert the fresh points into Qdrant. The bottom lane answers questions from Slack.

Two visible paths: document ingestion on top, Slack question answering below.

1. Start with approved docs

The workflow starts from a controlled Google Drive folder. In this demo, the folder contains Markdown files for FloxoLab pricing, services, FAQ, workflow examples, onboarding, and intake process notes.

That matters because a useful knowledge bot should not begin by crawling a messy shared drive. The first version should use current, approved documents that are safe for internal answers.

The workflow filters for Markdown files, so the first knowledge base stays simple and reviewable.

2. Chunk the files with metadata

Each file is downloaded and passed through a code node that splits text by headings, keeps chunks under a practical word limit, and adds metadata such as source, file index, chunk index, word count, and last modified time.

Metadata is not decoration. It is what lets the answer show where the context came from, and it gives the workflow a clean way to replace old chunks from the same source during the next ingestion run.

Each chunk carries source and index data, not just text.

3. Store searchable chunks in Qdrant

The workflow uses Ollama with nomic-embed-text for embeddings, then prepares a Qdrant point with a deterministic id, vector, and payload. Before upserting new points, it deletes old chunks for the same source so stale content does not sit beside fresh content.

Qdrant stores the vector plus the payload fields the workflow needs later: text, source, chunk index, timestamps, and word count.

4. Ask from Slack

The question flow starts when someone mentions the bot in Slack. n8n removes the mention text, embeds the clean question, searches Qdrant for the top matching chunks, and builds a compact context block for Groq.

The answer prompt is deliberately strict: answer only from the provided context, do not invent pricing, services, guarantees, timelines, or policies, and keep the message concise enough for Slack.

The user asks inside Slack. The bot answers from the retrieved context and appends source files.

5. Make uncertainty visible

The workflow also marks weak retrieval. If the top Qdrant score is below the threshold, the answer includes a low-confidence note. That is a practical guardrail because the user can see the answer should be checked before it becomes a decision.

A missing answer should stay visible. Here the bot says it does not know and marks the match as low confidence.

What I would improve next

The demo proves the path, but a production version should make ownership clearer.

Better source links. File names are useful, but links back to the exact Google Drive document would make review faster.
Threaded Slack replies. Posting answers in the original thread would keep channels cleaner.
Low-confidence review. Weak matches could be logged to a sheet or sent to a private review channel.
Ingestion logs. A clear record of files, chunk counts, and failures would make handoff easier.

Bottom line

A Slack knowledge bot is useful when the answer already exists, but the team wastes time finding it. The important choices are not only model and database. They are the approved knowledge set, the retrieval threshold, the source display, and the fallback behavior.

This workflow keeps those parts visible: selected docs in, searchable chunks stored, Slack question asked, context retrieved, answer written from that context, sources shown, uncertainty surfaced.

Related guide

For the plain-English explanation behind this pattern, read RAG for Small Businesses: AI That Searches Your Company Knowledge.

Originally published on FloxoLab.

n8n Webhook Not Working? Test URL, Production URL, and 404 Fixes

Stepan Nikonov — Tue, 21 Jul 2026 07:25:33 +0000

If an n8n webhook receives nothing or returns 404, check the URL mode and registration state before changing the workflow. This guide follows the shortest useful diagnostic order.

An n8n webhook normally fails before the first workflow node runs. A 404 usually means the request did not match a registered webhook route. The common causes are a test URL with no active listener, a production URL for an unpublished workflow, the wrong HTTP method, a changed path, or an incorrect public URL on a self-hosted instance.

Fastest check: open the Webhook node, copy the URL again, confirm whether it is Test or Production, and send the same HTTP method configured in the node. Do this before debugging credentials, expressions, or downstream nodes.

Start with the symptom

Symptom	Most likely check	First action
Test URL returns 404	No current test listener	Select Listen for test event, then resend within 120 seconds.
Production URL returns 404	Workflow is not published	Publish the workflow and copy the Production URL again.
URL works in a browser but not from the app	GET versus POST mismatch	Match the sender's method to the Webhook node.
URL has the wrong domain, port, or protocol	Self-hosted proxy configuration	Check `WEBHOOK_URL`, proxy hops, and forwarded headers.
Webhook runs but no data appears on the canvas	Production execution	Open the workflow's Executions tab.

Test URL versus Production URL

Every Webhook node exposes two URLs at the top of its panel. The official Webhook node documentation treats them as two different operating modes, not interchangeable copies of the same endpoint.

Use the Test URL while building

Select Test URL, then select Listen for test event before the external system sends its request. n8n registers the test webhook for 120 seconds and displays the incoming data in the editor. If the timer expires, register it again and resend the event.

Opening the workflow is not enough by itself. A saved test URL can return 404 later because test registration is temporary. This is useful during development because it lets one test payload appear directly on the canvas, but it is the wrong URL for a service that must call n8n at any time.

Use the Production URL after publishing

Select Production URL, copy it into the sending service, and Publish the workflow. Current n8n documentation uses Publish terminology. Publishing registers the production webhook and makes the published workflow version available to external requests until the workflow is unpublished.

Production payloads do not appear live on the editor canvas. Open Executions to confirm whether the request created a production execution and to inspect its input. No data on the canvas does not mean the webhook failed.

The n8n webhook 404 checklist

Run these checks in order. Stop as soon as the request reaches n8n.

Copy the URL from the node again. Do not rely on a URL saved in an old note, form, app, or API client.
Confirm Test or Production. Test requires a temporary listener. Production requires a published workflow.
Confirm the HTTP method. A POST request does not match a webhook registered only for GET.
Compare the path exactly. Check spelling, hyphens, route parameters, and any path changed after the sender was configured.
Check for a path-and-method conflict. n8n permits only one registered webhook for each path and method combination.
Inspect the public base URL. Do this only for self-hosted n8n behind a reverse proxy or when the node displays an internal hostname, HTTP instead of HTTPS, or the wrong port.

Check the HTTP method before the payload

The Webhook node supports GET, POST, PUT, PATCH, DELETE, and HEAD. By default it accepts one method. The sender must use that exact method. Pasting a webhook URL into a browser sends GET, so a successful browser test does not prove that a service's POST request will match, and the reverse is also true.

Current n8n versions can allow multiple HTTP methods from the node's Settings. Use that only when the endpoint genuinely needs more than one method. A tighter single-method webhook is easier to reason about and reduces accidental calls.

Check the webhook path

n8n generates a random path by default, and you can replace it with a stable custom path. Once an external app stores the URL, changing the Path field changes the route it must call. Copy the complete URL after every path change instead of editing only the last segment by hand.

n8n also requires each registered path and HTTP method combination to be unique. If another published workflow already owns the same combination, unpublish the conflicting workflow or choose a different path or method. The Webhook common-issues page documents both method matching and route conflicts.

Send a minimal request

Remove the external app from the diagnosis. Copy the exact URL from the Webhook node and test it with a safe placeholder payload. The example below uses POST. Change the method if your node uses something else.

curl --request POST 'https://n8n.example.com/webhook/example-path' \
  --header 'Content-Type: application/json' \
  --data '{"event":"webhook-test","id":"demo-001"}'

Replace the example URL with the full Test or Production URL copied from your node. For a Test URL, select Listen for test event immediately before running the command. For a Production URL, publish first. If this request works, the remaining problem is in the external app's stored URL, method, headers, authentication, or network access.

Reverse proxy and public URL problems

Skip this section on n8n Cloud. It matters when a self-hosted instance runs internally on one address but a reverse proxy exposes a different public HTTPS address.

n8n normally builds webhook URLs from N8N_PROTOCOL, N8N_HOST, and N8N_PORT. Behind a proxy, that can produce an internal port or the wrong scheme. The official reverse-proxy configuration says to set the public URL explicitly with WEBHOOK_URL, set N8N_PROXY_HOPS to the number of reverse proxies, and pass the forwarded host, protocol, and client information from the last proxy.

WEBHOOK_URL=https://n8n.example.com/
N8N_PROXY_HOPS=1

Do not copy this blindly. Use your real public HTTPS base URL and the actual number of proxies in the request path. Restart or redeploy n8n after changing environment variables, then copy the regenerated webhook URL from the node.

What to log before handing the webhook into production

The final Production URL location and which external system owns it. Do not paste secret query parameters into a public document.
The expected HTTP method, content type, authentication method, and a sanitized example payload.
The workflow owner and where production executions are reviewed.
The expected success response and what the sender does when it receives a non-2xx response.
The alert channel and recovery owner for failures after the webhook starts the workflow.

Once the route works, broader failures belong in the n8n workflow debugging guide. Production ownership and notifications belong in the n8n error workflow alerts guide. Keeping those jobs separate makes the webhook checklist short enough to use during an incident.

The production handoff

Test with the Test URL and one sanitized payload.
Switch the node to Production URL and copy the full value.
Publish the workflow.
Update the external service with the Production URL and matching method.
Trigger one real but safe event.
Confirm the run in Executions and record who owns failures.

n8n autosaves edits, but saved draft changes are not the same as the published version used by production executions. The save and publish documentation explains that production runs continue to use the current published version until you publish newer changes.

Originally published on FloxoLab.