DEV Community: sepideh jafari

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.

What Building SEO for a New SaaS Product Taught Me

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

SEO for an established website and SEO for a new SaaS product are two very different problems.

An established website usually gives you data.

You have rankings, impressions, landing pages, backlinks, conversion history, and enough Search Console information to understand how people are finding you.

A new SaaS product gives you almost none of that.

You have a product, a market, a set of assumptions, and a website that search engines barely know exists.

That changes the job.

Instead of asking, “How do we improve this page?”, you often have to ask a much earlier question:

Which pages should exist in the first place?

Start With Problems, Not Features

SaaS teams naturally think in features.

The product may offer dashboards, user management, reporting, payments, messaging, automation, or dozens of other capabilities.

Users rarely begin their search there.

They search for problems.

Someone might search for:

software to manage clients,
a way to deliver programs online,
a tool to organize customer payments,
an alternative to spreadsheets,
or a platform for managing an online service.

This distinction matters because a feature list is not automatically a search strategy.

A good SaaS architecture needs to connect:

User problem → Search intent → Landing page → Product capability

When that relationship is clear, SEO becomes much more useful to the business.

The Homepage Can't Rank for Everything

One mistake I often see with young products is asking the homepage to do too much.

The company wants it to rank for the brand, the product category, every major feature, several use cases, and multiple commercial keywords.

That usually creates an unfocused page.

The homepage has an important job: explain what the product is, who it is for, and why someone should care.

More specific search intents often deserve their own landing pages.

For example, instead of forcing several different intents onto one page, a SaaS site might eventually have separate pages around:

Product category

Core use cases

High-value features

Specific audiences

Alternatives or comparisons

The exact structure depends on actual demand, but the principle is consistent:

One page shouldn't be responsible for every query in the market.

Search Intent Should Shape the Landing Page

Creating a page for a keyword isn't enough.

The page needs to satisfy the reason behind the search.

Someone searching for information may need an explanation.

Someone comparing software may need features, screenshots, pricing context, limitations, and differentiation.

Someone already searching for your brand may simply need a clear route to sign in or start using the product.

Those are different journeys.

This is why I prefer thinking about landing pages as part of a search journey rather than as isolated SEO assets.

The keyword gets someone to the door.

The page still has to convince them to enter.

SEO and Conversion Design Have to Work Together

Ranking a SaaS landing page without thinking about conversion is an incomplete win.

A page can attract organic traffic and still fail commercially.

The visitor needs to understand quickly:

What is this?
Is it made for someone like me?
What problem does it solve?
What can I do with it?
What should I do next?

This is where SEO, UX, copywriting, and product marketing begin to overlap.

A perfectly optimized H1 won't rescue a page that leaves users confused.

And a beautiful landing page won't generate organic acquisition if search engines can't understand what it's about.

The two disciplines need to meet.

A Real Example: Coachiko

I've been working through these questions while developing the organic search strategy for Coachiko, a platform designed to help fitness coaches manage their students and deliver training and nutrition programs.

It's an interesting SEO project because the potential search space is much broader than the product itself.

A coach may not search for the brand.

They may search for a way to manage students, create workout programs, work with clients online, or organize their coaching business.

That means our job isn't simply to describe Coachiko's features.

We need to understand the problems coaches already search for and build useful landing experiences around those intents.

This has reinforced a principle I find increasingly important:

SaaS SEO should translate product capabilities into existing user demand.

Public Pages and Application Pages Need Different SEO Rules

SaaS products often contain two very different websites under the same brand.

There is the public acquisition website.

And then there is the application itself.

Search engines generally need access to pages such as:

the homepage,
product landing pages,
feature pages,
use-case pages,
useful guides,
and other public resources.

They usually don't need to index:

Making that distinction early prevents unnecessary indexation problems later.

Not every route your application creates should become a search result.

Canonicals Still Matter on Small SaaS Websites

Canonical problems aren't exclusive to giant e-commerce stores.

A young SaaS product can create confusing signals too.

Public landing pages should generally communicate clearly which URL represents the primary version of the page.

Meanwhile, authentication pages and private application areas need their own indexing strategy.

This sounds basic, but implementing it during development is far easier than discovering hundreds of unwanted indexed URLs later.

SEO architecture is cheapest when it is designed before it becomes a problem.

Branded Search Is a Different Battle

For a new product, ranking for your own brand may sound trivial.

It isn't always.

Search engines don't initially have much information connecting a new word or name to a specific entity.

A new SaaS brand benefits from consistency:

the same name,

the same domain,

clear descriptions,

consistent profiles,

relevant mentions,

and eventually genuine references from other websites.

This isn't about manufacturing signals.

It's about making the entity easier to understand.

Over time, branded search becomes one of the clearest indicators that people are beginning to know the product exists.

Don't Create 50 Landing Pages Before Validating Five

Programmatic SEO and AI make it tempting to create large numbers of SaaS landing pages very early.

That can be useful in the right situation.

But scale should follow evidence.

I'd rather build a smaller set of genuinely differentiated landing pages, measure how search engines and users respond, and expand from there.

Otherwise, you risk creating dozens of pages with slightly different keywords but essentially the same purpose.

That isn't an information architecture.

It's duplication with different headings.

Content Should Support the Product Architecture

Blog traffic can be valuable for SaaS.

But traffic alone isn't the objective.

The strongest content strategy creates a relationship between informational demand and commercial pages.

A useful guide can answer a real question while naturally introducing a relevant product capability or landing page.

That creates a path:

Question → Education → Solution → Product

Without that relationship, a SaaS blog can accumulate impressive traffic while contributing very little to product discovery.

Traffic should have somewhere meaningful to go.

Measure More Than Rankings

Rankings are useful.

For a SaaS product, they are only part of the picture.

Organic growth should eventually connect to metrics such as:

qualified landing-page visits,
registrations,
demo requests,
activation,
branded searches,
and conversions from organic sessions.

A keyword moving from position 12 to position 6 is encouraging.

A landing page bringing in the right users is much more interesting.

SEO needs to connect with business outcomes.

The Bigger Lesson

SEO for a new SaaS product isn't primarily about optimizing what already exists.

It's about helping determine what should exist.

Which problems deserve landing pages?

Which features correspond to real demand?

Which application routes should search engines see?

How should informational content connect to commercial pages?

And how do we turn someone who has never heard of the brand into someone who understands why the product is relevant?

Those questions sit somewhere between SEO, product strategy, UX, and marketing.

That's what makes SaaS SEO interesting.

You're not simply trying to rank a website. You're helping build the search-facing architecture of a product while the product itself is still growing.

What an E-Commerce Migration Taught Me About Technical SEO

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

Moving an e-commerce website to a modern framework sounds like a development project.

From an SEO perspective, it can be much more than that.

A migration can change URLs, rendering behavior, canonical tags, pagination, structured data, internal links, redirects, sitemaps, and even which pages search engines are able to discover.

That means a website can become technically faster and cleaner while simultaneously becoming harder for Google to understand.

Working on e-commerce SEO has made me increasingly skeptical of one assumption:

A successful deployment does not necessarily mean a successful migration.

The application can work perfectly for users while search engines see a very different website.

URLs Are Part of the Product

Developers often think about URLs primarily as routes.

Search engines see them as documents.

That difference becomes important during a migration.

Imagine an old product page has accumulated rankings, backlinks, historical signals, and internal links over several years.

The new application launches with a cleaner URL structure.

From a development perspective, this may be an improvement.

From an SEO perspective, however, we immediately need to know:

Did the old URL redirect correctly?
Is the redirect permanent?
Does it point directly to the equivalent new page?
Are internal links still referencing the old URL?
Is the new URL included in the sitemap?
What canonical does the new page declare?

A URL change isn't simply a routing decision once search engines have already discovered the old version.

It becomes a migration decision.

Redirects Need a Map, Not Guesswork

One of the easiest ways to lose organic visibility during a migration is treating redirects as something to configure after launch.

Redirect planning should happen before the migration.

Ideally, every important old URL should have a known destination.

For large stores, that means working with groups such as:

Old product → New product

Old category → New category

Old brand page → New brand page

Removed product → Relevant replacement or appropriate parent page

Not every URL deserves a redirect to the homepage.

In fact, sending large numbers of unrelated URLs to the homepage can create a confusing experience for both users and search engines.

The destination should preserve intent whenever possible.

Canonicals Can Quietly Break an Otherwise Good Migration

Canonical problems are particularly dangerous because the page itself may look completely normal.

A product loads.

The title is correct.

The description is there.

Users can buy it.

But somewhere in the HTML, the canonical points to the wrong URL.

Now the application and the SEO signals disagree about which document should be indexed.

I've learned to treat canonical validation as a separate migration test rather than assuming it is correct because routing works.

For important templates, I want to verify:

Product canonical
Category canonical
Brand canonical
Pagination behavior
Parameterized URLs
Protocol and hostname consistency

One incorrect template can affect thousands of URLs.

That's the difference between page-level SEO and platform-level SEO.

E-Commerce Sites Create URLs Very Easily

Online stores naturally create multiple ways to reach products.

Filters, sorting, pagination, categories, brands, colors, availability states, and tracking parameters can all affect URLs.

This is useful for users.

It can become complicated for crawlers.

Suppose a category offers filters for brand, price, color, and availability.

If every possible combination creates a crawlable URL, a relatively small product catalog can produce a very large crawl space.

The important question isn't whether filters should exist.

They should.

The question is whether every filter state needs to become a search-engine-accessible page.

Some filtered pages may represent valuable search demand.

Others are simply temporary interface states.

Treating both groups identically can create unnecessary indexation and crawling.

A Real E-Commerce Example

I've been dealing with many of these questions while working on the SEO of AsanGSM, an e-commerce website focused on mobile repair tools and equipment.

The project became particularly interesting from a technical SEO perspective because the website moved from WordPress to a Next.js-based architecture.

That kind of migration makes it necessary to look beyond rankings and individual keywords.

You have to examine the entire system:

URL behavior, redirects, canonicals, pagination, sitemaps, structured data, crawl paths, and the relationship between the old architecture and the new one.

It reinforced something I now consider fundamental:

A framework migration should include an SEO migration plan from the beginning.

SEO shouldn't arrive after the new application is already live.

Sitemaps Should Describe the Website You Want Indexed

A sitemap isn't just a giant list of URLs the application happens to know about.

It should represent the URLs you actually want search engines to consider.

That means an XML sitemap shouldn't casually include:

redirected URLs,
non-canonical URLs,
parameter variations,
pages intentionally excluded from indexing,
broken pages,
or duplicate routes.

If a URL is in the sitemap while another SEO directive says it shouldn't be indexed, you're sending conflicting signals.

At scale, those inconsistencies matter.

A useful sitemap should be boring.

Mostly clean, canonical, indexable URLs returning successful responses.

Structured Data Needs Migration Testing Too

Structured data is another area where migrations can create silent regressions.

The visible product page may survive the migration perfectly while Product or Offer markup becomes incomplete.

For an e-commerce website, structured data can include information such as:

product name,
price,
availability,
currency,
offers,
ratings,
and other product properties.

This data shouldn't be treated as decoration.

It should be generated from reliable product information and validated after deployment.

A migration checklist that only verifies the visible frontend is incomplete.

The machine-readable version of the page matters too.

Crawling the New Website Is One of the Best Reality Checks

Looking at individual pages in a browser isn't enough.

A crawler gives you a different view of the website.

Suddenly you can see patterns:

hundreds of redirects,

unexpected parameter URLs,

missing canonicals,

duplicate titles,

broken internal links,

non-indexable URLs inside the sitemap,

or templates generating inconsistent metadata.

This is why crawling before and after a migration is so valuable.

Humans inspect pages.

Crawlers expose systems.

And most serious technical SEO problems are systemic.

Next.js Doesn't Automatically Solve SEO

Next.js is powerful.

It gives teams excellent options for rendering, routing, metadata, performance, and application architecture.

But using Next.js doesn't automatically make a website SEO-friendly.

You can build an extremely fast application that still has poor canonical logic.

You can implement server-side rendering while exposing thousands of unnecessary URLs.

You can achieve excellent performance while accidentally removing valuable internal links.

Technology provides capabilities.

Architecture determines how those capabilities are used.

That's why I don't think the useful question is:

“Is Next.js good for SEO?”

A better question is:

“Has this Next.js implementation been designed with search behavior in mind?”

Search Console Becomes More Valuable After Migration

A crawler tells you what your website exposes.

Search Console tells you how Google responds to it.

After a migration, I pay particular attention to changes in:

indexed pages,
excluded pages,
discovered URLs,
crawled URLs,
canonical selection,
sitemap processing,
structured data reports,
and organic landing pages.

Not every fluctuation is a disaster.

Search engines need time to process major changes.

But unexpected patterns can reveal problems that weren't visible during development.

The goal isn't to panic over every graph.

It's to compare expected behavior with actual behavior.

The Bigger Lesson

E-commerce migrations sit at the intersection of development, UX, data, and search.

That's what makes them difficult.

A developer can successfully migrate the application.

A designer can successfully migrate the interface.

A product team can successfully migrate the catalog.

And the project can still lose important search signals if nobody owns the SEO migration.

The safest approach is to treat SEO requirements as part of the migration specification itself.

Before launch, know:

which URLs are changing,
where old URLs will redirect,
which pages should be indexable,
how canonicals will be generated,
how filters and pagination behave,
what enters the sitemap,
how structured data is produced,
and how the new site will be monitored after deployment.

Modernizing the technology is valuable.

Preserving the meaning and discoverability of the website while doing it is what makes the migration complete.

What Large Content Sites Teach You About Technical SEO

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

What Large Content Sites Teach You About Technical SEO

Scaling a content website changes the nature of SEO.

When a site has twenty articles, most SEO problems are easy to see. You can inspect pages manually, fix a few titles, improve internal links, and move on.

When the same site starts moving toward hundreds or thousands of pages, SEO becomes much less about optimizing individual articles and much more about controlling the system that creates, connects, and exposes those pages.

That shift has changed the way I think about technical SEO.

URL Architecture Becomes an SEO Decision

On a small website, a few unnecessary URLs rarely cause serious problems.

At scale, they multiply.

Filtering, sorting, pagination, tags, search states, and tracking parameters can create many variations of what is essentially the same page.

You may start with /articles and gradually expose variations created by pagination, sorting, tags, or different views.

Individually, these URLs don't look dangerous. But when parameters can be combined, the number of crawlable URLs can grow much faster than the amount of useful content.

For every URL pattern, I now ask:

Should this page exist as a separate URL?
Should search engines crawl it?
Should it be indexable?
What should its canonical URL be?
Does it satisfy a unique search intent?

Those are architecture questions, not just SEO checklist items.

Canonical Tags Don't Replace Good Architecture

Canonical tags are useful, but they're often treated as a cleanup mechanism.

A site generates dozens of unnecessary URL variations and then points all of them back to one canonical page.

Technically, that may communicate the preferred URL. Architecturally, however, the site is still generating unnecessary crawl paths.

A better approach is to decide which URL states deserve to exist in the first place.

Canonicalization should reinforce a clean architecture, not compensate for an uncontrolled one.

Crawl Budget Problems Often Start Inside the Product

One of the most useful lessons I've learned from technical SEO is that many “Google problems” are actually product architecture problems.

Googlebot can only crawl what the application exposes.

If navigation, filters, pagination, internal search, or components continuously generate new URLs, crawlers can discover them.

At that point, adding rules to robots.txt may reduce some crawling, but it doesn't necessarily fix the underlying architecture.

The better question is:

Why is the application exposing this URL at all?

That question often leads to a more permanent solution.

Internal Linking Has to Become Systematic

Manual internal linking works when a site contains a small number of articles.

It becomes unreliable at scale.

As the content library grows, articles need relationships.

A useful structure might look like:

Topic → Pillar → Cluster → Supporting Article

Instead of asking writers to randomly add several internal links, the platform should understand how content belongs together.

For example, an article about a specific symptom may naturally connect to a broader condition guide, a related topic, a prevention article, and its parent topic.

This creates a graph of related information rather than a collection of isolated posts.

Information Architecture Becomes More Important Than Publishing Speed

AI has made producing content dramatically easier.

That makes architecture more important, not less.

Imagine publishing 1,000 articles quickly without clearly defining their search intents.

You may end up with overlapping articles, keyword cannibalization, weak category pages, orphan content, inconsistent internal links, and several pages competing for the same query.

Publishing faster simply creates these problems faster.

Before scaling content, I prefer defining the relationship between:

Entity → Topic → Search Intent → Page

Only then does increasing publishing velocity make sense.

A Real Example: SefidSiah

I've been applying many of these lessons while working on SefidSiah, a Persian health content platform.

Health content makes information architecture particularly interesting because many topics naturally overlap.

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

If every keyword automatically becomes a new article, the architecture becomes fragmented very quickly.

Instead, we're treating content as connected topic clusters and paying close attention to indexation, canonical behavior, URL parameters, and internal linking as the library grows.

The project has reinforced an important lesson for me:

Content scale without architectural discipline creates technical debt.

And in SEO, that debt eventually becomes visible in crawling, indexing, rankings, or all three.

JavaScript Frameworks Don't Remove SEO Responsibility

Modern frameworks such as Next.js give developers excellent tools for rendering, routing, metadata, and performance.

But a technically modern stack doesn't automatically produce a search-friendly website.

You can still build a fast Next.js application that generates unnecessary URLs, uses incorrect canonicals, exposes thin pages, creates duplicate paths, or builds weak internal navigation.

Framework choice and SEO architecture are different decisions.

The best results I've seen happen when SEO requirements are considered during product development rather than added after launch.

Technical SEO Is Increasingly an Engineering Problem

The deeper I work with large websites, the less useful the boundary between “SEO issue” and “development issue” becomes.

Consider parameterized URLs, pagination, canonical generation, redirects, structured data, rendering, sitemap generation, faceted navigation, internal linking, and crawlable application states.

Most of them require understanding both search engines and application behavior.

An SEO specialist doesn't necessarily need to become a software engineer. But understanding how the application generates URLs and pages makes diagnosing these problems dramatically easier.

The Bigger Lesson

Small websites let you optimize pages.

Large websites force you to optimize systems.

Once a content platform reaches enough pages, SEO becomes increasingly dependent on architecture: how URLs are generated, how content is classified, how pages connect, what crawlers can discover, and which pages are allowed into the index.

That's why I increasingly think of technical SEO as part of product architecture rather than something that happens after development.

And as AI makes publishing content even easier, I suspect this distinction will become much more important.

The competitive advantage won't simply be producing more content.

It will be building a system capable of organizing that content without creating thousands of new SEO problems along the way.

AI Can Write Content, But It Can't Own Your SEO Strategy

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

AI has made content production dramatically faster.

But faster content production doesn't automatically create better organic growth.

The more I work with SEO, the more I see the same problem: teams use AI to generate articles before answering the questions that actually matter.

What search intent does this page satisfy?
Does another page already target the same intent?
Where does this page sit in the site's information architecture?
Which pages should link to it?
And most importantly, does the page add anything useful that isn't already available?

AI can help with research, outlines, topic discovery, entity extraction, content briefs, and even identifying potential gaps. These are genuinely useful applications.

But publishing hundreds of AI-generated pages without a clear architecture can simply produce hundreds of new SEO problems faster.

For me, the interesting future isn't AI replacing SEO specialists.

It's SEO specialists using AI to spend less time on repetitive work and more time on decisions that require context, prioritization, and strategy.

AI makes execution cheaper.

Good strategy becomes more valuable because of it.

I'm curious how other SEO and development teams are approaching this: where has AI genuinely improved your SEO workflow, and where do you still prefer human judgment?