DEV Community: Piyush Kumar Soni

I Created a Free Firefox Extension to Audit Google Business Profiles and AI Visibility

Piyush Kumar Soni — Mon, 31 Aug 2026 12:07:44 +0000

I recently created a Firefox extension called GBP Audit AI Visibility by Lucky Digitals.

The idea came from something I was doing again and again while working on local SEO.

Whenever I checked a Google Business Profile, I had to review multiple things manually. Categories, description, reviews, services, profile activity, review responses, and other optimization signals.

Then another question started becoming more important.

Is this business visible in AI search too?

That is where I got the idea to combine traditional GBP auditing with AI visibility checks in one simple browser extension.

The extension is completely free to use for anyone.

You can try it here:

https://addons.mozilla.org/en-US/firefox/addon/gbp-audit-ai-visibility/

Why I Created It

I did not want to create another heavy SaaS tool that needs a login, database, dashboard, subscription, and multiple setup steps.

I wanted something simple.

Open a business profile.

Run an audit.

Check the issues.

See the score.

Check AI visibility.

Export the report.

Done.

That was the main goal.

When I started planning it, I focused on the things I normally check during a GBP audit, such as:

Profile completeness
Business categories
Business description
Reviews
Review recency
Review responses
Services
Profile activity

I then turned these checks into a scoring system so the user gets a simple health score instead of going through everything manually.

For example:

GBP Health Score

82 / 100

Strong review profile
Business description added
Relevant categories found

Needs more recent reviews
Review response rate can be improved

I wanted the score to be easy to understand.

A score alone is not very useful.

If the tool gives someone a score of 65, I also wanted it to explain why the score is 65 and what they can improve.

I Also Added AI Visibility

This was the part I found more interesting.

Local SEO is changing.

Businesses are still trying to rank on Google Maps and Google Search, but now people are also asking tools like ChatGPT and Gemini for recommendations.

Someone might search:

Best dentist near me

or:

Recommended roofing companies in Dallas

or:

Best local SEO agency for Google Business Profile optimization

So I started thinking about how I could include AI visibility inside the same audit.

The idea was not to replace traditional SEO metrics.

I just wanted to add another layer.

The extension checks AI-related visibility signals through external data sources using DataForSEO.

The flow is basically:

Business
   ↓
Relevant Search Query
   ↓
AI Visibility Data
   ↓
Business Mention Check
   ↓
Visibility Result

This gives the user a better idea of how the business is performing beyond normal GBP optimization.

How I Structured It

I kept the setup quite simple.

Google Search or Google Maps
            ↓
      Firefox Extension
            ↓
      GBP Audit Engine
            ↓
      AI Visibility Check
            ↓
      Cloudflare Worker
            ↓
         DataForSEO
            ↓
     Recommendations
            ↓
       PDF Report

I used a Cloudflare Worker because I did not want to expose private API credentials inside the browser extension.

One Important Thing I Learned About API Keys

While creating the extension, one thing was very clear.

API keys should never be placed directly inside browser extension JavaScript.

For example, this is a bad idea:

const API_KEY = "my-secret-api-key";

Anyone can inspect the extension files and find it.

So instead, I created a small Cloudflare Worker that works between the extension and the external API.

Firefox Extension
       ↓
Cloudflare Worker
       ↓
External API

The Worker handles the API request and keeps the private credentials away from the browser.

It can also help with things like:

Request validation
Authentication
Rate limiting
Error handling
Response formatting

For a lightweight extension, this setup worked well for me.

I Wanted to Keep It Free and Simple

Another important decision was keeping the tool free to use.

Anyone can install the extension and use it.

I did not want users to create an account just to run a basic GBP audit.

I also did not want to create unnecessary storage.

The workflow is simple:

Open profile
    ↓
Run audit
    ↓
Check results
    ↓
Export report

For this type of tool, I did not feel that permanent user data storage was necessary.

That also helped me avoid unnecessary complexity around:

User accounts
Databases
Saved personal data
Login systems
Monthly subscriptions
Extra hosting costs

Sometimes a simple tool is better than turning everything into a full SaaS product.

I Added PDF Reports Too

I also wanted the audit to be useful for agency work and client reporting.

So I added PDF report generation.

The user can run the audit and export the findings into a report.

A report can include things like:

Business Information

GBP Health Score

Audit Findings

Review Analysis

AI Visibility

Priority Issues

Recommended Actions

This is useful if someone wants to share the audit with a client, business owner, or internal team.

I Did Not Want It to Just Find Problems

Another thing I focused on was recommendations.

Finding an issue is easy.

Explaining what to do next is more useful.

For example, instead of only saying:

Low review activity

the extension can give a recommendation such as:

HIGH PRIORITY

Try to increase the frequency of new customer reviews.

Or:

MEDIUM PRIORITY

Improve the consistency of review responses.

Or:

LOW PRIORITY

Improve the business description.

This makes the audit more actionable.

AI Visibility Does Not Replace Local SEO

I do not see AI visibility as a replacement for SEO.

I see it as another layer of search visibility.

A business still needs strong fundamentals.

Things like:

Website content
Google Business Profile
Reviews
Local citations
Brand mentions
Structured data
Authority
Relevant content

all still matter.

I currently think about it like this:

Website
   +
Google Business Profile
   +
Reviews
   +
Citations
   +
Brand Mentions
   +
Structured Data
          ↓
     Entity Understanding
          ↓
 Google Search + AI Search

SEO, GEO, AI visibility, local SEO, and entity optimization are becoming more connected.

That is one reason I wanted to experiment with bringing these areas together in one tool.

What I Learned While Creating It

I learned quite a few things while creating this extension.

Keep the scoring understandable

If a user gets a score, they should understand how it was calculated.

Never expose private APIs

I used a Cloudflare Worker because API credentials should not be stored inside an extension.

Keep permissions limited

I tried to keep browser permissions focused only on what the extension actually needs.

Do not overbuild

I did not need a huge backend, user database, or login system for the first version.

AI visibility needs context

One AI mention does not automatically mean a business has strong AI visibility.

Location, query intent, entity recognition, relevance, and other factors all matter.

Start from a real problem

I think this was the biggest lesson.

I did not start by asking:

"What SaaS should I build?"

I started with:

"What task am I doing repeatedly that I can make easier?"

That question led to the extension.

What I Want to Add Next

This is still an early version, and I have more ideas for it.

Some things I am considering are:

Better AI visibility scoring
Competitor comparison
Entity analysis
Citation checks
Schema checks
AI recommendation tracking
Historical visibility tracking
More GBP recommendations

The bigger idea is to bring local SEO and AI search visibility into one simple workflow.

Try It for Free

The extension is free for anyone to use.

You can install it here:

GBP Audit AI Visibility by Lucky Digitals

https://addons.mozilla.org/en-US/firefox/addon/gbp-audit-ai-visibility/

If you work with local SEO, Google Business Profiles, agencies, AI visibility, or GEO, I would genuinely like to know what you think about it.

Feedback will help me improve the next version.

Connect With Me

I am Piyush Kumar Soni, and I like creating practical tools around AI, LLMs, automation, SEO, and search visibility.

GitHub
https://github.com/piyushsoni-ai

LinkedIn
https://www.linkedin.com/in/piyushkumarsoni/

Medium
https://medium.com/@piyushkrsoni

Substack
https://piyushkumarsoni.substack.com/

About.me
https://about.me/piyushkumarsoni

Personal Profile
https://piyushkumarsoni.carrd.co/

If you are building something around AI, RAG, agents, automation, SEO tools, GEO, or AI search visibility, feel free to connect.

How LLMs Can Automate Technical SEO Workflows

Piyush Kumar Soni — Thu, 20 Aug 2026 07:48:08 +0000

Technical SEO has always involved a strange mix of strategy and repetition.

The strategic side is interesting: understanding how a website is structured, identifying why important pages are not performing, deciding what deserves to be indexed, improving internal linking, and prioritizing fixes that actually affect organic growth.

The repetitive side is less exciting.

SEO teams repeatedly review title tags, meta descriptions, canonical URLs, heading structures, status codes, internal links, schema markup, indexability signals, and large spreadsheets of crawl data.

This is where Large Language Models can become genuinely useful.

I am Piyush Kumar Soni, an SEO Expert & AI/LLM Specialist, and much of my current work focuses on combining Technical SEO, Generative Engine Optimization (GEO), AI Search, LLM integration, RAG, Entity SEO, Schema Markup, and automation.

I do not see LLMs as a replacement for technical SEO expertise.

I see them as a layer that can sit on top of deterministic SEO data and help teams interpret, prioritize, automate, and communicate findings faster.

This article explains where that approach works well, where it does not, and how I think about building LLM-powered SEO workflows in practice.

The Right Way to Think About LLMs in Technical SEO

A common mistake is asking an LLM to "audit a website" without giving it structured data.

That usually results in generic recommendations such as:

improve page speed
optimize title tags
add schema markup
improve internal linking
make content helpful

None of those suggestions are necessarily wrong.

But they are not an audit.

A real technical SEO workflow should start with actual evidence.

For example:

URL: https://example.com/product-a

Status: 200
Canonical: https://example.com/product-a
Robots: index, follow
Title: Product A | Example
Meta description: "Missing"
H1: Product A
Internal links pointing to page: 2
Structured data: Product
Word count: 430
Crawl depth: 5

Now an LLM has something useful to work with.

The architecture should look more like this:

Website
   ↓
Crawler / SEO API
   ↓
Structured SEO Data
   ↓
Rules & Validation
   ↓
LLM
   ↓
Interpretation / Prioritization
   ↓
Report or Workflow Action

The LLM is not replacing the crawler.

It is interpreting what the crawler found.

That distinction matters.

1. Automating SEO Issue Explanations

Most SEO crawlers are very good at identifying problems.

They can tell you:

174 pages are missing meta descriptions.

The crawler has done its job.

But somebody still needs to explain:

why that matters
which pages matter most
whether it deserves immediate attention
what the recommended action should be

An LLM can turn structured crawl findings into clear explanations.

For example, we could provide:

{
  "issue": "missing_meta_description",
  "affected_pages": 174,
  "important_commercial_pages": 12,
  "severity": "medium"
}

The LLM could generate:

174 pages are missing meta descriptions, including 12 commercially important landing pages. Missing descriptions do not directly prevent indexing, but they reduce control over how these pages may appear in search results. Prioritize high-value landing pages before informational or low-traffic URLs.

That saves time without changing the underlying technical diagnosis.

2. Prioritizing Large SEO Audits

A technical audit can easily produce thousands of individual findings.

The challenge is rarely:

"Can we find SEO issues?"

The harder question is:

"Which issues should we fix first?"

This is one of the most useful applications for LLMs.

Instead of asking the model to invent priorities, give it structured context.

For example:

{
  "issue": "orphan_page",
  "pages_affected": 84,
  "page_type": "product",
  "organic_traffic": "high",
  "conversion_value": "high",
  "crawl_depth": null
}

Compare that with:

{
  "issue": "long_title",
  "pages_affected": 250,
  "page_type": "blog",
  "organic_traffic": "low",
  "conversion_value": "low"
}

A good workflow should prioritize the orphaned commercial pages before spending time shortening low-value blog titles.

The LLM can help group findings into categories such as:

Critical

important URLs blocked from indexing
broken canonical implementation
widespread server errors
accidental noindex directives
redirect chains affecting important pages

High

orphaned commercial pages
broken internal links
duplicate pages competing for the same intent
important pages buried deep in site architecture

Medium

missing metadata
weak heading structures
underlinked informational content

Low

minor formatting inconsistencies
cosmetic metadata opportunities

The model should not make these decisions blindly.

It should be given business and SEO context.

3. Metadata Analysis at Scale

Title tags and meta descriptions are simple until you have 50,000 URLs.

At that point, manual review becomes expensive.

An LLM-powered workflow can help classify metadata into categories such as:

missing
duplicated
generic
mismatched with page intent
overly repetitive
weakly differentiated
potentially templated incorrectly

Imagine sending this data:

URL: /services/technical-seo
Title: SEO Services
H1: Technical SEO Services
Primary topic: Technical SEO
Page type: Service

A model can identify that the title is technically present but poorly aligned with the page's actual topic.

That is different from a simple character-count rule.

A deterministic rule can say:

Title exists.

An LLM can say:

The title is too generic compared with the page's H1 and topic.

This is where the combination becomes powerful.

4. Internal Linking Recommendations

Internal linking is another strong use case.

Traditional tools can show which pages have very few incoming internal links.

An LLM can help determine where relevant links could come from.

Suppose we have a target page:

Target:
Technical SEO Audit Services

Topic:
Technical SEO, site audits, crawlability, indexation

And possible source pages:

1. Complete Guide to Technical SEO
2. How to Fix Crawl Errors
3. Social Media Marketing Tips
4. Schema Markup Guide
5. Local SEO Checklist

The LLM can rank relevant internal-link opportunities based on semantic similarity.

It can also suggest natural anchor text such as:

technical SEO audit
professional SEO audit
identifying technical SEO issues

Again, human review still matters.

But the discovery process becomes much faster.

5. Schema Markup Generation

Schema markup is a natural area for automation because the output is structured.

For example, if we know:

{
  "name": "Piyush Kumar Soni",
  "jobTitle": "SEO Expert & AI/LLM Specialist",
  "url": "https://example.com/piyush",
  "worksFor": "Example Company"
}

an LLM can help generate a Person schema template.

But I would never stop there.

The workflow should validate the JSON-LD after generation.

The architecture should be:

Entity Data
   ↓
LLM Schema Generation
   ↓
JSON Validation
   ↓
Schema Rules
   ↓
Final Output

Do not blindly publish generated structured data.

LLMs can produce valid-looking JSON that contains inaccurate relationships or unsupported properties.

Schema automation should therefore combine:

LLM generation + deterministic validation + human review.

6. Entity Extraction for SEO and AI Search

Entity SEO becomes particularly interesting as search systems increasingly use semantic relationships rather than isolated keywords.

An LLM can extract entities from content such as:

people
organizations
products
locations
technologies
services
concepts

For example, from a professional profile it could identify:

Person:
Piyush Kumar Soni

Organization:
Lucky Digitals

Expertise:
Technical SEO
Generative Engine Optimization
AI Search
Large Language Models
RAG
Schema Markup
SEO Automation

This can help teams examine whether their content consistently communicates important relationships.

That is useful for traditional search, knowledge graph clarity, and AI-driven retrieval systems.

7. GEO and AI Search Auditing

Generative Engine Optimization is still an evolving area.

I would be careful about anyone claiming there is a simple checklist that guarantees citations in ChatGPT, Gemini, Perplexity, or other AI systems.

There isn't.

However, we can audit factors that make information easier to interpret and retrieve.

An LLM-assisted GEO audit might examine whether:

the author is clearly identified
the organization is clearly identified
expertise is explicit
important entities are connected consistently
claims are supported
sources are cited
pages answer specific questions directly
structured data supports visible content
topics are covered with enough depth
terminology is consistent across pages

For example:

Person → worksFor → Organization

Person → knowsAbout → Technical SEO

Person → knowsAbout → AI Search

Article → author → Person

These relationships can help create a clearer entity footprint.

The point is not to "trick an LLM."

The point is to make information less ambiguous.

8. SEO Reporting Automation

SEO reporting consumes a surprising amount of agency time.

Data might come from:

Google Search Console
Google Analytics
Ahrefs
Semrush
crawlers
rank trackers
spreadsheets

The challenge is combining these sources into a useful narrative.

An LLM can summarize structured metrics.

For example:

{
  "organic_clicks_change": "+18%",
  "impressions_change": "+24%",
  "average_position_change": "-1.8",
  "technical_errors_fixed": 34,
  "new_top_10_keywords": 12
}

The model could generate:

Organic search performance improved during the period, with clicks increasing 18% and impressions rising 24%. Average ranking position improved by 1.8 positions, while 34 technical issues were resolved. Twelve additional keywords entered the top 10.

This type of automation is especially useful because the numbers come from deterministic sources.

The LLM is simply making them easier to understand.

9. Turning SEO Data Into Developer Tasks

SEO recommendations often fail at implementation.

An SEO says:

Fix canonicalization.

The developer asks:

Where? How? Which URLs? What is the expected behavior?

An LLM can translate SEO findings into more actionable tickets.

Instead of:

Canonical issue found.

the workflow could generate:

Issue:
Category pages are self-canonicalizing correctly, but paginated URLs point to page 1.

Affected templates:
category-pagination.php

Expected behavior:
Each indexable paginated URL should use an appropriate self-referencing canonical unless the SEO strategy specifies otherwise.

Example:
Current:
/category/page/3 → canonical /category/

Expected:
/category/page/3 → canonical /category/page/3/

That is significantly more useful to development teams.

10. Building SEO Content Briefs

Content workflows are another obvious application.

SEO tools can provide:

target keywords
related queries
competing pages
search intent
entities
subtopics

An LLM can combine those inputs into a structured brief.

For example:

Primary topic:
AI-powered SEO audits

Related topics:
Technical SEO
Python
LLMs
SEO automation
Schema
Internal linking
RAG

Intent:
Informational / technical

Then the model can create:

proposed title
search intent summary
recommended sections
questions to answer
entities to cover
supporting examples
internal-link suggestions

But the brief should be based on collected data.

Otherwise we are back to generic AI-generated content.

11. RAG for Internal SEO Knowledge

One of the more advanced applications is combining technical SEO automation with Retrieval-Augmented Generation.

Imagine an SEO agency has:

internal SOPs
audit templates
client documentation
past recommendations
development standards
schema guidelines

Instead of relying only on the model's general knowledge, the system can retrieve relevant internal documentation before generating recommendations.

The workflow becomes:

Technical SEO Finding
         ↓
Search Internal Knowledge Base
         ↓
Retrieve Relevant SOP
         ↓
LLM
         ↓
Context-Aware Recommendation

This allows recommendations to follow the organization's actual processes.

For example, an agency may have a specific canonicalization policy.

RAG can retrieve that policy before producing the recommendation.

That is much more useful than asking a generic model what to do.

12. AI Agents for SEO Workflows

Once individual automations are working reliably, they can be connected into agent-style workflows.

For example:

Crawl Agent
     ↓
Technical Analysis Agent
     ↓
Entity Analysis Agent
     ↓
Internal Linking Agent
     ↓
Report Agent

I would still keep critical SEO checks deterministic.

The agents should orchestrate tasks, not invent facts.

A safer architecture is:

SEO Tools / APIs
      ↓
Verified Data
      ↓
AI Agents
      ↓
Analysis & Recommendations
      ↓
Human Approval
      ↓
Implementation

That human approval layer matters.

What LLMs Should NOT Automate Blindly

Automation is useful until it creates more problems than it solves.

I would not allow an LLM to automatically:

redirect large numbers of URLs
change canonical tags sitewide
add noindex directives
delete content
rewrite important commercial pages
change robots.txt
modify structured data at scale
change internal linking across thousands of pages

without validation and approval.

These decisions can have significant SEO consequences.

AI should accelerate the workflow.

It should not remove accountability.

A Practical LLM + SEO Stack

A simple stack might include:

Data Collection

Screaming Frog
Sitebulb
custom Python crawler
Google Search Console API
Google Analytics API

Processing

Python
Pandas
SQL

LLM Layer

OpenAI API
other LLM APIs
LangChain where orchestration is useful

RAG

embeddings
vector database
internal SEO documentation

Output

Google Sheets
CSV
dashboards
client reports
project-management tasks

You do not need all of these at once.

Start with one repetitive task.

Automate it well.

Then expand.

The Bigger Opportunity: SEO + AI

The most interesting part of this shift is not that AI can write title tags faster.

That is useful, but small.

The bigger opportunity is building systems that connect:

Technical SEO

Entity SEO

Generative Engine Optimization

AI Search

Structured Data

LLM Integration

RAG

Automation

SEO professionals already work with large amounts of structured and unstructured information.

LLMs are very good at working with that type of information when they are given the right context.

That makes SEO a natural environment for practical AI automation.

Final Thoughts

LLMs can automate a significant portion of technical SEO workflows, but the strongest systems do not ask the model to do everything.

Use crawlers and APIs to collect facts.

Use code and rules to validate those facts.

Use LLMs to interpret, classify, prioritize, summarize, and communicate.

Use SEO professionals to make the final strategic decisions.

That combination is much more reliable than trying to build a completely autonomous "AI SEO expert."

The future of technical SEO is unlikely to be humans versus AI.

It looks much more like:

SEO expertise + reliable data + automation + LLM intelligence.

And that is exactly where some of the most interesting SEO engineering work is happening right now.

About the Author

Piyush Kumar Soni is an SEO Expert & AI/LLM Specialist with 15+ years of experience across SEO, web development and digital marketing. He works on Technical SEO, GEO, AI Search, LLM integration, SEO automation, Entity SEO, Schema Markup, RAG and AI agents.

Learn more: Piyush Kumar Soni

RAG for Beginners: Build a Document Q&A System with LangChain (Full Code)

Piyush Kumar Soni — Sun, 19 Jul 2026 08:11:29 +0000

RAG for Beginners: Build a Document Q&A System with LangChain (Full Code)

Tags: #ai #langchain #python #tutorial

LLMs don't know your private documents. ChatGPT can write you an essay about quantum computing, but it has zero idea what's in your company's internal wiki, your client reports, or that PDF you saved last Tuesday — unless you paste it in yourself, every single time.

RAG (Retrieval-Augmented Generation) fixes this. This post walks through the concept and a full working code example you can run today.

The Architecture

Your Documents  →  Split into chunks  →  Convert to embeddings  →  Stored in a vector database
                                                                              ↓
User's Question  →  Convert to embedding  →  Find closest matching chunks  →  Send question + chunks to LLM  →  Answer

Two steps, really: retrieval (find the relevant pieces of your data) and generation (let the LLM answer using those pieces instead of guessing from training data alone).

Setup

pip install langchain langchain-community langchain-openai faiss-cpu

You'll also need an OPENAI_API_KEY environment variable set:

export OPENAI_API_KEY="your-key-here"

Full Working Example — Text Document

from langchain_community.document_loaders import TextLoader
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain_community.vectorstores import FAISS
from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain.chains import RetrievalQA

# 1. Load your document
loader = TextLoader("client_seo_report.txt")
documents = loader.load()

# 2. Split into chunks — LLMs work better with focused chunks than walls of text
splitter = RecursiveCharacterTextSplitter(
    chunk_size=500,
    chunk_overlap=50  # overlap prevents cutting a key sentence in half
)
chunks = splitter.split_documents(documents)

# 3. Convert chunks into embeddings and store them in a local vector index
embeddings = OpenAIEmbeddings()
vector_store = FAISS.from_documents(chunks, embeddings)

# 4. Wire up retrieval + generation
llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)
qa_chain = RetrievalQA.from_chain_type(
    llm=llm,
    retriever=vector_store.as_retriever(search_kwargs={"k": 4})  # top 4 matching chunks
)

# 5. Ask a question about YOUR document
answer = qa_chain.invoke("What was the biggest traffic change this month?")
print(answer["result"])

That's a complete, runnable RAG pipeline in about 20 lines.

Swapping in a PDF Instead of Plain Text

Most real documents aren't .txt files. Swapping the loader is the only change needed:

from langchain_community.document_loaders import PyPDFLoader

loader = PyPDFLoader("client_seo_report.pdf")
documents = loader.load()

# everything else in the pipeline stays exactly the same

LangChain has loaders for most formats you'll actually run into — Docx2txtLoader for Word docs, CSVLoader for spreadsheets, WebBaseLoader for scraping a URL directly. Same downstream pipeline every time.

Why `chunk_size` and `chunk_overlap` Matter More Than They Look Like They Should

This trips up almost everyone the first time:

Chunk size too large → retrieval pulls back a lot of irrelevant surrounding text along with the useful part, and the LLM's answer gets muddier.
Chunk size too small → you lose context; a chunk might not contain enough surrounding information to be useful on its own.
No overlap → you can accidentally split a sentence's meaning exactly at the point where the important information was.

There's no universal "correct" number — 500 characters with 50 overlap is a reasonable starting point for report-style text, but experiment for your actual documents.

Common Mistakes (Beyond Chunking)

Expecting perfect retrieval on the first try. Sometimes the "closest match" by embedding similarity isn't actually the most relevant chunk for the question. This is normal — tuning retrieval quality is where most of the real engineering effort goes, well past this example.
Not filtering by metadata. If you're indexing documents from multiple clients or time periods, tag your chunks with metadata (client_name, date) so you can filter the search instead of searching everything every time:

vector_store.as_retriever(
    search_kwargs={"k": 4, "filter": {"client_name": "acme_corp"}}
)

Using the wrong k value. Too few retrieved chunks (k=1 or 2) and the LLM might not have enough context. Too many (k=10+) and you're paying for tokens the model doesn't need and diluting the relevant signal. k=3 to k=5 is a reasonable starting range.

Where This Goes Next

Once this basic pattern works, natural next steps:

Try a production-grade vector store (Pinecone, Chroma, or Weaviate) instead of local FAISS once you need this to scale or persist across sessions
Add metadata filtering as shown above once you're indexing more than one source
Experiment with hybrid search (combining keyword search with embedding similarity) — pure embedding search sometimes misses exact-match terms like product names or codes

I'm covering agents next — giving an LLM the ability to actually take actions instead of just answering questions. RAG is the foundation a lot of that builds on, so if this made sense, you're already most of the way there.

If you build this and hit a snag, drop a comment — happy to help debug.

I'm Piyush Kumar Soni, an AI Developer and LLM Integration Expert with 15+ years running digital agency operations. I write about practical AI tools for SEO and digital marketing.

🔗 LinkedIn · 💻 GitHub · 📰 Substack

Build Your First LLM Tool: A Beginner's Guide to LangChain

Piyush Kumar Soni — Sat, 18 Jul 2026 07:14:17 +0000

Build Your First LLM Tool: A Beginner’s Guide to LangChain

Building an LLM application can sound complicated, but your first working tool may require fewer than 15 lines of Python.

In this tutorial, we’ll build a simple AI explainer using LangChain and an OpenAI model.

Why Use LangChain Instead of Calling the OpenAI API Directly?

Calling an AI model directly is perfectly reasonable for a small script. You send a prompt, receive a response, and display it.

The complexity begins when your application needs:

Reusable prompt templates
Structured output
Multiple model providers
Documents or external data
Conversation history
Tools and agents
Logging and debugging

LangChain provides a standard interface for composing these pieces. It also makes switching between supported providers easier because your application does not need to be completely rewritten around each provider’s API. (Docs by LangChain)

Think of the raw API as an engine. LangChain gives you reusable parts for building the rest of the vehicle.

Install the Required Packages

pip install langchain langchain-openai python-dotenv

Create a .env file:

OPENAI_API_KEY=your_api_key_here

Never commit this file or expose your API key in a public repository. OpenAI recommends storing API keys securely rather than placing them directly inside source code. (OpenAI Platform)

Build a Basic LangChain Chain

Create a file named app.py:

from dotenv import load_dotenv
from langchain_core.output_parsers import StrOutputParser
from langchain_core.prompts import ChatPromptTemplate
from langchain_openai import ChatOpenAI

load_dotenv()

prompt = ChatPromptTemplate.from_template(
    "Explain {topic} to a beginner using one example."
)

model = ChatOpenAI(model="gpt-5-nano")
chain = prompt | model | StrOutputParser()

print(chain.invoke({"topic": "vector databases"}))

Run it:

python app.py

The chain has three simple steps:

Insert the topic into the prompt.
Send the formatted prompt to the model.
Convert the model response into a normal Python string.

The | operator connects each component into a readable pipeline. The current LangChain OpenAI integration is provided through the separate langchain-openai package and its ChatOpenAI class. (Docs by LangChain)

Where Should You Go Next?

Once this basic chain works, explore two important areas.

RAG, or Retrieval-Augmented Generation, lets your application retrieve information from PDFs, webpages, databases, or company documents before generating an answer.

Agents allow a model to decide when to call tools such as search functions, APIs, calculators, or custom Python functions. LangChain currently provides configurable agent-building functionality for connecting models with tools and application logic. (Docs by LangChain)

You can also turn your script into a web interface using Gradio and publish it through Hugging Face Spaces.

Here are two live examples from my own AI-tool experiments:

Start with one prompt and one model. Get that working first. Then add memory, retrieval, tools, and agents only when your application genuinely needs them.

About the author: Piyush Kumar Soni is an AI Developer, LLM Expert and Digital Growth Specialist building practical AI tools, automation systems and LLM-powered workflows.

Suggested Dev.to tags: ai, langchain, python, beginners

This article follows the Dev.to and topical-authority direction in your SERP plan, including the focus on LangChain development, Python-based AI tools and Hugging Face demos. Your supplied profile list confirms the two live Hugging Face Space URLs used above.

DEV Community: Piyush Kumar Soni

I Created a Free Firefox Extension to Audit Google Business Profiles and AI Visibility

Why I Created It

I Also Added AI Visibility

How I Structured It

One Important Thing I Learned About API Keys

I Wanted to Keep It Free and Simple

I Added PDF Reports Too

I Did Not Want It to Just Find Problems

AI Visibility Does Not Replace Local SEO

What I Learned While Creating It

Keep the scoring understandable

Never expose private APIs

Keep permissions limited

Do not overbuild

AI visibility needs context

Start from a real problem

What I Want to Add Next

Try It for Free

Connect With Me

How LLMs Can Automate Technical SEO Workflows

The Right Way to Think About LLMs in Technical SEO

1. Automating SEO Issue Explanations

2. Prioritizing Large SEO Audits

Critical

High

Medium

Low

3. Metadata Analysis at Scale

4. Internal Linking Recommendations

5. Schema Markup Generation

6. Entity Extraction for SEO and AI Search

7. GEO and AI Search Auditing

8. SEO Reporting Automation

9. Turning SEO Data Into Developer Tasks

10. Building SEO Content Briefs

11. RAG for Internal SEO Knowledge

12. AI Agents for SEO Workflows

What LLMs Should NOT Automate Blindly

A Practical LLM + SEO Stack

Data Collection

Processing

LLM Layer

RAG

Output

The Bigger Opportunity: SEO + AI

Final Thoughts

RAG for Beginners: Build a Document Q&A System with LangChain (Full Code)

RAG for Beginners: Build a Document Q&A System with LangChain (Full Code)

The Architecture

Setup

Full Working Example — Text Document

Swapping in a PDF Instead of Plain Text

Why chunk_size and chunk_overlap Matter More Than They Look Like They Should

Common Mistakes (Beyond Chunking)

Where This Goes Next

Build Your First LLM Tool: A Beginner's Guide to LangChain

Build Your First LLM Tool: A Beginner’s Guide to LangChain

Why Use LangChain Instead of Calling the OpenAI API Directly?

Install the Required Packages

Build a Basic LangChain Chain

Where Should You Go Next?

Why `chunk_size` and `chunk_overlap` Matter More Than They Look Like They Should