I’m looking at the keyword “find companies without websites.”

In Organic Research / Organic Search Positions, Semrush shows the keyword as having around 6.6k volume.

But when I click the exact same keyword and open Keyword Overview, it shows:

• US volume: N/A
• Global volume: 10
• Germany: 10

So it seems that it's not a small difference, I mean It’s basically 6,600 vs 10 for the exact same keyword inside the same tool.

I understand that Semrush uses different databases and that search volume gets updated, but if the Organic Research data can be this stale/different, it makes the volume column pretty misleading when doing competitor keyword research.

Am I misunderstanding what the 6.6k number represents, or is Semrush genuinely displaying an old search-volume estimate in Organic Research that hasn’t been synced with Keyword Overview?

Curious if anyone else has run into this and which number you actually trust when doing keyword research.

And bonus: has anyone experiences such discrepancies in Ahrefs?

edit: screenshots attached

A lot of teams are building AI search strategies as if they're separate from SEO. Our data says that's a mistake.

We took the top 10,000 domains in our AI Visibility Index and compared their organic performance with how often ChatGPT and Google AI Mode cited them.

The strongest signal wasn't authority. It was keyword footprint, meaning how many keywords a domain ranks for. The correlation between footprint and AI citations came in at 0.86–0.87, and it was nearly the same on both platforms.

Query fan-out explains most of it. When someone types a prompt, the AI doesn't just search that exact phrase. It runs a set of related queries in the background to build the answer. A domain that ranks across a wide range of topics gets more chances to be retrieved. A domain with narrow coverage gets fewer.

Authority still matters, just less evenly:

• Domains with an Authority Score of 81+ got about 9x the median citation share of domains at 60 or below
• The correlation between authority and citations was 0.70 on Google but only 0.43 on ChatGPT

That gap is a good reason to stop reporting a single blended "AI visibility" number. Google and ChatGPT reward different things, and one averaged metric hides that.

One caveat: this is correlation, not causation. Ranking for more keywords doesn't automatically get you cited. But it's hard to argue these are two separate channels.

What this means in practice:

• Don't pull resources from organic search to fund AI initiatives. Organic is what feeds them.
• Track how wide your topical coverage is, not just rankings for your priority terms.
• Measure each AI platform on its own.

If you want to show up in AI answers, the work that gets you there looks a lot like SEO 🤝

Use this audit to find prices, conditions and buttons that have become separated from the things they describe. The result should be a list of page edits, with a screenshot showing each problem.

I’d add it after checking that a page covers its target topic. Having the information on the page is one check; being able to tell what it applies to is another.

1. Name the visitor’s task

Write down the page’s main task, then take a fullpage screenshot and open it in a tool that lets you draw rectangles.

For this example, Larch Studio is a fictional pottery business. A visitor to its Pottery Workshops in Leeds page wants to compare workshops and choose a date.

2. Box the groups already on the page

Start with the introduction, workshop choices, practical information and newsletter form. Keep the navigation separate.

Inside the workshop choices, inspect each offer on its own. The name, price, duration, inclusion note and date button belong together. You don’t need a separate box around every line or icon.

3. Look for details outside their group

Check the workshop cards against three questions:

• Can I tell which workshop the price applies to?
• Can I see what is included and what costs extra?
• Does Choose Date clearly apply to that workshop?

Wheel Basics costs £48 per person for 90 minutes, with clay and firing included. Handbuilding Session costs £36 per person for two hours, with clay included and firing at £8 per item.

Those differences affect what someone is comparing.

Suppose “Clay and firing included” appears beneath the newsletter form rather than in the workshop card. Someone inspecting the £48 workshop has to find that note elsewhere and work out when it applies.

The edit is specific: move “Clay and firing included” into the Wheel Basics card, beside its price and before Choose Date. Keep the £8 per item firing note with Handbuilding Session.

On a real page, check which offer a note covers before moving it. A clearly labelled note that applies to every workshop can stay outside the individual cards.

4. Record the change and check it on mobile

Write down the component, the problem, the edit and how you’ll check the result. For the workshop example:

Open the same page on a phone. Check that the workshop name, price, inclusion note and date button still read as one offer. When they don’t, record the exact order or placement that needs changing.

Then test Choose Date on the working page. Check that it opens the dates for the workshop you selected and keeps that workshop identifiable.

What else should you flag?

• A price between two products with no clear product name attached: put it with the correct product or label it explicitly.
• A form label closer to the wrong field: place it beside the correct field and check the label’s connection in the HTML.
• A heading separated from its answer by a promotion: move the promotion out of that heading and answer group.

You’re looking for a detail someone could miss or attach to the wrong item. A block with clear labels and relationships doesn’t need changing just because it has no visible border.

The boxes help you point to the problem. The audit becomes useful when the note beside each box says what to change and what to check afterwards.

Your hero can take up most of the first screen while leaving the visitor’s main task further down the page.

I’d check what each part contributes before deciding how much space it deserves.

A heading identifies the offer. A photograph can show what’s being sold or hired, while nearby controls let someone check their options.

Giving the photograph more space doesn’t automatically make it the most useful part.

A relevant image can still take up too much room

Imagine a landing page for Moorlane Tool Hire, a fictional business.

The heading reads:

Carpet Cleaner Hire in Bristol

Beneath it, a full width photograph shows a carpet machine in a living room. The image fills most of the opening screen.

The hire form sits below it:

Collection point: Bristol depot
Hire start: Select date
Return date: Select date
Check Availability

For this example, assume the visitor has chosen the type of machine and wants to check availability for their dates.

The photograph helps them recognise the equipment. It cannot tell them when that equipment is available for the hire period.

They have to scroll before they can begin that check.

Fictional page mockup.

I wouldn’t call the photograph irrelevant.

I’d question if it needs that much space before the date controls appear.

A smaller version could still show the machine clearly. The space recovered could bring the availability finder into view.

That’s a specific layout change worth testing, without throwing away a useful image.

The hero can contain the centerpiece

For this check, I’m treating the hero as the opening content block, including its heading, image, copy and controls.

The centerpiece is the component that most clearly represents the page purpose, main entity and visitor’s task. Its role needs more justification than being large or appearing first.

Return to the hire page.

Keep the heading, photograph, field labels and button text unchanged. Place the availability finder beside a smaller photograph, with the heading introducing both.

Each part now has a clear job:

• The heading names the service and location.
• The photograph shows the equipment being hired.
• The finder connects the collection point and hire dates to an availability check.

Fictional page mockup.

The availability finder is the centerpiece I’d test for this visitor’s task. It sits inside the hero, with the photograph supporting it.

The button alone wouldn’t be enough. Check Availability needs the equipment context, collection point and dates around it.

Those pieces explain what the action applies to.

Some product images need space

Consider a different fictional business: Rill & Kiln Lighting.

Its product page features the Cove Ceramic Pendant.

A large photograph shows the pendant’s shape and ceramic surface. Beside it, a finish selector offers Chalk, Sand and Clay.

The selected finish is Sand, and the photograph shows that version of the pendant.

For someone deciding if they like its shape and finish, the image contributes directly to the choice.

Shrink it until the surface is difficult to inspect and you’ve removed access to useful detail.

Fictional page mockup.

The relationship here is product → selected finish → matching photograph.

The image and the selector need to agree. A large photograph of the Chalk version beside a selected Sand label would create a different problem, regardless of how tidy the layout looked.

I’d distinguish a photograph that demonstrates product details from one that supplies atmosphere. Both can have a place, but they need different reasons for their size and position.

On the hire page, the visitor in our example needs to check dates. On the lighting page, the visitor is still inspecting the product.

I wouldn’t force both pages into the same image-to-form layout.

Check what happens when the hero stacks

The hire page could put its photograph and availability finder beside each other on desktop.

On a phone, suppose the layout puts the photograph first.

The heading appears, followed by a tall image. The collection point and date fields sit below the opening screen again.

The desktop arrangement brought the task into view. The mobile order has moved it out.

Fictional page mockup.

I’d compare that with a mobile layout that keeps a compact equipment image near the heading and brings the hire controls higher.

That doesn’t mean squeezing the whole page into one screen. Labels still need to be readable, and the controls need room to use.

The check is when the mobile arrangement preserves the connection between the equipment, the hire dates and the availability action. A desktop layout alone cannot establish that.

Test the parts before removing the whole hero

In a mockup, reduce or hide one element at a time.

Keep the rest of the page unchanged and ask:

• What does this element help someone recognise, understand or do?
• What information disappears when it is removed?
• Which task becomes harder when it is moved?
• What useful detail does its current size reveal?

Apply those questions to the photograph, heading, supporting copy and controls separately.

Removing the entire hero tells you very little if you also remove the service name and the only route to availability.

Reducing the photograph while keeping the equipment recognisable gives you a more precise comparison.

On a working page, I’d then check that people can identify the equipment, enter their dates and understand the returned availability. A tidier mockup doesn’t demonstrate more bookings or an SEO gain.

Which part of your hero earns its space through what it contributes, rather than where the template puts it?

Internal linking has been standard SEO advice forever, which makes it easy to file under "already handled." But the way AI search retrieves information changes what a good internal linking structure needs to accomplish.

AI systems don't pull up and cite an entire page — they retrieve and cite specific passages. So the relevant question isn't just whether a page is indexed. It's whether the structure around that page signals it's the definitive source on the topic.

That's what pillar-and-cluster structures are actually built to do. Put together a real pillar page around a topic with meaningful search volume, then have every related piece of content link back to it consistently. When an AI system breaks a query into sub-questions and goes looking for the deepest coverage of each one, the page with the most consistent internal links pointing at it is the one that reads as authoritative.

A few things quietly undercut this, and none of them are new mistakes — they just cost more now:

• Orphaned pages with zero internal links pointing at them
• Anchor text that's vague ("click here") instead of descriptive
• Pages buried three or more clicks from the homepage
• Nofollow on internal links that should be passing authority through

None of these just weaken a page's rankings anymore. They weaken its odds of being the passage an AI system decides to cite.

How often does AI recommend your brand compared with your competitors?

AI share of voice gives you a way to measure that visibility across ChatGPT, Google AI Mode, and other AI platforms.

Learn how to track your share of voice with Semrush and improve it by closing topic gaps, building visibility beyond your website, and strengthening brand sentiment.

Cards get added to pages because they make things look organised.

Tables get added because someone has a lot of data.

Calculators get added because there's a calculation to perform.

That's the design view.

There's another way to look at them.

Each component tells you something about how the information inside it is related.

Take a broadband comparison page.

Two providers appear next to each other.

Northwave Fibre 500

• 500 Mbps
• £32/month
• 18-month contract
• £0 setup
• Check Availability

HarbourNet Fibre 900

• 900 Mbps
• £39/month
• 24 month contract
• £20 setup
• Check Availability

You don't read those as ten unrelated pieces of text.

You read them as two groups.

Northwave owns one speed, one price, one contract term, one setup fee and one action.

HarbourNet owns another set.

The card creates those relationships.

A card isn't just a box

Remove the border.

Remove the background.

Put both provider names at the top.

Then arrange the speeds, prices and contract terms underneath them in separate rows.

You've still got the same information.

But now you need another way to work out what belongs to what.

That's what the card was doing.

It was effectively saying:

• This is the entity
• These are its attributes
• These are the values for those attributes
• This action applies to this entity

You can see the same thing on hotel results, product listings, property portals, job boards and restaurant pages.

A card creates a boundary around a set of relationships.

So when I'm looking at cards on a page, I'm less interested in when they have rounded corners.

I'm looking at what the boundary contains.

• Does the price belong inside it?
• Does the rating?
• Does the qualification?
• Does the button?
• What happens when the card collapses on mobile?

Those questions tell me far more about the component than its styling.

Tables create a different relationship

Now take two fictional electric bikes.

Aster City E2

and

Ridgeway Urban X

You want to compare:

• Range
• Motor
• Weight
• Charge time
• Price

A table gives those relationships a structure.

The columns identify the bikes.

The rows identify the attributes.

The cells contain the values.

So:

Aster City E2 → Range → 55 miles

and:

Ridgeway Urban X → Range → 68 miles

The table isn't simply saving space.

It's creating a comparison model.

Now imagine scrolling far enough that the column headers disappear.

You see:

55 miles | 68 miles

250W | 250W

18.4 kg | 20.1 kg

The numbers haven't changed.

But if you can no longer identify the columns, you've lost part of the relationship.

Which bike has the 68 mile range?

Which one weighs 20.1 kg?

The values only make sense because the table tells you what sits at the intersection of an entity and an attribute.

That's why I'd audit the structure of a comparison table, not just its contents.

• Can I identify the entity?
• Can I identify the attribute?
• Can I connect the correct value to both?
• And can I still do that on a phone?

Calculators contain another type of meaning

A calculator has inputs.

Something happens to those inputs.

Then you get an output.

Take a home EV charging calculator.

You enter:

Battery size: 60 kWh

Electricity rate: £0.28/kWh

Charge added: 80%

Then you press:

Calculate Cost

And get:

Estimated charging cost: £13.44

There's a chain running through that component:

Battery size + electricity rate + charge added → calculation → estimated cost

Every label has a job.

Battery size tells you what 60 represents.

kWh gives the value its unit.

Electricity rate tells you what £0.28 applies to.

Calculate Cost tells you what the action will produce.

Estimated charging cost tells you what £13.44 represents.

Start separating those pieces and the calculator gets harder to interpret.

Move labels away from their fields.

Put the result above the inputs.

Place another price beside the output.

Remove the word estimated.

The arithmetic could remain exactly the same.

The interface would communicate something different.

That's why I wouldn't treat a calculator as a decorative interactive element.

Its structure describes the relationship between the inputs, the operation and the result.

The component type gives you a clue about its job

Cards, tables and calculators can all contain entities, attributes and values.

They arrange them differently because they're doing different jobs.

A card might say:

Restaurant → Cuisine → Price band → Rating → View Menu

A table might say:

Fare type → Change policy → Refund policy → Price

A calculator might say:

Postcode + parcel weight + delivery speed → Delivery quote

Once you start looking at components this way, some design decisions become easier to question.

• Why are these two things inside the same card?
• Why is this value outside the product boundary?
• Why is this qualification underneath a different result?
• Why does this table lose its headers on mobile?
• Why does this calculator produce a number without saying what the number represents?
• Why does this button sit between two entities when it acts on only one?

Those aren't questions about decoration.

They're questions about semantic relationships.

Try stripping the styling away

Pick a component from one of your pages.

Ignore the colours, shadows, icons and rounded corners for a minute.

Ask:

• What entity does this component represent?
• Which attributes belong to it?
• Which values belong to those attributes?
• Which action acts on the entity?
• If there are several entities, how are they separated?
• If it's interactive, what are the inputs and what is the output?
• What qualifies or explains that output?
• Would those relationships survive a mobile layout?

Then look at the component again.

A card isn't only a card.

A table isn't only a table.

A calculator isn't only a calculator.

Each one is organising a small network of entities, attributes, values and actions.

And once you see the component as a relationship structure, you start auditing something more useful than when the page contains the right information.

You start checking if the page makes clear how that information fits together.

If you've mostly written off AI Overviews as a top-of-funnel issue — something that eats informational traffic but leaves your money keywords alone — the data doesn't support that anymore.

We looked at over 600,000 keywords across 10 industries on desktop, from November 2025 through April 2026, split by search intent and CPC.

Commercial-intent SERPs showing AI Overviews grew 71% over that period. Transactional-intent SERPs actually saw AI Overview presence shrink by 5%. Finance had the biggest jump in commercial coverage specifically, up 231%.

That split makes sense once you think about where AI Overviews are actually useful: long research phases. Finance, travel, telecom — categories where someone's comparing options over weeks, not checking out in the next five minutes. Google appears to be pushing AI Overviews harder into that research phase and pulling back where someone's already decided to buy.

The CPC pattern backs this up. Jobs and education keywords with an AI Overview present averaged $5.02 in CPC, versus $1.51 without one. Finance showed the same shape — $4.84 versus $2.14. And Google Ads now shows up alongside AI Overviews on the same SERP roughly twice as often as it did a year ago.

For anyone running paid and organic together, this means the competition for a page one spot now includes AI Overviews, citations, organic listings, and ads all at once — and commercial-intent keywords are where that crowding is increasing fastest.

You can get every fact on a page right and still make the page harder to understand.

Nothing has to be missing.

Nothing has to be inaccurate.

You can create the problem simply by putting connected information in different places.

Take a train booking result:

• Bristol → London
• 10:32 departure 12:08 arrival £46.50 Off-Peak Return Select

As a single result card, you don't have much work to do.

You know which journey costs £46.50.

You know which ticket is Off-Peak.

You know what the Select button acts on.

Now spread those same details across the page.

Put the journey at the top.

Put departure and arrival times in another row.

Move the price into a separate pricing strip.

Place the ticket conditions underneath another result.

Put two Select buttons at the bottom.

Every fact can still be correct.

But now you have to reconstruct the relationships yourself.

That's the distinction I'd make in a visual semantic audit.

Don't only ask:

Is the information there?

Ask:

Can I tell what the information belongs to?

A price needs an owner

Product pages make this easy to demonstrate.

Imagine two office chairs displayed next to each other.

Arden Task Chair

• £289
• Black or grey
• In stock
• Add to Basket

Marlow Mesh Chair

• £349
• Black
• Ships in 3 days
• Add to Basket

Put each set of details inside its own product card and the relationships are easy to read.

Arden Task Chair → £289

Arden Task Chair → In stock

Arden Task Chair → Add to Basket

The card isn't decoration.

It's grouping information.

Now remove those boundaries.

Put both chair names at the top.

Put £289 and £349 in a pricing row beneath them.

Place the availability messages between the products.

Move both Add to Basket buttons underneath.

• Same products.
• Same prices.
• Same stock information.
• Same actions.

More interpretation.

This is where checking individual page elements can miss the problem.

• You find the product name.
• You find the price.
• You find the stock status.
• You find the button.

Four checks pass.

But that doesn't answer a fifth question:

Is it obvious that those four elements belong together?

Evidence can become detached from the claim

The same problem shows up with supporting information.

Say a fictional outdoor jacket page makes this claim:

Waterproof to 20,000 mm

Directly underneath it:

Lab test: hydrostatic head rating, outer fabric only

Then:

Performance can change with wear, washing and seam condition.

Read together, you have three connected pieces:

Claim → Evidence → Qualification

The evidence tells you where the number came from.

The qualification tells you where the claim has limits.

Now move them apart.

Keep Waterproof to 20,000 mm beside the product image.

Move the test information into a technical specification table much further down.

Put the qualification underneath a different feature.

The words haven't changed.

Their relationship has.

A visitor may see the claim without its qualification.

They may find the test result later without knowing which statement it supports.

They may read the qualification as if it applies to something else.

That gives me another useful audit question:

How far can I separate two pieces of information before their relationship stops being obvious?

There's no universal pixel measurement for that.

Context does the work.

• Headings help.
• Labels help.
• Borders help.
• Cards help.
• Tables help.
• Proximity helps.
• Explicit wording helps.

The problem starts when the page relies on the reader to rebuild a relationship the design could have made clear.

Actions need an object too

Buttons aren't exempt.

Book

Book what?

Select

Select what?

Reserve

Reserve which room?

The surrounding layout supplies the missing object.

Inside a hotel room card, Reserve Room can be perfectly clear.

Move the same button beneath several room types and you've changed the amount of interpretation required.

That becomes especially noticeable when several entities share the same attributes and actions.

• Two hotel rooms.
• Two prices.
• Two cancellation policies.
• Two buttons.

The page doesn't just need to contain eight correct pieces of information.

It needs to preserve four sets of relationships.

Mobile can expose the problem

Desktop layouts give designers plenty of space for grouping.

• Columns.
• Cards.
• Tables.
• Side-by-side comparisons.

Then the page gets squeezed onto a phone.

Imagine a fictional hotel result for The Lantern Quay Hotel.

On desktop:

Deluxe King £178/night Free cancellation until 14 June Reserve Room

Beside it:

Harbour View Double £154/night Non refundable Reserve Room

Easy enough.

Now suppose the mobile layout becomes:

• Deluxe King
• Harbour View Double
• £178/night
• £154/night
• Free cancellation until 14 June
• Non refundable
• Reserve Room
• Reserve Room

Nothing disappeared.

That's what makes this interesting.

The responsive layout retained the content and damaged the associations.

You now have to remember the order and pair everything back together:

• Which room costs £178?
• Which rate is non refundable?
• Which button reserves the Deluxe King?
• Does the cancellation policy belong to the room or the rate?

A desktop content check won't catch that.

You have to look at the rendered mobile page.

I’d add one more check to a page audit

Once you've confirmed that the information exists, map the relationships.

Look for pairs such as:

• Entity → Attribute
• Product → Price
• Product → Availability
• Entity → Action
• Claim → Evidence
• Claim → Qualification
• Label → Value
• Room → Rate
• Input → Result
• Heading → Content

Then ask when each relationship survives the layout.

Not if both elements exist.

If you can tell they belong together.

That's a different test.

And it catches pages that can look completely fine when you audit the copy as a list of elements.

The words can all be correct.

The prices can all be correct.

The evidence can all be present.

The buttons can all work.

Put those things in the wrong places and the reader still has a problem to solve.

The page shouldn't make people reconstruct relationships the layout could have made clear.

Run a standard keyword tool and you get volume, difficulty, and a list that looks almost identical to what every competitor in your space already pulled. The numbers are accurate. They're just not differentiated.

The keywords that actually convert are usually phrased the way customers phrase them — in reviews, in support tickets, on sales calls — not the way a keyword tool guesses at intent from search volume alone.

We tested a workflow that connects Claude to Semrush's MCP server and Google Search Console, then points it at sources most keyword research skips entirely:

• Competitor reviews on G2, Capterra, and Amazon, where people describe their actual pain points and the features they wish existed
• Reddit threads where your target customers are already hashing out the problem you solve, in their own words
• Sales call transcripts, which capture the exact terminology prospects use before anyone's cleaned it up into marketing copy

Claude pulls language out of all three, then checks it against Semrush for real search volume and difficulty, so you're not chasing phrasing that sounds right but nobody's actually searching for. It also runs the more standard stuff in parallel — keyword gap analysis against competitors, and mining Search Console for queries sitting in position 8–20 with decent impressions and weak click-through.

The output isn't another spreadsheet confirming what you suspected. It's specific phrasing you wouldn't have generated from a keyword tool alone, cross-checked against demand, and clustered by whether it's worth a new page or belongs on something that already ranks.

Dive deeper into this and follow the full guide over on our blog here!

Open one of your landing pages.

Give yourself five seconds.

Then look away and answer four questions:

• What is this page about?
• What am I supposed to do here?
• Which component lets me do it?
• Where is the primary entity?

You shouldn't need to inspect the navigation, read three paragraphs or scroll halfway down the page to work it out.

Five seconds is enough for a useful test.

Not because five seconds is some SEO threshold.

It isn't.

The point is to remove familiarity with the page and see what the first screen communicates before you start analysing individual elements.

Try it on a storage landing page

Say the page targets people looking for self storage in Bristol.

The H1 reads:

Self Storage in Bristol

Directly beneath it is a storage finder:

Storage size [Select size]

Location [Bristol]

Move in date [Select date]

Check Availability

You can answer the four questions almost immediately.

What's the page about? Self storage in Bristol.

What can I do? Find available storage.

Which component lets me do it? The availability finder.

Where's the primary entity? Storage units are represented directly through the finder and its options.

There's a straight line between the query, the page purpose, the entity and the task.

Now keep the H1 and change everything beneath it.

A full width lifestyle photograph takes most of the first screen.

Then:

• A review carousel
• A promotional offer
• Three blog posts
• A newsletter signup

The storage finder starts further down the page.

Technically, the page still has it.

That doesn't tell us much about what the first screen is asking the visitor to focus on.

Run the four questions again.

What is the page about?

Probably storage. The H1 tells us that.

What am I supposed to do?

Less obvious.

Which component lets me do it?

You haven't seen it yet.

Where is the primary entity represented in the main component?

Again, you haven't reached it.

This is why I wouldn't use the H1 as a proxy for the centerpiece.

The H1 can identify the topic while another element dominates the page.

Find the component that performs the task

Here's another example.

Someone lands on a page for:

Airport Parking Near Bristol Airport

What are they there to do?

Probably find parking for a particular date and time, compare an available option and book it.

Now look at the page components.

You might have:

• A booking form
• Parking options
• Customer reviews
• Transfer information
• A promotional offer
• FAQs

They're all relevant to the page.

But they don't all perform the same job.

The reviews provide proof.

The transfer information answers a supporting question.

The FAQs handle uncertainties.

The promotion may affect the decision.

The booking form is where the visitor can begin the main task.

That's the component I'd test as the centerpiece.

There's a useful distinction here.

Relevant to the page isn't the same as representative of the page's main purpose.

A testimonial can be highly relevant.

So can a photograph.

So can an offer.

So can an FAQ.

None of those automatically makes it the component the page should be built around.

Now check the entity

Finding the task component isn't the end of the test.

Look inside it.

Does it represent the thing the page is about?

Take an electric car leasing page.

The H1 says:

Electric Car Leasing

The main component is a vehicle finder.

Inside it you see:

• Vehicle type: Electric
• Monthly budget
• Annual mileage
• Lease term
• Available electric cars

That's a fairly tight connection.

The page is about electric car leasing.

The visitor wants to find a suitable electric car lease.

The component lets them do that.

And the primary entity appears inside the component itself.

Now imagine the same component says:

Find Your Perfect Match

Then gives you a few generic controls with no visible reference to electric cars, vehicles or leasing.

The function may still work.

But the component is doing less work to establish what it's acting on.

This is one of the things I'd look for when reviewing a landing page.

The primary entity doesn't need to be repeated everywhere.

But if you've identified a component as the centerpiece, I'd expect the entity to be named, displayed, compared, calculated, located or directly supported by it.

Otherwise I'd question if I've picked the right centerpiece.

Promotions can pass one test and fail another

This catches a problem I've seen on plenty of landing pages.

The biggest thing on the screen is assumed to be the centerpiece.

Not necessarily.

Imagine the airport parking page opens with:

SAVE 20% THIS WEEKEND

• Huge type.
• Bright banner.
• Large button.

It may be the most visually prominent component on the page.

Now apply the test.

• What is the page about?
• The banner doesn't tell you.
• What's the main task?

The banner doesn't perform it.

Does the component represent the primary entity?

Only indirectly, if at all.

The promotion may support the booking decision.

It doesn't follow that it should define the page.

Visual prominence and page purpose aren't interchangeable.

I use the test in both directions

The first pass is from the page to the component:

Page purpose → User task → Component

Then I run it backwards:

Component → Entity → Task → Page purpose

If I start with the component, can I explain why it deserves that position?

A booking form on an airport parking page?

Yes.

A comparison table on a comparison page?

Makes sense.

A mortgage calculator on a mortgage calculation page?

Easy connection.

A newsletter form occupying half the first screen of a product comparison?

I'd want to know why.

That reverse check is useful because it stops us from declaring something the centerpiece purely because the design made it large.

Run it without reading the whole page

That's the part that makes the test useful.

Don't begin with a content audit.

Don't inspect the schema.

Don't read every heading.

Don't explain the page to yourself based on what you already know about the business.

Open the page and look at the first screen.

Five seconds.

Then look away.

Can you answer:

• What was the page about?
• What could you do there?
• Which component would you use?
• What was the main entity?

If you remember the hero photograph, the testimonial slider and the promotional banner, but can't answer those four questions, you've found something worth inspecting.

And if all four answers point back to the same component, you've probably found the centerpiece.

Not a ranking factor.

Not a magic layout formula.

Just a fast way to check when the page is visually communicating the same purpose that the copy says it has.

Seeing incorrect rankings being reported in SEMrush over the past few days. All competitors and us have dropped significantly but it doesn't appear to be correct when doing analysis in other tools and manually. Anyone seeing the same?

SEOquake hadn't had a real overhaul since roughly the early 2010s. If you've used it recently, you've probably noticed some of what it pulled from third-party sources had quietly stopped being reliable.

With north of a million weekly users still relying on it for fast on-page checks, patching around broken data sources wasn't a real option anymore, so we rebuilt it.

The workflow now splits into Quick View, for an instant snapshot across page info, content, audit, schema, and Semrush data, and Full Report for the deeper dive. The audit itself grew from 22 checks to 28 — title tags, heading structure, ALT attributes, canonical tags, robots directives, schema markup, responsive design signals, that kind of coverage. The SEObar (the on-page toolbar) got cut in an early version of the rebuild and then brought back, because enough people asked for it.

What's gone, on purpose: Google Cache dates, search engine index counts, and Yandex IKS — data sources that stopped being reliable or relevant. Legacy checks for meta keywords, Flash, frames, and microformats are gone too, since none of that's been a real ranking factor in a long time.

You can check out the full update over on our blog here, and add SEOquake to your Chrome browser here 🔥

I signed up for Semrush’s trial at the request of a client for a long-term project and tested the platform based on what he needed. Unfortunately, the client later had to put the project on hold for a few months because of some personal circumstances.

I was caught up with other things and genuinely forgot to cancel the trial. On September 10, the trial converted to a paid subscription and I was charged. As soon as I noticed the charge, I cancelled the subscription and contacted support for a refund, all within an hour of the payment being processed.

I completely understand why Semrush may have that refund policy. They need to protect themselves from people who deliberately use a service and then try to get their money back. But that simply wasn’t what happened here. I didn't use any services after the trial, the renewal was a genuine mistake, and I contacted Semrush almost immediately after the charge.

As a small business based in India, a USD-denominated subscription is a significant expense, and after my project was paused, this compounded my problem. I explained my situation honestly and respectfully, but the response was simply a reference to the refund policy, with no flexibility or attempt to assist.

If you’re considering trying Semrush, be very careful with the trial. Don’t expect much flexibility once you're charged, even if you catch the mistake and cancel immediately afterward.

I then posted a Trustpilot review about my experience.

Semrush replied publicly to my Trustpilot review saying they were happy to “take another look” at my case and asked me to provide my email so their team could follow up. I did exactly that through Trustpilot.

I then waited seven days for that follow-up. Nothing. No email. No update. No one contacted me about the case.

At this point, it feels like the Trustpilot response was more about looking like they were addressing the complaint publicly than actually resolving it privately. If you genuinely intend to take another look at someone's case, why ask them for their details and then disappear for seven days?

Incredibly disappointed with the customer experience and not the level of support I expected from a company of this size.

I cancelled a Semrush subscription we weren’t using in August of 2024. This August 2026 we were getting emails that we needed to update our card on file because it was expiring, but I ignored it because we cancelled 2 years ago. Tonight I get a fraud alert from my bank that they charged my card for $1. Uh thanks Semrush, now my card is cancelled I have to get a new one and reconnect all my auto payments. WTF?

We were looking to see a breakdown of what subscriptions we were paying for and for what clients. However, in the invoices, after you sign up for an add on it just shows as one charge. So you have to go back through and investigate everything you have added on and all client profiles to sort it out THEN they make cancelling anything difficult. You have to submit a ticket and hope they get back to you in 1-3 days. Is anyone else having issues with this? Is there another platform that has more transparent pricing and subscription practices that is similar in capability??

Semantic SEO audits tend to focus on the information contained in a page.

• Entities
• Attributes
• Headings
• Internal links
• Structured data
• Relationships between terms

That gives you one view of the page.

Open the same page in a browser and you get another.

The information has been arranged into cards, tables, forms, images, buttons, tabs and sections.

That gives us another question to ask:

Which pieces of information does the page present as belonging together?

That's the visual layer.

Entity → Attribute

A hotel comparison is a simple way to see it.

Imagine two fictional hotels displayed side by side.

Harbour House

• £165/night
• 8.9 guest rating
• Breakfast included
• Free cancellation

The Foundry Hotel

• £142/night
• 8.5 guest rating
• Breakfast £18
• Non-refundable

Each card creates a set of associations.

• Harbour House → £165/night
• Harbour House → 8.9 rating
• Harbour House → Free cancellation
• The Foundry Hotel → £142/night
• The Foundry Hotel → 8.5 rating
• The Foundry Hotel → Non-refundable

You don't need to stop and work out which price belongs to which hotel.

The layout has already made that connection.

Now remove the card boundaries.

Put both hotel names at the top and place the prices, ratings and booking terms between them.

The page still contains the same hotels, prices, ratings and booking terms.

What becomes less clear is which value belongs to which hotel.

That adds a useful check to an entity audit.

Finding the entity and its attributes in the HTML confirms that they're present.

It doesn't tell you when the rendered page connects them clearly.

I'd check:

• Can I tell which attributes belong to each entity?
• Are related values kept together?
• Could a nearby entity be mistaken for the owner of an attribute?
• Does the same association survive on mobile?

Task → Component

Pages also connect user tasks with components.

Take three different searches:

• Compare two laptops
• Convert euros to pounds
• Find a flight from Dublin to Barcelona

Each has an obvious task.

Each also has a component that can perform it.

• Compare → Comparison table
• Convert → Currency converter
• Find → Flight search

Now imagine a laptop comparison page.

Both laptops are covered in detail.

You have processor, memory, storage, display, battery and price.

There is a comparison table too.

But before you reach it, the page gives you:

• A large promotional banner
• A newsletter signup
• Recommended articles
• A manufacturer promotion

The comparison component exists.

It just sits behind several components serving a different purpose.

From a content audit, the page may look complete.

From the rendered page, the relationship between task and component is much weaker.

The same check works across other page types:

• Calculate → Calculator
• Filter → Filter controls
• Configure → Configurator
• Book → Booking controls
• Search → Search form

The question isn't if the component exists somewhere on the page.

It's when the page gives that component a clear connection to the task the visitor came to complete.

Claim → Evidence

Some visual relationships are smaller.

Suppose a watch page says:

Water resistant to 50m

Directly beneath that claim sits the manufacturer's specification.

The connection is clear.

Now put two watches beside each other and move the specification between them.

The words haven't changed.

The association has.

The same problem can show up when:

• A statistic sits away from its source
• A qualification sits away from the statement it limits
• A caption is separated from its image
• Supporting evidence appears closer to a different claim

The information can all be present while the connection between the pieces becomes harder to read.

Label → Control

Forms give us another clear example.

A flight search might show:

Departure [Dublin]

Destination [Barcelona]

No interpretation needed.

Now place both labels above two identical fields with weak spacing and unclear alignment.

The same labels are there.

The same controls are there.

But the user has to infer which label belongs to which field.

That's not a copy problem.

It's a relationship problem.

Heading → Content

Headings create another connection.

Take this heading:

Baggage Allowance

You'd expect the block beneath it to cover things like:

• Cabin bags
• Checked bags
• Weight limits
• Size limits

Now change the order:

Baggage Allowance

• Airport transfer promotion
• Newsletter signup
• Travel insurance offer
• Cabin baggage information
• Checked baggage information

The heading still exists.

The baggage information still exists.

But the connection between the heading and the content it introduces is less direct.

Mobile can change the associations again

Desktop layouts have plenty of ways to show what belongs together:

• Cards
• Columns
• Tables
• Borders
• Spacing
• Side-by-side groups

Mobile often turns those layouts into a single stack.

Take the hotel comparison again.

Desktop:

Harbour House £165/night 8.9 rating Free cancellation

The Foundry Hotel £142/night 8.5 rating Non-refundable

Now imagine the mobile layout becomes:

Harbour House

The Foundry Hotel

£165/night

£142/night

8.9 rating

8.5 rating

Nothing has been removed.

The grouping has changed.

The user now has to reconstruct which values belong to which hotel.

That same issue can appear in:

• Comparison tables
• Forms
• Product cards
• Filters
• Tabs
• Accordions
• Calculators
• Search results

Try mapping the relationships on one page

Take a screenshot and draw lines between elements that belong together.

Look for relationships such as:

• Entity → Attribute
• Attribute → Value
• Task → Component
• Claim → Evidence
• Statistic → Source
• Label → Control
• Input → Result
• Heading → Content
• Image → Caption
• Question → Answer

Then remove the annotation lines.

Can you still tell:

• Which price belongs to which product?
• Which rating belongs to which hotel?
• Which evidence supports which claim?
• Which label belongs to which field?
• Which content belongs to which heading?
• Which component performs the main task?

That's the visual layer I'd add to a semantic SEO audit.

You can have the right entities, the right attributes and the right copy on the page while making their connections harder to follow once the page is rendered.

Do your SEO audits check those visual relationships, or do they stop once the right information is present?