WTSFest Philly is back on October 1st!
WTSFest Philly is back on October 1st!
Author: Roxana Stingu
Last updated: 15/07/2026
We recently had the pleasure of hosting Roxana Stingu for an Ask Me Anything (AMA) in our Slack #seo-technical channel.
With more than 15 years experience, Roxana describes herself as “one of the lucky few SEOs who gets to see search from both sides”.
As Head of Search and SEO at Alamy, she’s responsible for visibility across search engines and AI surfaces; and she also gets to work on the search engine Alamy’s customers use to navigate a catalogue of hundreds of millions of images.
Roxana loves educating and engaging with others, whether through mentorship, being part of communities like WTS, speaking at conferences, webinars and podcasts, or writing blog posts. Her aim is to inspire conversation and promote a culture of continuous learning and innovation in the industry.
Roxana answered questions from our community on a range of topics, including how Alamy’s search engine works, what building the search engine has taught her, AI workflows, Agentic and AI search, and more! You can read the highlights from her session below.
Our live AMA sessions take place on the WTS Slack Workspace, a safe, private space for community members to ask questions and share their knowledge. Out of respect for our members and their privacy, rather than publishing full transcripts of these sessions, we curate edited recaps which capture a selection of the questions and answers from each session.
Want to take part in our next Slack AMA? Join the WTS community!
The biggest similarity is that all search engines are trying to solve the same basic problem: out of everything available, what is the best result for this particular query?
The process which goes on in the background is broadly similar:
Relevance is only the starting point. Whether you are Google, Bing or an ecommerce search engine, you can often find hundreds of technically relevant results. The difficult part is deciding which one deserves to appear first.
Many of the practical challenges are also the same: ambiguous queries, new content with no performance history, spam or low-quality content, balancing freshness with proven quality, avoiding repetitive results, and doing all of that quickly and at enormous scale.
And there is definitely one thing every search engine has in common: people will try to game the system – and we’ve seen this on our own search engine too!
The main differences come from the corpus, the goal, and the data available.
At Alamy, we search within a known catalogue. We have structured metadata, visual embeddings, contributor information, licensing details and direct signals such as clicks, downloads and sales. We also know that the user is ultimately trying to find an image they can use or buy.
A web search engine has to understand an open and constantly changing web. It needs to discover pages, assess different websites and sources, understand authority and links, and serve a much wider range of intents, from finding a restaurant to researching a medical condition.
The definition of a “good result” is therefore different too. At Alamy, results need to be visually relevant, licensable, commercially useful, and varied enough that the page does not show twenty near-identical images. For Google or Bing, the result may need to be authoritative, timely, local, informational, or navigational depending on the query.
The signals also differ. We can see whether an image was purchased. A web search engine usually cannot see the final business outcome on every website, so it has to rely much more heavily on indirect signals such as links, source reputation, content quality and user interactions.
But the fundamental lesson is that search engines are much more alike than they first appear. They all balance relevance, quality, trust, freshness, diversity and efficiency, they just have different information available and different definitions of success.
This used to be much harder to do at scale, especially in stock photography. You might have an entire photoshoot featuring the same model, clothing and background, with only very small differences in crop, colour treatment, pose or facial expression.
Historically, we could group images using signals such as the photographer, upload batch, shoot reference, capture time and other EXIF data. If several images came from the same photographer, were taken seconds apart and shared very similar metadata, there was a good chance they belonged to the same shoot. For exact duplicates, checksums or file hashes could identify identical files. Perceptual hashing could go a step further by finding images that were visually very similar despite being resized, compressed or slightly colour-adjusted. However, those methods were less effective when an image had been cropped, retouched or differed only in a small but meaningful way, such as a facial expression.
It is much easier now because, when we built our new search engine, we created vector embeddings for our images. Those embeddings place every image within a shared vector space based on its visual characteristics.
To find near duplicates, we can take one image and look for the images closest to it in that space using measures such as cosine similarity. Images with very small visual differences tend to sit very close together, so this allows us to identify identical and near-identical images at scale.
We use the same principle for our reverse image search service where someone uploads an image, and the system finds the images that are most visually similar to it.
The important part is deciding where to set the similarity threshold. Too strict, and you only catch exact duplicates. Too loose, and you start grouping together images that are related but meaningfully different.
Human labelling still plays a very important role. AI is great for automating broad, repeatable tasks, such as identifying that an image contains a puppy, a car, a beach or a group of people.
Where it struggles is with context.
For example, AI might recognise that a group of people are celebrating, but it may not know which specific event they are attending. It might see the sun over the sea, but not know whether it is a sunrise or sunset without understanding the exact location and orientation of the beach. The same applies to identifying real people, precise locations, time of day, cultural context, or what was actually happening when the image was taken.
That is where human input remains essential. The photographer or contributor was there, so they can confirm who is in the image, where and when it was taken, which event was happening, and any other details that cannot be reliably inferred from the pixels alone.
So, I do not see model-generated tags as replacing human labelling. I see them as a way to automate the obvious, while humans provide the specific, factual context that makes an image genuinely searchable and useful.
One of my biggest learnings is that there is rarely one search experience that works equally well for everyone.
When we tested Smart Search, different customer groups responded differently. Enterprise and B2B users often benefited more from broader, exploratory results, while some B2C users had shorter, more transactional journeys.
The same principles apply more generally to our work as SEOs – we should be very careful with averages. A traffic or conversion change may look neutral overall, but our averages hide completely different outcomes by audience, country, device, query type or landing page. Segmentation is often where the real insight lives.
Another learning is that improving a search metric does not automatically improve the business outcome. For example: we significantly reduced zero-result searches, but showing more results does not necessarily mean showing results people want to buy. A higher click-through rate could mean we’re showing better results, or it could mean people are clicking around because they cannot find what they need.
In a similar vein, from an SEO perspective higher rankings, impressions or traffic are not automatically valuable. You need to connect them to what happens next.
I have also learnt that value is not always visible in the headline numbers straight away.
Our new result pages began surfacing images that had rarely been seen before, and those images started receiving clicks. Total transactions might remain broadly similar, but opportunity was being distributed across more of the catalogue.
It's similar to when we make a change that might not immediately increase total traffic, but it may improve the mix of landing pages, bring visibility to previously buried content or reduce dependence on a small number of pages and queries. That can still be a meaningful improvement.
And finally, when you’re building a search engine, you’re never finished. I’ve been at it for years, (and working in SEO for even more years!) and I’m still learning non-stop and finding new things to improve!
A search engine can perform brilliantly in offline testing without necessarily helping people click, buy, or find what they need. Sales data is much scarcer than search, or click data, so it takes time to gather enough evidence and averages often hide completely different outcomes across customer groups.
This has made me appreciate why Google values its usage data so highly. The US Department of Justice proposed forcing Google to sell Chrome, although the court ultimately rejected that remedy and instead required Google to share certain search index and user-interaction data.
Chrome is strategically important to Google for several reasons, but I think the visibility it provides into how people use the web is undoubtedly part of its value.
One other unexpected issue was how much tiny language details matter.
You might assume that dealing with things like names, accented characters and multi-word phrases will be trivial, but tokenisation or text normalisation can cause a search engine to split or interpret them incorrectly.
A technically sophisticated search engine can still fail on something that seems incredibly obvious to a human.
I think the biggest thing that suddenly made sense was not one specific update, but the growing importance of brand and source-level quality.
When we built our image search engine at Alamy, establishing relevance was only the first step. We could identify images that matched the query fairly easily, but how did we decide which of those relevant images deserved to appear first?
Looking only at an individual image’s sales or clicks wasn’t always enough, particularly for a new image with no performance data.
So, we started looking one level higher, at the photographer.
If a photographer consistently produces work that performs well, there is a reasonable chance their new images will also be high quality. In this analogy, each image is like a page, while the photographer’s complete collection is like a website or brand.
That helped me understand why Google may consider signals beyond the individual page. If people have repeatedly had successful experiences with a source, that history can help the search engine assess new content from that source. Google says its systems work primarily at page level, but that it also uses some site-wide signals.
I would not say “brand” is one simple ranking factor, but I now understand why established, trusted brands often have an advantage. It’s because the search engine has more evidence about the likely quality of what they produce.
Another update that springs to mind is Panda (2011). At the time, I saw it mainly as Google cleaning low-quality content farms out of the results (Google described Panda as a system intended to surface more high-quality, original content).
Having run a search engine, I now also see quality filtering as an operational necessity.
At scale, you cannot afford to retrieve, process and rank endless volumes of repetitive, low-value content as though every document deserves equal consideration.
I cannot claim Google launched Panda primarily to reduce costs, only Google could confirm its motivations. But I now understand that removing low-quality content does more than improve the results for users. It also helps a search engine use its resources more effectively.
Building a search engine made me realise that many updates we view as philosophical decisions about what is “good for the web” may also solve very practical problems around scale, efficiency and result quality.
As SEOs we tend to treat search engines as a checklist of ranking factors, where changing one thing should produce a predictable ranking outcome.
In reality, ranking factors are systems of trade-offs.
A search engine is trying to balance relevance, quality, freshness, diversity, speed and resistance to manipulation, often with incomplete or messy data.
Improving one area can easily make another worse. For example:
As SEOs we might ask if something is a ranking factor; but search engineers are more likely to ask: what problem is this signal solving, how reliable is it, and what happens when people start gaming it?
There is no such thing as a perfect ranking signal or factor, and it’s definitely not the case that one single signal or factor determines ranking position. Instead, rankings are determined by a combination of lots of imperfect signals or factors being balanced against one another.
I’m not using MCPs as much as I should yet (shame on me!) but I have a sizable backlog of ideas for where it could help.
The biggest opportunity for me is connecting an LLM to all the different data sources I use, so that I can query them directly rather than exporting data from six different places and repeatedly uploading it into whichever LLM I am using.
For technical SEO, I would particularly like to bring together data that is difficult to analyse side by side. For example:
It’s not that I can’t connect some of these things, it’s that I haven’t. That means that when I’m reporting or investigating an issue, I often have to move between several tools to correlate a technical change with what I am seeing in traffic, crawling or user behaviour.
Log files are a big use case for me. We have an enormous amount of log data, and identifying patterns or investigating what particular bots are doing can take a lot of filtering and processing. I would love to give an LLM controlled access to that data and be able to ask questions in natural language, rather than manually slicing it every time.
My general rule is if I’m currently exporting data and uploading it to an LLM, then that’s probably a candidate for an MCP (i.e. the LLM could access the current data directly through an approved connection instead of relying on a static file I pasted into a chat).
Screaming Frog may actually be the first one I properly test as it now has its own MCP integration, which can run crawls, analyse the results, and export or manipulate crawl data through an AI assistant.
In terms of getting buy-in, you have to remember that this is still very new and quite difficult to understand for people who do not regularly experiment with AI. Unfortunately, those are often the same people whose approval you need for budget, engineering time, security access, or data permissions.
In the past, whenever I have wanted to introduce something unfamiliar, I have built out a small proof of concept. Once people can see it working, it is no longer theoretical. They do not need to understand the protocol itself; they can see that a task which previously took several hours now takes a few minutes, or that you can ask a question across several datasets without manually assembling them first.
So I would start with one contained, low-risk use case, ideally using read-only access and non-sensitive data. Demonstrate the experience, quantify the time or insight it provides, and use that to make the case for expanding it.
Do not try to get people excited about MCPs. Get them excited about the problems you can solve using an MCP.
You’ve asked the right person because I consider myself constructively lazy!
What does that mean? I’m too lazy to want to repeat work that I’m not learning from, but also too ambitious to leave the work undone. So I automate it, and scripts are often the quickest and cheapest way to do that.
I think a pipeline has outgrown being “just a script” when:
However, building a formal tool also has a cost.
The moment you involve engineering, you need to compare the value of that tool with everything else those engineers could be doing for the business. Sometimes an imperfect script that you can maintain yourself is still the right solution.
There is also a useful middle ground between a raw script and a fully engineered product. I build a lot in Google Colab, where I can keep the code online and add instructions, controls or generated HTML to make it feel more like a tool. Colab supports executable code alongside text, images and HTML within the same notebook.
You can also use AI app builders such as Bolt.new. You describe the application you need, and it can generate the interface and underlying application, as well as provide hosting.
Before rebuilding anything, though, I would first make the existing pipeline more reliable:
Generative AI will never be completely deterministic, so reliability is not only about whether the code runs. You also need to test whether the quality of the answer remains acceptable when the model, prompt or input changes.
My rule would be to keep scripting while it is saving you time and you can understand, test and maintain it. Start turning it into a product when other people depend on it, failures become expensive, or maintaining it starts becoming a job in itself.
Yes, I think technical knowledge is becoming even more important too.
One misconception is that AI search has introduced something completely new, so SEOs need to throw away everything they already know and start again. I don’t think that is true. The technology is different, but many of the challenges are the same.
AI search engines are still search engines. As such, you still need to understand:
For example, with Google search, discovery might happen through internal links and XML sitemaps. An AI search engine may instead discover your page through Google, Bing or another search index. It is still a discovery question, but the route may be different.
The same applies to crawling and rendering. Google can render JavaScript, but some AI crawlers and agents may rely much more heavily on the initial HTML response. If your important content only appears after JavaScript runs, they may not see it.
Some agents may also interact with a page visually, using screenshots or the accessibility tree. If important information is hidden behind dropdowns, interactions or poorly implemented components, that can create another barrier.
But none of this is completely unfamiliar. Google has always advised us to make important content accessible and visible.
So my advice is to strengthen the classic technical SEO skills: crawling, rendering, indexation, internal linking, structured data and accessibility. Then start asking how each of those principles applies differently to AI search engines and agents.
The skills are not being replaced. They are being applied to a wider range of machines.
I genuinely think agentic is a big part of the future of ecommerce.
People have always looked for shortcuts and ways to remove friction from tasks they do not enjoy. We all know someone who hates shopping. Imagine being able to tell an agent what you need, allow it to research and compare the available options, and only become involved when it needs a preference clarified or a purchase approved.
That is the promise of agentic ecommerce: rather than just asking AI for product recommendations, we’ll be allowing it to discover, evaluate and potentially purchase products for us.
If you want to learn more about this topic, I would start by seeking to understand how LLMs and agents work. You don’t necessarily need to know how to build an agent, but you should understand how an agent:
The next step would be testing whether or not agents can actually use your website.
Some agents may interact with a website through its rendered pages, including the DOM and accessibility tree, while others may access information through feeds, APIs or dedicated commerce integrations. (Google specifically recommends considering how browser agents understand visual rendering, the DOM and the accessibility tree.)
I would test questions such as:
Your product data also becomes incredibly important. Agents need accurate, structured and current information about titles, descriptions, images, pricing, availability and other product attributes. OpenAI’s current merchant guidance, for example, asks businesses to provide structured product feeds containing precisely this information.
Then I would start learning about the different ways agents can connect to ecommerce businesses.
MCP may be one of those routes, particularly where you want to expose particular data or tools to an AI application. However, it is not the only protocol worth watching. OpenAI has its Agentic Commerce Protocol, while Google has introduced the Universal Commerce Protocol for discovery and purchasing through surfaces such as AI Mode and Gemini.
This is evolving quickly, so I would not become overly attached to one specific protocol. Instead, understand the underlying requirements.
I would also start using shopping agents yourself. Give them real ecommerce tasks, watch what they do, and test them against your own website. You will learn much more from seeing where an agent fails than from reading twenty articles about what agents might eventually do.
I think ecommerce SEOs’ roles are going to expand. We will still optimise pages so that search engines and people can discover products, but we will increasingly need to make sure machines can understand the inventory, compare it accurately and take permitted actions with it.
We have spent years making websites crawlable. The next challenge is making businesses usable by agents.
Yes, I think structured data is worth implementing and it definitely isn’t only for ecommerce websites.
At Alamy, we receive a significant amount of traffic from traditional search, and structured data helps search engines understand the entities and information on a page while making that page eligible for richer search features. Google even supports specific SoftwareApplication structured data, alongside things such as Organization, Article and BreadcrumbList.
To give you a more concrete example, on Alamy we use ImageObject schema heavily and one of the fields in this schema is what allows us to show licensable badges on Google image search.
There is also an indirect AI-search benefit. Many AI search experiences rely on web retrieval, search indexes or third-party search providers to find relevant sources. Anything that improves the ability of these systems to interpret and surface your content can therefore support its discoverability in those experiences too. Bing has also said that structured content can help AI systems interpret and summarise pages more effectively.
I wouldn’t position schema as a magical AI-ranking tactic, though. It won’t guarantee rankings, rich results or citations. Instead, I’d position it as giving machines clearer, more consistent information about your company, software and content.
For buy-in, try not to sell “implementing schema” as the outcome. Tie it to the business benefit:
Start with the schema types that genuinely match the visible content on your pages, prioritise those with a clear search benefit, and position your ask as a small, measurable test rather than a large technical request.
I do find them useful, but I treat them as directional rather than tools that can show the full picture.
GA4 helps me understand what people do after arriving from AI assistants, while Search Console and Bing give me more visibility into where my content is appearing and which pages or topics are being cited.
I’m not changing the fundamentals of my strategy because of these tools, but they are helping me ask better questions:
Even if these tools don’t give us the full journey (yet?), they’re a very welcome step forward from manually testing prompts and hoping the results are representative.
I use a prioritisation matrix that looks at business impact, scale, confidence and resource required before something moves up the list.
The biggest priorities are usually:
For example, if I see a bot crawling the site but creating no value for us, I would not necessarily block it immediately. I would set an alert for when it passes a daily threshold that makes it worth investigating, and then a second, higher threshold where blocking becomes urgent. That stops the team spending time on something before the impact justifies it.
Scale matters enormously too. A small template-level fix affecting millions of pages may be much more valuable than fixing a severe-looking issue on a handful of URLs.
Context is also everything. John Mueller once jokingly told me he had found a 404 page on our site. I told him we had tens of thousands of them, but with around two billion URLs across the site, that was still a very small percentage and therefore a low priority. On a much smaller site, the same number of 404s could indicate a serious problem.
The technical work with the biggest impact is usually work that removes a barrier across large, valuable sections of the site: incorrect canonicalisation, poor internal linking, server errors, rendering failures, broken migrations or systems generating huge numbers of unnecessary URLs.
I think SEOs often overprioritise issues because a tool labels them as errors. For example: long title tags, missing meta descriptions, minor heading changes, or chasing a perfect crawl score.
Those things can matter, but only in context. The question should always be how much value will fixing this create, how many important pages does it affect, and what else could we do with the same resource?
Original images can be valuable because they give the page something distinctive and may offer a better opportunity to appear in image search. However, an image does not have to be original to contribute value, and there is no technical threshold where using the same image more than three times becomes problematic.
The more important question is whether the image is relevant to each page it appears on. Google’s own guidance recommends placing high-quality images near relevant text because the surrounding content helps Google understand the image and its relationship to the page.
If you are using the same image across several pages, I would ask why. If all of those pages cover almost the same subject and search intent, the bigger issue may be that the pages themselves overlap, not that they share an image.
There are also perfectly legitimate reasons to reuse an image. A logo might appear across an entire website, a product image might appear on a category page and its product page, or the same supporting image might be relevant to several related pieces of content.
The same principle applies when an image has already been used by many other websites. Imagine you are writing about a historical event from the late 1800s. You obviously cannot take your own photograph, so you might use an archival image that has appeared in books, journals and many other websites. That does not make the image useless. If your article provides relevant information and someone clicking the image finds content that genuinely explains or adds context to it, it can still be a useful search result.
Where I would be more cautious is if you’re adding a generic stock image simply to break up a long piece of text. If the image has very little connection to the subject, there is no strong reason for Google to surface your page for searches around that image.
So, I would not count how many times an image has been used. I would ask whether it adds something useful to the page, whether the page provides meaningful context for it and whether each page has a distinct purpose of its own.
The biggest mistake I see is treating localisation as translation.
You cannot take the same English landing page, translate it word for word and expect it to perform equally well in every country.
Expressions, tone, terminology and even the way people search can be completely different. Even the USPs you highlight might need to change from country to country.
That applies even between countries using the same language. When I first moved to the UK, I kept telling a male colleague that I preferred black pants. I meant black jeans; he thought I meant underwear. That was my first lesson in localisation!
So I would involve native speakers, carry out keyword research in each market and adapt the examples, offers, imagery and messaging to what people in that country actually expect.
From a technical perspective, I would not recommend one particular platform over another. Instead, I would choose a stack that supports:
The technology should make localisation easier, but it will not replace local knowledge. The best setup combines a flexible CMS, clean international SEO foundations, and people who genuinely understand each market.
We pay our authors, speakers & team to bring you helpful content like this.
We aim to always keep our content and community free and accessible.
If you've found value in WTS, please consider supporting us through our Buy Me a Coffee initiative.
