DEV Community: Kenneth K. Amadi

Your Website Images Are Part of Search Now. Are You Treating Them That Way?

Kenneth K. Amadi — Mon, 28 Sep 2026 23:00:00 +0000

When most people think about SEO, they think about words.

Page titles.

Headings.

Keywords.

Blog posts.

Links.

The image usually comes later.

Someone finds a nice photo, uploads it to the website, gives it a filename like IMG_4827.jpg, adds it to the page and moves on.

That approach is starting to look increasingly incomplete.

Images have always been part of Google Search, but the way people search is changing.

People can search using Google Lens, upload an image, use Circle to Search, or search an image directly from Chrome. Google has now added a multimodal search filter to Search Console so site owners can see when their content is being surfaced through these image-based searches. Google explains the new reporting here. The rollout began globally on September 24, 2026.

That doesn't mean every website suddenly needs an image SEO strategy.

It does mean something simpler:

The images on your website are content too.

So let's look at what you can actually do with them.

Start with the image itself

Before touching filenames, alt text or metadata, ask a more basic question:

Is this a useful image?

If your website is for an architecture company, photographs of completed buildings are useful.

If you're selling a product, photographs of the actual product are useful.

If you're publishing a tutorial, screenshots and diagrams can be useful.

If you're writing about a real project your company completed, showing the project is useful.

Compare that with a generic image of someone typing on a laptop that appears on every technology website on the internet.

It might make the page look nicer.

But it tells the visitor very little.

This matters because Google's image SEO guidance isn't simply about making images technically available. Google recommends using images that are relevant to the page and placing them near relevant text.

A good image should add information.

Not just fill an empty space.

Give the image a sensible filename

This:

IMG_4827.jpg

doesn't tell anyone much.

Something like:

mobile-app-dashboard.jpg

is more useful.

Or, for a real project:

phunplan-mobile-booking-screen.jpg

The filename isn't a magic ranking factor that will suddenly move a page to number one.

That's not the point.

You're simply giving the file a meaningful name before uploading it.

And don't turn it into this:

best-mobile-app-development-company-mobile-app-developer-app-development.jpg

That's not optimisation.

It's noise.

Use a filename that naturally describes what the image is.

Then write the alt text properly

This is where people often go too far.

If you have an image of a mobile booking screen, an appropriate alternative text might be:

alt="PhunPlan mobile booking screen"

If it's a photograph of a building:

alt="Exterior of the Pathvera Group office building"

If it's a decorative shape that contributes nothing to the meaning of the page, it may not need descriptive alt text at all.

The purpose isn't to insert keywords into every image.

The purpose is to provide an appropriate text alternative when the image conveys information.

That distinction is important.

Don't write:

alt="best mobile app development company in Nigeria mobile app developers"

unless, somehow, that is genuinely what the image represents.

It isn't.

It's keyword stuffing.

The surrounding page matters

An image doesn't exist in isolation.

Imagine you publish an article about building mobile applications.

You include an image showing a mobile app interface.

The image appears directly underneath a section discussing the app's booking flow.

That's useful context.

Now take exactly the same image and place it inside an unrelated article about accounting.

The image hasn't changed.

The context has.

Google's image documentation recommends placing images near relevant text and using descriptive titles, captions and alt text where appropriate.

So don't think:

"I need to optimise this image."

Think:

"What does this image contribute to this page?"

That usually leads to better decisions.

Don't upload the original camera file

There is another problem that has nothing to do with search keywords.

File size.

A designer sends you a beautiful photograph.

It is 5.8 MB.

You upload it directly to the website.

The image looks fantastic.

The page now has to download several megabytes before the visitor gets what they need.

That is unnecessary.

Resize the image to the dimensions actually needed.

Compress it.

Use an appropriate modern format where your browser and workflow support it.

And don't serve a 4000-pixel image to a component that displays it at 600 pixels.

This isn't about chasing a perfect Lighthouse score.

Google's current page experience guidance explicitly says that Core Web Vitals matter, but also warns against treating a perfect score as the goal in itself. The purpose is a good experience for users.

If an image can be 200 KB instead of 2 MB without a meaningful visual difference, that's simply better engineering.

Don't forget responsive images

There is another optimisation that is easy to overlook.

The same image doesn't need to be downloaded at the same resolution on every device.

A desktop monitor might display a large hero image.

A phone may need something much smaller.

Modern HTML gives us tools such as srcset and sizes to provide appropriate image resources for different display conditions.

Your framework or image pipeline may already handle this for you.

If it does, use it.

If it doesn't, it's worth understanding what is actually being delivered to the browser.

The question isn't:

"Does the image look sharp?"

It's also:

"How much image did the browser have to download to make it look sharp?"

Use the right image, not just the biggest one

There is a tendency to think that higher resolution automatically means better.

It doesn't.

If the image is going to be displayed as a 400-pixel thumbnail, serving a 3000-pixel source isn't automatically an improvement.

Likewise, don't compress an image so aggressively that important details disappear.

There is a balance between:

quality

and

cost of delivery.

The right image pipeline should handle that balance automatically where possible.

This is one reason a good CMS matters.

An administrator shouldn't have to understand image codecs, responsive breakpoints and compression settings every time they upload a photograph.

The system should do more of the work.

Think about the image people would actually search for

This is where things get more interesting.

Suppose you're a furniture company.

You have a photograph of a particular chair.

Someone might not search for the name of your company.

They might search visually for:

"modern brown leather office chair"

Or they might photograph a similar chair in a showroom and use Lens to find visually similar products.

Your website doesn't control whether Google chooses to show your image.

But you can make the image easier to understand.

Use an appropriate product page.

Give the image a meaningful filename.

Use appropriate alt text.

Provide useful surrounding content.

Make the product details clear.

If the page is an actual product page, use the relevant structured data correctly.

Google supports Product structured data for product search features, and its merchant listing documentation covers additional requirements for eligible product pages.

The important part is that the image isn't doing the work alone.

The page, product information, structured data and image all describe the same thing.

Your social preview image matters too

There's another image that many websites get wrong.

The image that appears when someone shares your page.

Someone posts your article on social media or sends the link in a chat.

What image appears?

Does the website have a deliberately selected og:image?

Or does the platform grab something random from the page?

Google's current image SEO documentation also notes that it can use both structured data and the og:image meta tag as sources when determining image thumbnails for Google Search and Discover.

That doesn't mean you should create a dozen competing image signals.

It means your site's preferred image should be intentional.

For an article, that might be a designed article cover.

For a product, it might be the primary product photograph.

For a company page, it could be a suitable brand image.

Decide what represents the page.

Don't leave it to chance.

Structured data can help, but don't add it everywhere

Structured data is another place where SEO advice often becomes excessive.

You don't need to put every schema type imaginable on every page.

Use the type that actually describes the content.

Google supports structured data for a range of content types and search features. For example, Article structured data, Product structured data and LocalBusiness structured data can help Google understand the content they describe.

For example, if you have a product page, Product structured data may be appropriate.

If you have an article, Article structured data may be appropriate.

If you're describing a local business, LocalBusiness structured data may be appropriate.

The important word is appropriate.

And structured data doesn't guarantee a special appearance in Google. It can make a page eligible for certain search features when the content and implementation meet Google's requirements. Google's structured data documentation explains the supported features and requirements.

Don't add markup simply because an SEO checklist says you should.

Add it because it accurately describes the page.

Your best images may already be sitting on your website

Before creating new content, check what you already have.

Open Search Console.

Look at your Search performance reports.

Google has now introduced a multimodal search type filter that can show performance from searches involving Lens, Circle to Search, image uploads and other visual search interactions. The rollout began globally on September 24, 2026, and Google says the data appears when a site is receiving traffic from these queries. See Google's announcement.

If your site receives this type of traffic, you now have a much better way to understand it.

You might discover that an image you considered secondary is helping people find the site.

Or that your visual content is appearing in searches you weren't specifically targeting.

That's valuable information.

Don't guess what your audience is doing when Search Console can increasingly show you.

Give important images a real place in your content

There is a difference between:

"We added an image because the page looked empty."

and:

"This image helps explain what this section is about."

The second approach produces better websites.

If you're explaining how a CMS works, show the CMS.

If you're describing a project, show the project.

If you're selling a product, show the product clearly.

If you're explaining a technical process, use a diagram or screenshot where it actually helps.

And if the image doesn't contribute anything, you don't have to force one into the page.

More images don't automatically mean better SEO.

Better images can mean better content.

Be careful with AI-generated images

AI-generated images make it very easy to fill a website.

Need a hero image?

Generate one.

Need six blog illustrations?

Generate six.

Need a photograph for a service page?

Generate one.

Technically, that's convenient.

But ask what the image is actually doing.

If a software company publishes an article about a real engineering problem and uses a completely generic AI illustration of a glowing laptop, the image adds almost nothing.

A screenshot of the actual system might be more useful.

A diagram might be more useful.

A photograph of the team working on the project might be more useful.

A real example usually tells the reader something.

Use generated imagery where it serves a purpose.

Don't use it simply because an empty space on the page needs filling.

Run a simple image audit

You can audit a website's images without turning the process into a major SEO project.

Pick your ten most important pages.

For each page, check:

Is the image actually useful?

If not, remove it.
Does the filename make sense?

Rename it before uploading where practical.
Does meaningful imagery have appropriate alt text?

Describe the image rather than stuffing keywords into it.
Is the file unnecessarily large?

Resize and compress it.
Is the browser receiving an appropriately sized image?

Check responsive image handling.
Is the image close to the content it supports?

Context matters.
Is the page's preferred social/share image set?

Check og:image where relevant.
If the page represents a product or another structured content type, is the appropriate structured data implemented correctly?

Don't add markup just for the sake of it.
Can Google access the image?

Make sure your image URLs aren't accidentally blocked.
What does Search Console tell you?

Look at actual search performance instead of guessing.

That's enough to uncover a surprising number of problems.

The web is becoming more visual

Search isn't only a box where someone types ten words anymore.

People take pictures.

They upload screenshots.

They point their phones at things.

They search from images.

They interact with visual results.

And Google's latest Search Console update is a good indication of where the web is heading: site owners are now being given more visibility into how their content performs in these multimodal experiences.

That doesn't mean traditional SEO has disappeared.

It hasn't.

Text still matters.

Good pages still matter.

Good technical foundations still matter.

But a modern website should treat its visual content as part of the information it publishes, not merely as decoration around the information.

The next time you're about to upload:

IMG_4827.jpg

to a page, stop for a second.

Ask what the image is saying.

Ask whether it helps the visitor.

Give it the right context.

Deliver it efficiently.

And make sure your website gives search engines enough information to understand what it is.

That's image SEO in a much more useful form.

Not a collection of tricks.

Just better web development.

About the author

I'm a software engineer focused on building production software and exploring the architectural problems that emerge as applications grow beyond their original assumptions.

I share more of my engineering work and projects at Kenresoft.

When a Bug Isn't Really a Bug: How Architectural Constraints Hide Behind Technical Problems

Kenneth K. Amadi — Sat, 12 Sep 2026 11:24:36 +0000

Sometimes the hardest bugs aren't caused by broken code. They're caused by an architecture that no longer matches the problem.

There is a particular kind of bug that can consume far more engineering time than it should.

You fix it.

It comes back.

You fix it again.

Then something else breaks in a completely different part of the feature, and you start wondering whether the two problems are actually related.

I've learned to pay attention when that happens.

Sometimes a bug is just a bug. There is a mistake in the code, you find it, fix it, add a test, and move on.

But sometimes the bug is exposing a problem underneath the code.

The implementation may be doing exactly what it was designed to do. The problem is that the design no longer fits what the application has become.

That's when a bug stops being just a bug.

It becomes an architectural constraint.

The Trap of Fixing Symptoms

Take a text editor as an example.

Suppose the cursor occasionally jumps to the wrong position after an edit.

You investigate and find that the selection is being recalculated incorrectly. You fix it.

A few days later, applying formatting moves the cursor.

You fix that too.

Then lists start behaving strangely.

Another fix.

Then importing a document containing lists causes the editor to become unstable.

Another fix.

At some point, it is tempting to conclude that the editor simply has too many bugs.

But that may not be what is happening.

The individual failures can be symptoms of the same underlying assumption.

For example, imagine an editor whose document is fundamentally represented as one large string, with global character offsets used to represent selections and formatting:

Document
─────────────────────────────────────────────
"First paragraph\nSecond paragraph\nThird..."
─────────────────────────────────────────────
  0              15             30

For a simple editor, this is a perfectly reasonable design.

Text is text.

A selection is a pair of offsets.

An attribute applies to a range.

Insert some characters and shift the offsets after them.

Delete some characters and shift them back.

There is nothing inherently wrong with this approach.

The trouble starts when the document becomes more than a string.

Now it has paragraphs.

Headings have levels.

Lists have items and relationships.

Some formatting belongs to individual characters.

Other formatting belongs to an entire paragraph or block.

Once that happens, you're asking a flat representation to describe a structured document.

You can keep adding fixes.

But you're no longer just fixing bugs.

You're working around the limitations of the representation.

The Most Dangerous Bugs Are Sometimes Predictable

One thing I've become more careful about is assuming that unexpected behavior means the code is behaving unexpectedly.

Sometimes the behavior is actually predictable.

It is just the predictable consequence of an assumption that no longer holds.

Consider a simple cache.

Early in an application's life, you might have:

API
 ↓
Repository
 ↓
Cache

The repository fetches data, puts it in the cache, and returns it when needed.

Simple.

Then the application grows.

Now you need background refreshes, stale data handling, retries, offline behavior, concurrent requests, cache invalidation, and partial updates.

The original cache wasn't necessarily badly designed.

It was designed for a smaller problem.

The problem changed.

The architecture didn't.

This happens everywhere in software.

A state class that worked nicely for three screens can become difficult to reason about when twenty screens depend on it.

A navigation approach that worked for a small application can become awkward once deep links, authentication, nested navigation, and state restoration enter the picture.

A simple data model can become painful once the application needs relationships, partial updates, synchronization, and more complex queries.

A text buffer that works beautifully for plain text can become difficult to extend when the editor needs to understand document structure.

The original decision wasn't necessarily wrong.

The context changed.

Why We Keep Fixing the Wrong Thing

There is a practical reason this happens.

A bug report usually gives you something concrete:

"The cursor jumps after formatting."

You can reproduce it.

You can put a breakpoint somewhere.

You can change a function.

You can run the test again.

Architecture is less satisfying.

Architecture asks questions like:

Why does formatting need to manipulate the same coordinate system used by text insertion?

Why does this component need to know about that component?

Why is this state represented this way?

Why does a paragraph-level concept live inside a character-range system?

Those questions don't immediately produce a patch.

They produce investigation.

And when there is a ticket waiting to be closed, the patch is usually more attractive.

That's one of the ways technical debt accumulates.

Not because engineers don't care about architecture.

Because local fixes give you an immediate result, while architectural problems require you to step back and reconsider the problem.

A Useful Question: "What Must Be True for This Bug to Exist?"

One question I've found useful when debugging stubborn problems is:

What must be true about the architecture for this bug to be possible?

Take the cursor example.

Instead of asking only:

"Why is the cursor jumping?"

ask:

"Why is the cursor position so dependent on these transformations in the first place?"

That changes the investigation.

You stop looking only at the incorrect value and start looking at the system producing it.

Here's another example.

Suppose deleting a list item occasionally causes formatting from the following item to move into the previous one.

The obvious place to look is the deletion algorithm.

But another useful question is:

"Why does deleting one item require us to repair formatting ranges somewhere else?"

That might reveal something deeper.

Maybe the document model doesn't actually understand paragraphs.

Maybe lists are being represented indirectly through character attributes.

Maybe a global range-based representation is being asked to represent relationships it wasn't designed to represent.

Now the problem isn't necessarily the deletion function.

The problem may be the model underneath it.

Architecture Is About What the System Understands

This is probably the most important distinction I've learned.

Architecture isn't just folders.

It isn't whether a project has:

data/
domain/
presentation/

It isn't whether you use BLoC, Riverpod, Provider, Clean Architecture, MVVM, or another pattern.

Those choices can be useful.

But architecture is ultimately about what concepts the system understands and how those concepts are represented.

A document editor that understands only:

characters
offsets
ranges

has a very different model from one that understands:

document
paragraph
list
list item
inline formatting
selection

The second system isn't automatically better because it has more classes.

It is better only if those concepts actually exist in the problem you're solving.

The goal isn't to create more abstractions.

The goal is to make the important concepts explicit.

But This Doesn't Mean "Rewrite Everything"

This is where architecture discussions can become dangerous.

Once you discover that a model has become a constraint, it is tempting to throw everything away.

I've had that instinct myself.

You find the underlying problem and suddenly the existing architecture looks terrible.

But a rewrite isn't automatically the right answer.

Existing code contains knowledge.

It contains behavior that users already depend on.

It contains edge cases that may not be obvious from reading the code.

And sometimes the majority of the architecture is still perfectly fine.

The better question is:

What is the smallest architectural change that allows the system to represent the problem correctly?

That might mean introducing a proper paragraph index.

It might mean separating character-level attributes from paragraph-level attributes.

It might mean introducing a block abstraction without replacing the entire text engine.

It might mean introducing a new representation alongside the old one and migrating gradually.

Architecture doesn't have to be a choice between:

keep everything

and:

rewrite everything

There is usually another option:

change the boundary where the existing model stops being appropriate

That is often a much more manageable engineering problem.

The Architecture Should Follow the Problem

One mistake we can make as developers is treating architecture as permanent.

We design something and unconsciously expect it to remain valid forever.

But applications change.

Requirements change.

Users find workflows we didn't anticipate.

Features interact in ways we didn't plan for.

Data grows.

Performance requirements change.

A model that was appropriate at version 1.0 may not be appropriate at version 3.0.

That doesn't mean version 1.0 was badly engineered.

It means the software has taught us something about the problem that we didn't know when we designed it.

I think that's a healthier way to look at architecture.

Architecture is a hypothesis about the problem.

As we learn more about the problem, we should be willing to revise that hypothesis.

How I Approach Persistent Bugs Now

When I encounter a bug that keeps returning in different forms, I try not to immediately add another patch.

I look for patterns first.

1. Is the same subsystem repeatedly involved?

If several apparently unrelated bugs keep passing through the same component, that's worth investigating.

It doesn't prove that the architecture is wrong.

But it is a signal.

2. Are we constantly repairing state after operations?

If every operation looks something like this:

perform operation
→ repair state
→ recalculate offsets
→ restore selection
→ synchronize another structure

I start asking why.

Sometimes that complexity is necessary.

Sometimes it is evidence that two structures that should understand each other don't.

3. Does a simple operation require knowledge of too many things?

A useful question is:

"Why does this operation need to know all of this?"

If changing one paragraph requires knowledge of formatting, selection, rendering, history, list state, and unrelated document ranges, the problem may be larger than the function being changed.

4. Are fixes creating more fixes?

This is probably the strongest warning sign.

If fixing A creates a problem with B, and fixing B creates a problem with C, you may not have three independent bugs.

You may have one architectural tension showing up in three places.

5. Can the current representation express the concept naturally?

This is the question I find myself asking most often.

If the answer is:

"Not really, but we can work around it."

I pay attention.

A workaround isn't automatically bad. Good software is full of pragmatic compromises.

But when workarounds keep accumulating around the same missing concept, the debt is becoming visible.

Sometimes the Bug Is Telling You Something

This is the perspective I wish I'd adopted earlier.

A difficult bug isn't always an enemy.

Sometimes it is feedback.

It is telling you that the system's mental model of the problem may no longer be accurate.

That doesn't mean you should immediately redesign the system.

It means you should listen before you patch.

There is a big difference between:

"How do I stop this bug?"

and:

"Why does this system make this class of bug possible?"

The first question helps you close a ticket.

The second can help you improve the software.

The Goal Isn't Perfect Architecture

I'm not convinced that perfect architecture exists.

Every architecture makes trade-offs.

Every abstraction has costs.

Every representation makes some operations easier and others harder.

The goal isn't to design a system that never needs to change.

The goal is to recognize when the assumptions behind the system have stopped matching reality.

When that happens, the right response isn't always a rewrite.

It might be a small refactor.

It might be a new abstraction.

It might be a new boundary.

It might be replacing one component.

Or, sometimes, it might actually be time for a larger architectural change.

The important part is knowing why you're making the change.

A Real Example From My Own Work

These aren't just theoretical questions for me.

I've been working through many of these architectural questions while building a lightweight rich-text editor for Flutter.

As the editor has grown beyond basic text editing, problems around document structure, paragraphs, formatting, lists, and selections have made one thing increasingly clear: some problems are easier to solve when the underlying model actually understands the concepts the editor is working with.

The editor is already public on GitHub, and the current version is stable and working. It hasn't been published as a package yet, but I'm continuing to work toward a proper release.

I'm also using the editor as the foundation for a note-taking application. That gives the architecture another important test: it isn't enough for the editor to work in isolation; it needs to hold up when used as part of a real application with its own requirements.

View the rich-text editor on GitHub

A Bug Report Can Be an Architectural Report

These days, when I see a bug that keeps resurfacing, I try to treat it as more than a defect.

I ask:

What assumption is this bug exposing?

Sometimes the answer is nothing interesting.

It's just a bug.

Fix it and move on.

But sometimes the answer reveals something much more valuable:

The system is trying to represent a concept it doesn't really understand.

And when that happens, no amount of clever patching will make the underlying problem disappear permanently.

You can keep repairing the symptoms.

Or you can change the part of the architecture that makes those symptoms inevitable.

That's the point where debugging becomes engineering.

About the author

I'm a mobile engineer focused on building production software and exploring the architectural problems that emerge as applications grow beyond their original assumptions.

I share more of my engineering work and projects here at Kenresoft.