DEV Community: sepideh jafari

Canonical Tags Can't Fix a Bad Website Architecture

sepideh jafari — Fri, 25 Sep 2026 20:30:00 +0000

Canonical tags are powerful.

They're also misunderstood.

A canonical tells search engines which URL you consider the preferred version among similar or duplicate pages.

What it doesn't do is magically repair an uncontrolled website architecture.

Canonical Is a Signal, Not a Cleanup Tool

Imagine an application generates 100 variations of the same page.

You canonicalize all 100 to one URL.

That's better than leaving them ambiguous.

But those 100 URLs may still:

be crawlable,
receive internal links,
appear in logs,
consume crawling,
and create unnecessary complexity.

The canonical tag didn't remove the architecture.

It clarified preference.

Ask Why the Duplicate Exists

Whenever I see large-scale canonicalization, I want to ask:

Why can these alternative URLs exist?

Sometimes there's a good reason.

Parameters.

Tracking.

Valid product variants.

Pagination.

Sometimes there isn't.

The application simply creates multiple paths to the same resource.

Self-Canonicals Matter Too

Canonical tags aren't only for duplicates.

A clean indexable page generally benefits from clearly declaring itself as canonical.

That creates consistency.

Especially across templates.

Canonical Problems Are Often Template Problems

If five pages have incorrect canonicals, check the pages.

If 5,000 pages have incorrect canonicals, check the code generating them.

This distinction matters.

Technical SEO at scale is often about identifying the system producing the error.

Google Can Ignore Your Canonical

Canonical tags aren't commands.

Search engines can select a different canonical when other signals disagree.

Internal links, redirects, sitemap entries, duplicate content, and URL consistency all contribute.
That's another reason architecture matters.
The Bigger Lesson
Canonical tags work best inside a clean system.
Don't ask canonicalization to compensate for URL behavior that should have been fixed at the architecture level.

Why Publishing More Content Doesn't Guarantee More Traffic

sepideh jafari — Tue, 22 Sep 2026 06:30:00 +0000

Producing content has never been easier.

AI can generate outlines, drafts, summaries, FAQs, and topic ideas in seconds.

That sounds like great news for SEO.

And it can be.

But there's a dangerous assumption hiding behind the excitement:

If we publish more pages, we'll get more organic traffic.

That's not how search works.

More content only helps when those pages add useful coverage to the website.

Otherwise, scale can simply multiply existing SEO problems.

More URLs Don't Mean More Search Visibility

Imagine a website publishing 1,000 articles.

That number sounds impressive.

But what if 300 of them target nearly identical search intent?

What if hundreds have almost no internal links?

What if multiple pages compete for the same query?

What if Google sees dozens of pages answering essentially the same question?

The website has more content.

It doesn't necessarily have more value.

Content Cannibalization Often Starts With Planning

Cannibalization is often discovered after publishing.

I prefer thinking about it before publishing.

Before creating a new article, I want to know:

What exact intent does it satisfy?
Which existing page is closest to that intent?
Should this become a new page or improve an existing one?
Where does it sit in the topic architecture?

This becomes increasingly important as content libraries grow.

AI Makes Architecture More Important

AI reduces the cost of creating content.

That makes information architecture more valuable.

If publishing becomes 10x faster while planning stays the same, websites can create technical and editorial debt 10x faster too.

The bottleneck moves.

Writing becomes easier.

Deciding what deserves a page becomes harder.

A Real Content Platform Example

I've seen this challenge clearly while working with SefidSiah, a growing Persian health content platform.

Health topics naturally overlap.

A broad subject can contain symptoms, conditions, exercises, warning signs, lifestyle questions, and highly specific searches.

Without a clear topic model, it's easy to create several articles that look different editorially but satisfy nearly the same search intent.

That's why content growth needs to be connected to architecture.

Internal Linking Can't Be an Afterthought

Publishing an article doesn't automatically integrate it into the site.

A new page needs relationships.

It should connect to relevant parent topics, supporting articles, and related content.

Otherwise, a site can accumulate hundreds of isolated pages.

This is why I increasingly think of content as a graph rather than a list.

Measure Useful Coverage, Not Article Count

“500 articles published” is a production metric.

It doesn't tell you whether SEO improved.

What SEOs Should Know About JavaScript Websites

sepideh jafari — Sun, 20 Sep 2026 06:30:00 +0000

What SEOs Should Know About JavaScript Websites

Modern websites increasingly behave like applications.

For SEO specialists, that changes what we need to understand.

You don't need to become a JavaScript engineer.

But if you're auditing modern websites without understanding how JavaScript applications create pages, links, metadata, and routes, you're increasingly working with only part of the picture.

View Source Isn't the Whole Website

One of the first things to understand is that the initial HTML response and the final rendered page may not be identical.

JavaScript can modify the page after the initial response.

That means an SEO audit may need to distinguish between:

Response HTML

and

Rendered DOM

This matters when investigating content, links, metadata, and other elements generated client-side.

Rendering Strategy Matters

Modern frameworks provide several rendering approaches.

Pages may be:

server-rendered,
statically generated,
client-rendered,
incrementally generated,
or use a combination of strategies.

From an SEO perspective, the important question isn't which acronym sounds best.

It's:

What does the crawler receive, and when?

A JavaScript framework isn't automatically bad for SEO.

Poor implementation is.

Links Need to Behave Like Links

Interactive interfaces make it easy to create navigation that works perfectly for users but isn't represented in the way crawlers expect.

A clickable element and a crawlable link aren't always the same thing.

When auditing navigation, I want to know whether important destinations are exposed through proper links and whether crawlers can discover them reliably.

This becomes particularly important for:

pagination,
category navigation,
related content,
breadcrumbs,
and product discovery.
Metadata Should Be Predictable

Modern frameworks can generate metadata dynamically.

That's powerful.

It also means one incorrect function can generate incorrect metadata across thousands of pages.

Instead of checking only one page, SEOs should think in templates.

How does the application generate:

titles,
descriptions,
canonicals,
robots directives,
Open Graph data,
and structured data?

Template-level problems have template-level consequences.

Routing Is SEO Architecture

Frontend routing decisions can determine which URLs exist.

Optional parameters, dynamic routes, filters, slugs, trailing slashes, capitalization, and redirects all affect how search engines interpret the site.

This is why technical SEO increasingly overlaps with application architecture.

Sometimes the most important SEO question isn't:

“What keyword should this page target?”

It's:

“Why can this URL exist?”

Performance Isn't the Entire JavaScript SEO Story

JavaScript SEO conversations often become Core Web Vitals conversations.

Performance matters.

But a fast website can still have serious SEO problems.

It can have:

incorrect canonicals,
inaccessible internal links,
duplicate routes,
uncontrolled parameters,
broken structured data,
or poor indexation rules.

Performance is one layer.

Search architecture is another.

Learn Enough to Ask Better Questions

I don't think every SEO specialist needs to build React applications.

But understanding concepts such as:

rendering,
routing,
hydration,
API-driven content,
HTTP responses,
DOM changes,
and client-side navigation

makes technical conversations dramatically easier.

You become better at separating:

SEO symptoms

from

application causes.

And that's increasingly important because modern SEO problems often originate in the application layer.

The Bigger Lesson

SEO specialists don't need to become developers.

But the web has changed.

Websites are becoming applications, and search engines still need to discover and understand the documents those applications create.

Understanding a little more about how those systems work makes technical SEO much more effective.

You don't need to write the framework. You need to understand what the framework is doing to the website search engines see.

Technical SEO Problems AI Can Detect but Shouldn't Fix Alone

sepideh jafari — Wed, 16 Sep 2026 06:30:00 +0000

AI is becoming surprisingly good at finding technical SEO problems.

Give it a crawl export and it can identify unusual URL patterns, duplicate metadata, redirect chains, canonical inconsistencies, orphan-page candidates, and many other anomalies.

That's useful.

But there's an important distinction:

Detecting an SEO problem and deciding how to fix it are two different tasks.

The first is increasingly easy to automate.

The second still requires context.

Detection Is Becoming Cheap

A technical crawl can contain hundreds of thousands of rows.

Manually reviewing every URL isn't realistic.

AI can help classify this information quickly.

For example, it can help identify:

parameterized URLs,
non-indexable sitemap URLs,
unusual status-code patterns,
duplicate titles,
canonical mismatches,
deep pages,
redirect chains,
and inconsistent templates.

These are excellent uses of AI because we're asking it to identify patterns.

We're not yet asking it to change the website.

A Canonical Problem Isn't Always a Canonical Fix

Imagine AI discovers 5,000 URLs canonicalizing to another URL.

It might classify them as canonical problems.

But are they?

Maybe they're legitimate parameter variations.

Maybe they're duplicate product routes.

Maybe they're tracking URLs.

Maybe the application shouldn't generate them at all.

Changing the canonical tag might hide the symptom without addressing the cause.

Before fixing a canonical issue, I want to understand:

Why does this alternative URL exist?

That's an architecture question.

Redirects Need Context Too

AI can easily identify a redirect chain:

A → B → C

And recommending:

A → C

may be perfectly reasonable.

But things become more complicated when URLs have changed because products were removed, categories were reorganized, or an entire website was migrated.

The technically shortest redirect isn't automatically the most relevant destination.

Search intent still matters.

Robots.txt Recommendations Can Be Dangerous

This is an area where I would be particularly careful with automated fixes.

A crawler discovers thousands of unwanted URLs.

The obvious recommendation becomes:

Block them in robots.txt.

But blocking crawling and controlling indexing aren't the same thing.

And if Google needs to crawl a URL to observe another directive, blocking access can complicate the situation.

The correct solution depends on why those URLs exist and what you want search engines to do with them.

AI Is Excellent for Prioritizing Investigation

Instead of asking AI:

“Fix my technical SEO.”

I prefer asking:

“Which patterns in this dataset deserve investigation first?”

That's a much better role for it.

AI can reduce a massive dataset into a manageable list of hypotheses.

Then I can verify those hypotheses using:

crawl data,
Search Console,
rendered HTML,
response headers,
server logs,
and application behavior.

AI helps narrow the search space.

Evidence decides what happens next.

The Real Risk Is Confident Automation

The dangerous part isn't that AI makes mistakes.

Humans make mistakes too.

The dangerous part is how confidently automated recommendations can move from:

Observation → Recommendation → Deployment

without anyone verifying the middle step.

Technical SEO changes can affect thousands of URLs simultaneously.

A wrong title recommendation affects one page.

A wrong canonical template can affect an entire site.

That's why automation should become more cautious as the potential blast radius increases.

My Rule

The larger the scope of a proposed technical SEO change, the more evidence I want before implementing it.

AI can detect.

AI can classify.

AI can suggest.

AI can explain.

But architecture-level changes still deserve human verification.

The goal isn't to remove AI from technical SEO. It's to use it where speed helps without outsourcing the decisions where context matters most.

What I Check Before an E-Commerce Website Migration

sepideh jafari — Tue, 15 Sep 2026 20:30:00 +0000

Website migrations make me nervous.

Not because migrations are bad.

Because they can change many SEO signals at the same time.

A store can keep the same products and branding while changing URLs, templates, rendering, internal links, metadata, canonicals, structured data, and sitemap behavior.

That's a lot of moving parts.

I Start With the URL Map

Before launch, I want to know which URLs are changing.

Not approximately.

Actually mapped.

Important old URLs should have known destinations.

For example:

Old product → New product
Old category → New category
Old brand → New brand

This prevents redirect decisions from being improvised after launch.

I Crawl the Old Website

Before changing the site, I want a snapshot.

That crawl becomes a reference point.

Useful data includes:

status codes,
titles,
descriptions,
canonicals,
headings,
internal links,
indexability,
structured data,
and crawl depth.

Once the new site launches, I can compare.

Redirects Need Relevance

A migration often creates removed or changed URLs.

The easiest solution is sometimes sending everything to the homepage.

That's rarely the best solution.

A redirect should preserve intent whenever possible.

A product should go to its replacement or relevant category, not automatically to the homepage.

Canonicals Need Template-Level Testing

One incorrect canonical implementation can affect thousands of pages.

So I don't just inspect one product.

I test templates.

Products.

Categories.

Brands.

Pagination.

Parameter states.

The goal is understanding the rule generating canonicals.

A Real Migration Example

This became particularly important while working on AsanGSM, where an e-commerce site moved from WordPress to a Next.js architecture.

That type of migration makes it obvious that changing technology and preserving search signals are two separate jobs.

The frontend can work perfectly while SEO behavior changes underneath.

Sitemaps Need Revalidation

After migration, the sitemap should contain URLs that are:

canonical,

indexable,

successful,

and intended for search.

Redirects and non-indexable pages shouldn't casually remain there.

Structured Data Can Break Quietly

Product pages can look normal while structured data becomes incomplete.

That's why schema should be retested after migration.

Especially Product and Offer information.

The Bigger Lesson

A migration isn't complete when the new website works.

It's complete when users and search engines can understand the new architecture correctly.

Crawl Budget Is Often an Architecture Problem

sepideh jafari — Sun, 13 Sep 2026 20:37:03 +0000

Crawl budget sounds like a Google problem.

Sometimes it's actually a website problem.

When crawlers spend time on thousands of low-value URLs, the immediate instinct is often:

How do we make Google crawl differently?

A better first question may be:

Why does the website expose these URLs?

Crawlers Follow What You Give Them

Websites can generate huge crawl spaces through:

parameters,
faceted navigation,
calendars,
search results,
pagination,
duplicate routes,
session states,
and inconsistent linking.

Google didn't invent those URLs.

The application did.

Robots.txt Isn't Always the First Fix

Blocking URLs can reduce crawling.

But it doesn't necessarily solve the reason those URLs exist.

And crawling and indexing are different processes.

Before blocking anything, understand the desired outcome.

Do you want the URL:

not crawled?

not indexed?

canonicalized elsewhere?

removed entirely?

Those are different problems.

Internal Links Matter

If your own site links heavily to low-value URLs, crawlers will keep discovering them.

That's an architecture signal.

Fixing internal discovery paths can sometimes be more meaningful than adding another directive.

Sitemaps Matter Too

A sitemap should reinforce your preferred architecture.

If it contains low-value or non-indexable URLs, you're explicitly asking search engines to discover pages you may not want indexed.

That's contradictory.

Small Sites Can Have Crawl Problems Too

Crawl budget discussions often focus on huge websites.

But even smaller sites can create inefficient crawl spaces through poorly controlled parameters.

The issue isn't only total page count.

It's the relationship between valuable pages and discoverable URLs.

Logs Can Show Reality

Crawlers tell us what can be discovered.

Server logs can show what bots are actually requesting.

That difference is useful.

If Google repeatedly requests URLs you consider low value, logs can help identify the pattern.

Then the investigation moves back into architecture.

Where are those URLs coming from?

The Bigger Lesson

Crawl optimization isn't about trying to control Google with dozens of rules.

It's about building a website where valuable pages are easy to discover and unnecessary URL states are difficult to generate.

Good crawl efficiency starts with good architecture.

Why SaaS SEO Should Start Before the Product Is Finished

sepideh jafari — Sun, 13 Sep 2026 20:26:35 +0000

SEO is often treated as something that happens after launch.

Build the product.

Launch the website.

Then bring in SEO.

For SaaS, I increasingly think that's backwards.

Search architecture can influence the way public pages, application routes, features, and use cases are organized.

Those decisions are easier to make early.

Your Product Creates Searchable Concepts

A SaaS product has:

features,

audiences,

use cases,

problems,

workflows,

and integrations.

Some of those concepts correspond to real search demand.

If you understand that before building the marketing site, you can design a much stronger architecture.

Authentication Routes Don't Need Search Visibility

A SaaS application may contain:

registration,

dashboards,

profiles,

settings,

and private application states.

Those routes have a purpose.

But they're usually not acquisition pages.

Separating public search pages from private application routes early prevents later indexation problems.

Landing Pages Need a Job

A SaaS landing page shouldn't exist because someone found a keyword.

It should connect:

Search intent → User problem → Product capability

That's where SEO becomes part of product marketing.

A Real SaaS Example

This has been especially relevant while working on Coachiko, a platform for fitness coaches managing students, programs, payments, and related workflows.

The interesting SEO challenge isn't simply ranking the homepage.

It's understanding what coaches actually search before they know the brand exists.

Those searches can shape landing-page architecture.

Don't Wait for Perfect Data

New SaaS products don't have years of Search Console history.

You work with market research, competitor SERPs, user language, and early data.

Then iterate.

SEO architecture doesn't have to be perfect on day one.

But it should be intentional.

The Bigger Lesson

SEO is cheapest when considered before architecture hardens.

For SaaS, organic acquisition should be part of how the public-facing product is designed, not something attached after launch.

AI Is Changing Keyword Research, but Not Search Intent

sepideh jafari — Sun, 13 Sep 2026 20:24:36 +0000

AI has changed keyword research dramatically.

It can generate hundreds of topic ideas in seconds.

It can cluster phrases.

It can categorize queries.

It can suggest related concepts.

But there's something AI hasn't eliminated:

Understanding why someone searches.

Keywords Are Not Intent

Two phrases can contain almost identical words and still require different pages.

One user may want information.

Another may want to compare products.

Another is ready to buy.

Another wants a specific brand.

Keyword similarity doesn't automatically mean intent similarity.

AI Is Great for Expansion

I like using AI for:

generating seed variations,
discovering related entities,
categorizing large keyword sets,
identifying possible topic gaps,
and summarizing patterns.

These tasks are fast and repetitive.

Perfect for automation.

But SERPs Still Matter

If I'm unsure whether two queries should share one page, I still want to inspect actual search results.

What types of pages rank?

Products?

Categories?

Guides?

Forums?

Videos?

Google's results give useful clues about interpreted intent.

AI predictions alone aren't enough.

Clustering Can Be Too Aggressive

AI can group keywords based on semantic similarity.

That can be helpful.

But semantic similarity isn't always SEO similarity.

“Best running shoes”

and

“How to choose running shoes”

both concern running shoes.

One is strongly commercial.

The other is informational.

A semantic model may see them as close.

An SEO architecture may need separate pages.

The Biggest Risk Is Artificial Scale

AI can produce enormous keyword lists.

That's not automatically useful.

A list of 50,000 keywords isn't a strategy.

The real work is deciding:

Which intents matter?

Which deserve pages?

Which belong together?

Which support commercial objectives?

The Bigger Lesson

AI makes keyword discovery faster.

It doesn't remove the need for judgment.

The future of keyword research isn't generating more keywords. It's making better decisions with larger amounts of search data.

The Hidden SEO Cost of E-Commerce Filters

sepideh jafari — Sun, 13 Sep 2026 20:20:29 +0000

Filters are essential to e-commerce.

They're also one of the easiest ways to create thousands of URLs nobody intentionally planned.

Imagine a store where users can filter products by:

brand, color, price, size, availability, and style.

Each filter is useful.

The problem begins when every possible combination becomes a crawlable URL.

One Category Can Become Thousands of URLs

Suppose a category contains:

10 brands
8 colors
5 sizes
6 price ranges

The number of potential combinations grows very quickly.

The store still has the same products.

But search engines may now discover a dramatically larger URL space.

This can affect crawling, indexing, duplicate content, and internal linking.

Not Every Filter Is Bad

The solution isn't simply blocking all filter pages.

Some combinations represent real search demand.

A filtered page may deserve indexation if:

users genuinely search for that combination,
it has enough relevant products,
it represents distinct intent,
and the page can provide unique value.

Other combinations are simply interface states.

Those don't necessarily need to become search landing pages.

Search Intent Should Decide

I've been dealing with this distinction while working on Kifico, where product attributes such as use case, style, and other characteristics can influence how people search for bags and backpacks.

The important SEO question isn't:

“Can this filter generate a URL?”

It's:

“Does this URL represent something people actually search for?”

That's a very different decision.

Canonicals Alone Aren't Enough

A common solution is to let every filter generate a URL and canonicalize them back to the main category.

Sometimes that's appropriate.

But if the application exposes endless combinations, canonical tags don't remove those crawl paths.

The architecture itself still matters.

Filters Are a Product Decision and an SEO Decision

UX teams care about helping users narrow products.

SEO teams care about controlling which combinations become search documents.

Both goals can coexist.

But only if filter behavior is designed intentionally.

The Bigger Lesson

Faceted navigation isn't inherently bad for SEO.

Uncontrolled faceted navigation is.

The goal isn't to stop users filtering products. It's to stop every interface state from automatically becoming a search-engine landing page.

Why URL Architecture Matters More as Websites Grow

sepideh jafari — Sun, 13 Sep 2026 12:10:31 +0000

URLs look simple when a website is small.

You create a page.

It gets a URL.

You link to it.

Done.

But as a website grows, URLs stop being simple addresses.

They become part of the architecture of the product.

Ten Pages Hide Architectural Mistakes

A website with ten pages can survive an inconsistent URL strategy.

A website with 100,000 pages cannot.

At scale, small decisions multiply.

Consider:

?page=

?sort=

?filter=

?tag=

?view=

Each parameter may appear harmless.

Now allow several of them to combine.

Suddenly one collection of content can generate thousands of technically unique URLs.

The amount of content hasn't increased.

The crawl space has.

Every Crawlable State Has a Cost

Not every application state needs to become a crawlable document.

Users may need sorting.

Users may need filters.

Users may need different interface views.

That doesn't automatically mean search engines need separate URLs for every state.

This distinction becomes increasingly important as applications become more interactive.

Frontend functionality and search architecture aren't the same thing.

Canonicals Are Not Architecture

One common response is:

“We'll just canonicalize everything.”

Canonical tags are important.

But creating thousands of unnecessary URLs and then canonicalizing them back to one page isn't necessarily good architecture.

A better question comes earlier:

Should these URLs be generated and discoverable at all?

Canonicalization should clarify legitimate duplication.

It shouldn't become the only mechanism preventing uncontrolled URL growth.

Sitemaps Reveal Architectural Thinking

A sitemap should contain the canonical, indexable pages you actually want search engines to discover.

When sitemaps contain redirects, parameters, duplicates, or non-indexable URLs, it often reveals a deeper problem:

The application doesn't have a clear definition of what constitutes a search page.

That definition matters.

Content Platforms Make This Particularly Visible

I've been dealing with this while working on SefidSiah, a Persian health content platform with a growing content library.

As content scales, archives, tags, pagination, query parameters, and topic relationships all begin interacting.

The challenge isn't simply publishing another article.

It's ensuring that adding content doesn't unintentionally multiply low-value URLs at the same time.

That experience has made one principle particularly clear to me:

Content scale and URL scale should not be confused.

A website can grow to thousands of useful documents without needing tens of thousands of unnecessary URL variations.

Developers and SEOs Need the Same URL Map

Technical SEO problems often appear after development because different teams have different mental models.

A developer may see routes and application states.

An SEO specialist may see indexable documents and crawl paths.

Both are correct.

The solution is agreeing on which application states should become search-engine-visible URLs.

For important patterns, teams should know:

Is it crawlable?
Is it indexable?
What is its canonical?
Is it internally linked?
Is it included in the sitemap?
Does it satisfy unique search intent?

These decisions become far more expensive to change after millions of URLs have already been discovered.

The Bigger Lesson

Good URL architecture isn't about making URLs pretty.

It's about controlling how a growing application represents information.

At small scale, architecture mistakes hide.

At large scale, search engines crawl them.

The best time to solve URL architecture problems is before scale turns them into indexing problems.

How I Use AI for Technical SEO Without Trusting It Blindly

sepideh jafari — Sun, 13 Sep 2026 11:59:47 +0000

AI has become part of my daily SEO workflow.

But probably not in the way many people imagine.

I don't give an AI tool a website and ask:

“What's wrong with my SEO?”

Then copy whatever it says into a task list.

Instead, I find AI most useful somewhere between data collection and human decision-making.

It can help me process information faster, identify patterns, generate hypotheses, and investigate technical issues.

But deciding whether those hypotheses are actually correct still requires context.

And that distinction matters.

AI Is Good at Finding Things Worth Investigating

Technical SEO produces a lot of data.

Crawlers can return thousands or even millions of URLs.

Search Console contains queries, pages, indexing states, sitemap information, and crawl signals.

Server logs can contain enormous amounts of request data.

Then there are:

redirects,
canonical tags,
status codes,
structured data,
duplicate metadata,
internal links,
pagination,
parameterized URLs,
and rendering behavior.

The problem isn't always finding data.

The problem is deciding where to look first.

This is one area where AI can be genuinely useful.

Instead of manually inspecting thousands of rows, I can use AI-assisted workflows to help identify patterns that deserve investigation.

The important word is investigation.

A pattern isn't automatically a problem.

Finding a Pattern Isn't the Same as Understanding It

Imagine a crawl shows 5,000 URLs containing query parameters.

An AI system might immediately classify this as:

Duplicate content problem.

Maybe.

But those parameters could represent very different things.

Some might be tracking parameters.

Some might control sorting.

Some might represent useful filters.

Some might create indexable landing pages intentionally.

Some might never be internally linked.

Some might already canonicalize correctly.

And some might genuinely be creating crawl waste.

The URL pattern alone doesn't tell you which situation you're dealing with.

You need to understand how the application works.

This is where blindly accepting AI recommendations becomes dangerous.

I Prefer Asking AI Questions, Not Asking for Verdicts

There's a subtle but important difference between these prompts:

“Tell me how to fix these URLs.”

and:

“What hypotheses could explain why these URLs are being discovered?”

The second question is much more useful.

It turns AI into an investigation partner rather than an authority.

Possible hypotheses might include:

faceted navigation,
pagination,
internal search,
JavaScript-generated links,
tracking parameters,
old URLs still linked internally,
sitemap contamination,
or external discovery.

Now I have something useful:

a list of things to test.

The next step is evidence.

Search Console and Crawlers Answer Different Questions

AI becomes more useful when you give it context from multiple sources.

A crawler tells you what the website exposes.

Search Console tells you something about how Google interacts with those URLs.

Analytics tells you how users behave.

Server logs can tell you what crawlers actually request.

These datasets describe different parts of the same system.

Suppose a crawler discovers thousands of parameter URLs.

Before deciding they're hurting SEO, I want to know:

Are they indexed?

Is Google crawling them?

How were they discovered?

Are they internally linked?

Are they in the sitemap?

What canonical do they declare?

Do they receive impressions?

AI can help organize those questions.

It can't replace the evidence needed to answer them.

AI Is Surprisingly Useful for Regex

This is one of the less glamorous applications, but I use it often.

Technical SEO regularly involves grouping URLs.

For example, I might need patterns for:

product URLs,
category URLs,
pagination,
query parameters,
image paths,
API routes,
language directories,
or legacy URLs.

Writing regular expressions manually isn't difficult once you're comfortable with them, but AI makes the process faster.

I can provide examples of URLs that should match and URLs that shouldn't.

Then generate a candidate regex.

But I still test it.

Always.

A regex that works on five examples can behave very differently across 500,000 URLs.

AI Can Help Turn Crawl Data Into Questions

Suppose I export crawl data containing:

URL

Status Code

Canonical

Indexability

Title

Depth

Inlinks

Content Type

Instead of reading thousands of rows individually, I can analyze groups.

Which templates contain most 3xx responses?

Which sections have unusually high crawl depth?

Which indexable URLs canonicalize elsewhere?

Which pages have zero or very few internal links?

Which URL patterns produce duplicate titles?

Which sitemap URLs aren't indexable?

These are excellent tasks for automation and AI-assisted analysis.

But notice what AI is doing.

It's helping prioritize.

It's not deciding the SEO strategy.

One of the Best Uses of AI Is Explaining Anomalies

I particularly like using AI after I've already found something strange.

For example:

A section suddenly contains far more URLs than expected.

A sitemap contains non-indexable pages.

Google selects a different canonical.

A template produces structured data errors.

A pagination pattern creates unexpected crawl paths.

Instead of immediately asking for a solution, I can describe the architecture and ask:

“What mechanisms could produce this behavior?”

That often gives me several directions to investigate that I might not have considered immediately.

Some will be wrong.

That's fine.

Generating hypotheses cheaply is useful.

Deploying fixes cheaply without verification isn't.

AI Doesn't Know Your Business Priorities

This is one of its biggest limitations in SEO.

Imagine two problems:

Problem A affects 100,000 URLs but none generate meaningful traffic or revenue.

Problem B affects 50 high-value commercial pages responsible for a significant portion of organic sales.

Which one should you fix first?

A tool looking primarily at scale might choose Problem A.

A business-aware SEO specialist may choose Problem B immediately.

Technical severity and business priority aren't always the same thing.

Good SEO prioritization often requires knowing:

revenue,
conversion value,
development effort,
business goals,
seasonality,
search demand,
and organizational constraints.

AI rarely has all of that context unless you explicitly provide it.

AI Can Produce Very Confident SEO Nonsense

This is the part that worries me most.

AI-generated SEO recommendations often sound professional.

They may mention:

canonicalization,

crawl budget,

indexation,

structured data,

Core Web Vitals,

internal linking,

and E-E-A-T.

Everything sounds plausible.

But plausible isn't the same as correct.

I've seen recommendations where the proposed “fix” would create a bigger problem than the original issue.

That's why I don't evaluate an AI recommendation based on how technical it sounds.

I evaluate it based on:

What evidence supports this?

My Preferred Workflow

The workflow I've found most useful looks something like this:

Collect → Segment → Investigate → Verify → Prioritize → Implement → Measure

AI can help significantly with the middle of that process.

Collect

Get data from crawlers, Search Console, analytics, logs, or the application.

Segment

Group URLs and issues into meaningful patterns.

Investigate

Generate possible explanations for unusual behavior.

Verify

Check the actual HTML, headers, rendering, application logic, and search-engine behavior.

Prioritize

Combine SEO impact with business value and development effort.

Implement

Turn verified findings into clear development or content tasks.

Measure

Check whether the change produced the expected result.

The dangerous workflow is much shorter:

Ask AI → Copy recommendation → Deploy

That's not automation.

That's outsourcing judgment.

AI Makes SEO Knowledge More Important, Not Less

There's an interesting contradiction happening.

AI makes many SEO tasks easier.

But because it makes recommendations so easy to generate, understanding SEO fundamentals becomes even more important.

If you understand canonicalization, you can evaluate an AI recommendation about canonicals.

If you understand HTTP status codes, you can challenge a bad redirect recommendation.

If you understand crawling and indexing, you can distinguish between a crawl issue and an indexation issue.

Without those fundamentals, every confident AI response looks equally convincing.

That's a problem.

Technical SEO Is Moving Toward Better Tooling

I don't think the future is SEO specialists manually inspecting spreadsheets forever.

More of the repetitive work will be automated.

Large URL datasets will be classified automatically.

Patterns will be surfaced faster.

Anomalies will be detected earlier.

Reports will become easier to generate.

And AI will increasingly sit between raw data and human analysis.

That's a good thing.

It means we can spend less time moving information between spreadsheets and more time understanding why something is happening.

But the final step still matters:

Does the recommendation make sense for this specific website?

The Bigger Lesson

AI is extremely useful for technical SEO when you treat it as an accelerator.

It can help you:

process data,
generate regex,
classify URLs,
identify anomalies,
generate hypotheses,
explain technical concepts,
and turn findings into clearer tasks.

What I don't want it doing blindly is making architectural decisions.

Because SEO problems don't exist in isolation.

They exist inside products, businesses, codebases, content systems, and user journeys.

AI can help you see the map faster.

You still need to decide where you're going.

Why E-Commerce SEO Is More Than Optimizing Product Pages

sepideh jafari — Sun, 13 Sep 2026 11:53:13 +0000

When people talk about e-commerce SEO, product pages usually get most of the attention.

Optimize the product title. Improve the description. Add structured data. Compress the images. Write better alt text.

All of that matters.

But after working with online stores, I've become convinced that some of the biggest SEO opportunities don't exist on individual product pages at all.

They exist in the architecture connecting products, categories, filters, brands, and search intent.

A store with perfectly optimized products can still struggle if search engines can't understand how those products belong together.

Product Pages and Category Pages Serve Different Intent

Consider someone searching for a specific backpack model.

A product page may be exactly what they need.

Now consider someone searching for:

school backpacks

They probably don't want one specific product chosen for them.

They want options.

They may want to compare size, design, price, color, or other characteristics before deciding.

That's where category pages become important.

This distinction sounds obvious, but it has major SEO implications.

A product page shouldn't necessarily compete with its parent category for the same query.

The architecture should reflect different levels of intent.

Broad commercial query → Category

Specific model query → Product

Brand-focused query → Brand page

Informational query → Guide or article

The clearer these roles become, the easier it is to build a coherent search strategy.

Categories Are Landing Pages, Not Just Product Grids

One of the easiest mistakes in e-commerce is treating a category page as nothing more than a list of products.

From a user perspective, a grid may be enough to browse.

From a search perspective, the category represents something much larger.

It defines a collection.

A strong category page can communicate:

what products belong there,
how they differ,
what users should consider,
which subcategories exist,
and how the collection relates to the rest of the store.

That doesn't mean adding 2,000 words of SEO text underneath every product grid.

More text isn't automatically more useful.

The goal is to provide enough context to make the category understandable without getting in the way of shopping.

Filters Create Both Opportunities and Problems

Filters are one of the most interesting parts of e-commerce SEO.

Users need them.

Search engines can struggle with them.

Imagine a backpack category that can be filtered by:

color,
gender,
size,
brand,
price,
style,
and availability.

From a UX perspective, that's useful.

From a URL perspective, it can become complicated very quickly.

If every combination produces a crawlable URL, a single category can generate hundreds or thousands of variations.

But blocking every filtered page isn't always the right answer either.

Some filter combinations may correspond to genuine search demand.

For example, users may actually search for a particular product type combined with a meaningful attribute.

That creates an important distinction:

Some filtered states are navigation.

Some filtered states may deserve to become search landing pages.

The difficult part is deciding which is which.

Search Demand Should Decide Which Filter Pages Matter

I don't think the right approach is:

“Index all filters.”

And I don't think it's:

“Block all filters.”

The decision should come from search behavior.

If a filtered combination represents meaningful, distinct demand and the page can provide a genuinely useful result set, it may deserve its own indexable landing page.

If it's simply an arbitrary UI state with no independent search value, allowing it into the index may create more noise than opportunity.

This is where keyword research and technical SEO need to work together.

Keyword research identifies demand.

Architecture determines how the website should represent that demand.

A Real Example: Kifico

I've been working through many of these decisions while handling SEO for Kifico, an e-commerce store focused heavily on bags and backpacks.

The project is a useful example because backpack searches can become surprisingly specific.

Users don't always search for a generic product.

They may care about purpose, style, audience, color, or other attributes.

That means simply optimizing individual product pages isn't enough.

We also have to think carefully about category architecture, which filtered combinations correspond to real search intent, how products connect to their parent categories, and which pages should actually become organic landing pages.

The experience has reinforced a principle I use increasingly often:

E-commerce navigation and SEO architecture cannot be designed independently.

The way users browse the catalog directly influences the URLs and relationships search engines discover.

Internal Linking Starts With the Store Hierarchy

E-commerce sites naturally contain a hierarchy.

Homepage.

Categories.

Subcategories.

Brands.

Products.

Guides.

But simply having those pages doesn't guarantee a strong internal linking structure.

The relationships need to make sense.

A product should clearly belong to relevant categories.

A category should expose important subcategories.

Useful buying guides should connect informational visitors to relevant commercial pages.

And the homepage should help users and crawlers reach the store's most important areas without forcing them through unnecessary steps.

This is why navigation itself becomes part of SEO.

Every important page shouldn't depend on an XML sitemap for discovery.

Breadcrumbs Do More Than Show Location

Breadcrumbs are especially useful in e-commerce because products often sit inside larger collections.

A structure such as:

Home → Bags → Backpacks → Product

helps communicate hierarchy.

It's useful for users who want to move back to a broader collection, and it also creates consistent internal relationships between levels of the site.

Like many technical SEO elements, breadcrumbs seem small when looking at one page.

Across thousands of products, they become structural.

Product Variants Need a URL Strategy

Colors, sizes, and other variants create another architectural decision.

Should each variant have its own URL?

Should all variants share one product URL?

Should changing a color modify a query parameter?

Should a variant URL be indexable?

There isn't one answer for every store.

The correct decision depends on whether variants have meaningful independent demand, unique content, inventory behavior, and how the application represents them.

The important thing is to make the decision intentionally.

Otherwise, the frontend may create a URL strategy accidentally.

And accidental URL strategies rarely scale well.

Out-of-Stock Products Need More Thought Than “Delete”

Products disappear.

That's normal.

The SEO decision depends on what happened to the product.

Temporarily unavailable is different from permanently discontinued.

A discontinued product with a clear replacement is different from one with no equivalent.

A page with backlinks or significant organic traffic deserves more consideration than a product that was never discovered.

Automatically deleting every unavailable product can throw away useful signals.

Keeping every dead product forever can create a poor shopping experience.

Again, context matters.

Technical SEO often involves choosing between imperfect options rather than applying one universal rule.

Product Schema Helps Machines Understand the Offer

E-commerce pages contain structured information naturally.

Product name.

Price.

Currency.

Availability.

Offers.

Ratings when applicable.

Structured data gives search engines a machine-readable representation of some of this information.

But schema shouldn't be treated as a box to tick.

It needs to match the visible product and actual offer.

If price or availability changes, the structured data should remain consistent.

And if the implementation generates errors across an entire product template, one small technical mistake can affect hundreds of pages.

Template-level validation is therefore far more important than checking one random product and assuming everything else works.

Category Content Should Help Shoppers

Category SEO sometimes leads to an unfortunate pattern:

A useful product grid is followed by a giant wall of keyword-heavy text written primarily for search engines.

I don't think that's a good long-term strategy.

If category content exists, it should help someone make a decision.

For example:

What distinguishes products in this category?

Which attributes matter?

Are there meaningful subcategories?

What should a buyer consider before choosing?

Useful commercial content can support SEO without turning the page into an article.

The primary purpose of an e-commerce category is still shopping.

Content and Commerce Should Connect

Informational content can play an important role in e-commerce SEO.

Someone searching for a buying guide may not be ready to choose a product immediately.

That's fine.

A useful guide can help them understand the decision and naturally connect them to relevant categories when they're ready to browse.

This creates a much healthier relationship than publishing unrelated blog posts simply because their keywords have traffic.

A useful architecture might look like:

Informational query → Guide → Relevant category → Product

Each page serves a different stage of the journey.

The Homepage Can't Carry the Entire Store

Another common problem is trying to make the homepage rank for every major commercial query.

The homepage should communicate the brand and help users discover important parts of the store.

Specific categories should handle more specific commercial demand.

That gives search engines a clearer architecture and gives users a more relevant landing experience.

If every commercial keyword points conceptually to the homepage, the rest of the site's structure isn't doing enough work.

SEO Architecture Should Follow How People Shop

This may be the biggest lesson.

A good e-commerce architecture isn't created by looking only at keywords.

And it isn't created by looking only at the product database.

It sits between the two.

The catalog tells us what the business sells.

Search behavior tells us how people look for it.

UX tells us how people want to browse it.

Technical SEO determines how those relationships become crawlable, indexable pages.

When those four pieces agree, the site becomes much easier to understand.

For users and for search engines.

The Bigger Lesson

Product optimization matters.

But e-commerce SEO becomes much more powerful when you stop thinking about products as isolated URLs.

A store is a network of relationships:

Homepage → Category → Subcategory → Filter → Brand → Product → Guide

The challenge is deciding which of those relationships deserve their own search landing pages and which should remain part of the shopping interface.

That's why some of the most important e-commerce SEO decisions happen before anyone writes a title tag.

They happen when the store decides how its catalog should be organized.

Good e-commerce SEO doesn't just optimize products. It makes the structure of the store reflect the way people actually search and shop.