A practical on-page check for one published article

If you want to review one live article without disappearing into a full site audit, start with evidence, not edits. A practical on-page check for one published article is a bounded review of one URL as it exists now. We use it when a page is already live, has a clear purpose, and we want to know whether obvious on-page issues, indexing problems or page experience weaknesses are getting in the way.

What it cannot do is prove a ranking cause on its own. Search performance is affected by the query, competing pages, internal linking, site reputation, indexing decisions and changes outside your control. So this is not a magic checklist. It is a disciplined way to inspect one article, confirm what is actually published, and decide what is worth fixing first.

What this check is for

This check is useful when one article matters enough to inspect individually. Typical cases include:

• a new article that is not appearing as expected
• an older article that has lost clicks or impressions
• a page that gets traffic but not the right kind of visits
• a page rewritten by several editors over time
• a page you may promote or link to more heavily

It differs from a general SEO basics guide because the unit of review is one published article, not the whole site and not SEO theory in the abstract. We are not trying to teach every ranking factor. We are checking whether this page says what it is meant to say, whether search systems can access the right version, and whether readers can use it without friction.

It also has limits. A single-page check can show that a title is vague, a canonical points elsewhere, or the intro hides the main topic. It cannot prove that changing one heading will improve rankings. Google’s own guidance is clear that useful, accessible content and descriptive links help discovery, but rankings are not guaranteed Google SEO Starter Guide.

That is why we treat this as diagnosis and prioritisation, not prophecy.

Start with evidence before changing anything

Before editing copy, confirm that you are reviewing the right URL and the version Google is most likely to treat as primary.

Start in the browser with the live page open. Check these basic facts:

• the exact URL in the address bar
• whether it resolves with or without a trailing slash
• whether it switches between http and https
• whether it forces one preferred host, such as www or non-www
• whether a print view, tag page or campaign parameter creates alternate versions

Then inspect the canonical. You can view page source and search for rel="canonical". The canonical should usually point to the article’s own preferred URL, not to a category page or an older duplicate. If the canonical points elsewhere, that changes the whole exercise because Google may choose not to index this URL as the main version.

Next, check indexability in the page itself:

• look for a meta robots tag such as noindex
• check whether the page is blocked by a header directive
• see whether the page is linked from somewhere reasonable on the site
• confirm the article is not hidden behind a form, script failure or unusual navigation path

After that, move to Google Search Console. Use URL Inspection on the exact live URL. This tells you whether the URL is on Google, whether it is indexable, what canonical Google selected, and when it was last crawled. If the page is excluded, do not guess. Read the stated reason and investigate that reason directly. Google’s Page indexing guidance is explicit that excluded URLs need interpretation, and not every excluded URL should be indexed Google Page indexing report.

For one article, the key Search Console checks are:

1. URL Inspection status

Is the URL indexed? If not, why not?

1. User-declared canonical versus Google-selected canonical

If they differ, your page may not be the version Google prefers.

1. Last crawl and crawl availability

This does not prove quality, but it tells you whether Googlebot has recently revisited the page.

1. Performance data for the page

Review clicks, impressions, average position and queries for a sensible date range. Compare before and after any known edit if relevant.

Be careful with interpretation. An impression is not a click. A click is not a conversion. A crawler visit is not approval. The same caution applies to AI-facing crawlers. Googlebot is for search crawling. OAI-SearchBot and GPTBot have different purposes, and search access and model-training controls are separate choices in OpenAI’s documentation OpenAI crawler documentation. Google’s AI search features also use existing search fundamentals, and Google does not require a special AI text file or special AI schema for those features Google AI features.

If you need a broader measurement frame before buying tools, our guide on checking your site for free before buying SEO tools is the better next step than stretching this article into a full basics hub.

Check the parts a reader and Googlebot both rely on

Once you know the page is the right URL and can be indexed, review the on-page elements in the order both readers and crawlers encounter them.

Title tag

The title tag should identify the article precisely, not merely gesture at the topic. For one article, ask:

• does the title match the actual subject of the page?
• is it specific enough to distinguish this article from similar pages?
• does it front-load the main topic naturally?
• would a person who clicked it feel they landed on the right page?

A weak title often sounds generic or promises something broader than the page delivers. We have covered this specific issue in our check on whether the page title matches what the page actually says.

Headings

Review the heading structure on the live page, not only in the CMS editor. A clean structure helps readers scan and helps clarify the page’s subject. You are looking for:

• one clear H1 that matches the article’s purpose
• H2s and H3s that divide the topic logically
• no skipped logic where subheadings appear without a parent section
• headings that describe content, not vague labels like “More” or “Overview”

Do not obsess over heading counts. The practical question is whether someone arriving cold can understand the page outline in seconds.

Introduction

The opening paragraph matters because it sets user expectations and signals relevance early. For one published article, the intro should do three things:

• identify the topic quickly
• explain what the page will help the reader do
• avoid a long scene-setting preamble before the useful part begins

If the first paragraph could sit on almost any article, it is probably too generic. If it hides the point until paragraph four, the page is making readers work too hard.

Body copy

Read the article as if you know nothing about the subject but do care about the problem. Check for:

• a clear answer to the implied question
• evidence or source links where factual claims need support
• unnecessary repetition
• drift into adjacent topics that deserve their own page
• missing definitions for terms a beginner may not know
• stale references to dates, screenshots or interfaces that have changed

This is also where we look for search-intent mismatch. If the page claims to be a practical check, but most of the body is opinion, history or tool promotion, it is not meeting its own promise.

One useful test is to write the page’s core purpose in one sentence. If you cannot do that easily, the article may be trying to serve too many jobs at once.

Internal links

For one article, internal links should help the reader continue, not simply scatter authority around. Review:

• whether the article links to the most relevant supporting guide
• whether anchor text describes the destination clearly
• whether the links appear where the reader would naturally want them
• whether there are obvious missing links to definitions, examples or next-step checks

Descriptive anchors are part of good practice for both usability and discovery Google SEO Starter Guide. For example, if the article raises a performance drop investigation, it should naturally point readers towards how to investigate a change in search performance, rather than using a vague “read more”.

External references

If the article makes factual claims about indexing, AI features or accessibility, check that the references are current and primary where possible. A practical article should not lean on industry folklore if the platform owner has published direct guidance.

Images and image text

For a single article, image review is usually simple:

• does each image add information or merely decorate?
• is the file name sensible if you control it?
• does alt text describe the image appropriately where needed?
• does the image create layout or loading problems?
• are screenshots still accurate?

Alt text is not a place to stuff phrases. It should help when the image content matters. If an image is purely decorative, empty alt may be the right implementation.

Anchor wording inside the article

Look specifically at linked words in the body. “Click here” and “this article” waste context. Better anchors tell the reader what they will get. That matters for accessibility and for comprehension, and it is a more useful check than counting exact-match keywords.

Look for page experience issues that distort the result

A page can be well written and still underperform because the experience of using it is poor. That does not prove a ranking cause, but it can weaken outcomes for both readers and search systems.

Start with loading and stability. Open the page on a normal mobile connection if you can. Watch for:

• large images loading late
• text shifting as banners or fonts appear
• cookie notices obscuring the page
• newsletter pop-ups appearing before any content is read
• sticky elements taking too much screen space

Core Web Vitals are the standard framework for loading, responsiveness and visual stability, but the score is not a guarantee of rankings or business results Core Web Vitals. For a one-article check, we are not trying to perfect lab scores. We are looking for obvious friction that changes what users can actually do.

Then assess navigation and readability:

• can a reader tell where they are on the site?
• is the article title prominent and unambiguous?
• are paragraphs short enough to scan?
• are fonts, contrast and spacing comfortable?
• do buttons and links look like controls?
• does the page remain usable without hunting through clutter?

The W3C’s accessibility design tips are a useful baseline here, especially for contrast, understandable navigation and clear controls W3C accessibility design tips.

Also check mobile specifics. Many article pages look acceptable on desktop and awkward on phones. Watch for sidebars jumping above the content, related-post blocks interrupting the article too early, or tables overflowing the screen.

Finally, note any intrusive elements added by plugins or monetisation systems. If a page repeatedly interrupts reading, your content assessment becomes less reliable because the user is not experiencing the article in the clean form you think you published.

Decide what to fix now, what to test later and what to leave

The value of a practical on-page check is in the decisions at the end. We want a short action list, not a pile of observations.

We usually sort findings into three groups.

Fix now

These are clear defects or mismatches that do not need a long debate. Examples include:

• wrong canonical
• accidental noindex
• title tag that describes a different topic
• broken internal links
• vague anchors that can be improved in context
• missing source links for factual claims
• intrusive pop-up blocking the opening content
• image or script causing obvious layout shift

These are worth changing because the problem is visible and the remedy is straightforward.

Test later

These are plausible improvements with uncertainty attached. Examples include:

• rewriting the intro to answer faster
• changing heading order for clarity
• shortening a long article section
• adding one internal link from a stronger related page
• replacing an image that appears to slow the page

For these, note what you changed and when. Then review Search Console data after enough time has passed for fresh crawling and a reasonable comparison window. If you need a more structured framework for that, use our guide to investigating a change in search performance.

Leave for now

Some findings are real but not urgent. Examples include:

• minor style inconsistencies
• a heading that is not elegant but is clear enough
• a small image-alt improvement on a low-value decorative asset
• speculative keyword tweaks unsupported by user evidence

Leaving something alone is often the right decision. Not every imperfection is worth editorial churn.

A simple one-page summary can be enough:

• URL reviewed
• date checked
• current indexing status
• main issue found
• immediate fixes
• later tests
• unresolved uncertainty

That keeps the exercise practical. It also stops one article review turning into a vague promise to “do SEO”.

Where broader service work is needed, that sits with Suffolk Web, which shares ownership with The SEO Blog under Fleeta Limited. But this publication’s job is to help you assess evidence first, so you can tell the difference between a page problem, a measurement gap and a wider site issue.

If your next step is not another single-page check but a broader foundation review, go to our free pre-tool site check rather than expecting one article inspection to answer every SEO question. That is the right boundary for this process. A practical on-page check for one published article should leave you with a clearer page, a shorter fix list and fewer guesses.