How to Increase Google Discover Traffic: A Practical Guide

How Google Discover traffic actually behaves

I remember a night-shift support ticket about a customer’s post that had suddenly started appearing in Google Discover. The traffic graph looked encouraging until we checked the mobile sessions. Visitors were leaving before the page finished opening. A large hero image arrived late, and a fixed newsletter popup covered the text.

That is the awkward part of Discover. People are not searching for a phrase; Google is placing content in a personalised feed based on their interests. Google Discover optimisation is not a matter of adding a few tags and waiting. The page has to reach the right person at the right moment, then deliver what the card promised.

There is no guarantee. The same post can receive thousands of impressions one week and almost none the next. You can still build a repeatable process around access, presentation, usefulness, trust and user response.

Search and Discover are different products

Google Search and Discover do not send visitors for the same reason. In Search, someone enters a query and Google tries to rank the most appropriate answers. Discover builds a personal feed from signals such as previous interactions, followed topics, location, language and how current a piece of content is.

That difference changes how I plan content. Ask not only, “Would someone type this into Google?” Ask this too: “If this appeared in someone’s feed without warning, would the topic earn a tap?”

• Search content: Answers a defined question or fulfils a specific need.
• Discover content: Surfaces a topic the user has not searched for yet but may care about.
• Content for both channels: Solves a clear problem while using a title and image that make sense in a feed.

You do not submit an application to appear in Discover. A page that can be indexed by Google may also be considered for Discover. Indexing does not mean impressions will follow. Content policies, quality signals, user interest and changing demand all play a part.

Good content cannot compensate for a broken page

Many Discover projects begin with a headline idea. I start somewhere less exciting: can Google access the page, and does the page describe itself correctly? A well-written post carrying a noindex directive or pointing to the wrong canonical URL has little chance of entering the feed.

Check indexing and the canonical URL

After publishing, use URL Inspection in Google Search Console. Check that the URL is known to Google and indexed. If the same post exists under a parameterised URL, a print version or an old address, verify that the canonical URL points to the real, accessible article.

On a WordPress site, I inspect the source and look for these details:

• There is no noindex value in the robots meta tag.
• rel="canonical" points to the actual article URL.
• The page opens without a login.
• Important content is present without requiring JavaScript to run first.
• The mobile version is not buried under errors, redirects or aggressive advertising.

Even when the WordPress dashboard is unavailable, I can perform a quick first check from the shell:

curl -sL https://example.com/example-post/ | grep -Ei 'canonical|robots|og:image|article:published_time'

This checks whether the returned HTML contains a canonical URL, robots information, a social image and a publication timestamp. Empty output is not proof of a problem because themes and plugins may format these tags differently. It is simply a useful first flashlight.

Mobile experience is part of the traffic opportunity

Most Discover visitors are on phones. If the page opens with a large advert, a late web font and a newsletter popup pushing the article below the fold, the click has been wasted. Core Web Vitals are not a Discover admission ticket by themselves, but a poor real-user experience makes quick exits and weak engagement more likely.

For LCP, do not serve the hero image at a needlessly large size. For CLS, reserve dimensions for images and advertising slots. For INP, reduce heavy JavaScript that runs during the initial load.

I once assumed a slow page was a hosting problem because the cache was working correctly. A reporting plugin was running unnecessary database queries on every visit. Looking at the browser performance trace and query load together showed the real bottleneck. That mistake still shapes how I investigate “the server is slow” tickets.

The distinction between server response time and content quality is also covered in Hosting and SEO: Myths vs Reality About IPs, Location, CDNs and HTTP/2/3. I need both parts of the diagnosis, not a single “the hosting is slow” label.

The image often gets the first look

On a Discover card, the image may catch the eye before the headline does. That does not make the text less valuable; it means the first contact happens differently. A small featured image that works for a social share can look blurry and forgettable in a Discover card.

Start here.

• Prepare the featured image at 1200 pixels wide or more when practical.
• Allow large image previews with max-image-preview:large.
• Make the image directly relevant to the subject. A smiling stock photo unrelated to the article adds very little.
• Keep text overlays restrained. Tiny words on a phone usually create clutter rather than context.
• Compress the file without destroying the detail that makes it useful.
• Confirm that you have the right to use the image.

You can provide the directive in an HTTP header or in the HTML:

<meta name="robots" content="max-image-preview:large">

This tells Google that a large preview may be used. It does not force Google to display the image at that size; the final choice depends on the system and the available space on the device.

A common WordPress mistake is to place an image inside the article but never define a featured image. Fill in the featured image field and confirm that the theme exposes it correctly as og:image. You do not need an identical image on every post. A consistent visual style is more useful when each image still explains its own topic at a glance.

Write a title that earns curiosity without misleading

A Discover headline has a different job from a search-result headline. The reader was not necessarily looking for this subject. The title has to explain what the post offers quickly and answer the quiet question, “Why should I read this?”

Surprising wording can produce short-term clicks. If the article does not deliver the promise, the visitor leaves immediately. I would not describe every disappointing click as a direct ranking penalty, but low satisfaction and weaker trust are bad enough.

“Why Did Your WordPress Site Become Slow Overnight?” presents a clearer problem than “Things You Should Know About WordPress.” The first title gives the reader a likely issue and a sense of timing. The second is too broad to create a useful expectation.

A quick test for a Discover headline

• Can the real subject be understood on the first reading?
• Does the article deliver what the title suggests?
• Are unnecessary capital letters, excessive punctuation or fear-based wording doing the work?
• If the title concerns a current event, does the article explain the date and context?
• Are you repeating the same headline pattern across unrelated cards?

I do not fixate on one character limit. I want the title to remain clear and reasonably short on a mobile card. The practical test is simple: can someone who sees the headline predict what they will read after tapping it?

First-hand usefulness builds trust

Discover is not limited to news sites. How-to posts, reviews, analysis, personal experience and local content can all appear when they match a user’s interests. Whatever the subject, a page filled with general statements needs a real contribution behind it.

“Improve your site speed” is easy to write in a hosting post. Explaining what you measured, which file was delayed and what changed afterwards is much more useful. If you cannot publish customer screenshots, show the command output, configuration example or reasoning that led to the decision.

My own writing checklist is short:

• What real problem did I investigate to prepare this post?
• What can the reader do independently after finishing it?
• Which statements are assumptions, and which are based on measurements or sources?
• If the subject is version-sensitive, have I stated the versions, dates and operating conditions?
• If a procedure is risky, have I included backup, rollback and verification steps?

An author page, publication date, update date and a publisher contact page also help readers judge the source. They are not an entry ticket to Discover, but they matter especially in health, finance, legal and security topics. Hosting articles should name the environment too: Apache and OpenLiteSpeed do not always behave the same way.

Freshness depends on the subject

Discover tends to favour current content, but every post does not need to pretend to be breaking news. For a domain security guide, freshness might mean adding a new attack pattern, browser behaviour or DNS practice accurately. Changing the date without changing the substance is not an update.

When revising an existing post:

• Change information that has actually changed.
• Fit new sections into the flow instead of bolting them on without context.
• Remove commands that no longer work or state the version where they apply.
• Do not move the publication date forward merely to make the post look new.
• Add a short update note at the top when the change needs explanation.

For news-related subjects, state when the event happened, which source supports the claim and how later developments differ from the first report. For evergreen content, accuracy matters more than artificial freshness. A reader who sees the article three months later should still find a dependable answer.

Policies are part of publishing, not an afterthought

Technical optimisation cannot repair a policy problem. Dangerous content, harassment, deceptive practices, manipulative headlines, hate speech and copyright violations can all put visibility at risk. The expectation for trustworthy material is even higher in areas such as news and finance.

Advertising is allowed, but do not make an advert impossible to distinguish from the article. A visitor who expects a news story and instead meets five popups and a full-screen advert has been given a poor experience. Artificially multiplying content, publishing the same article under several URLs and adding keywords without adding meaning are not durable tactics.

The publishing environment needs protection too. Secure Web Hosting Checklist for Small Businesses covers the security side of that work. A compromised WordPress installation can create spam pages that make the best headline strategy irrelevant. Keep administrator accounts protected, plugins maintained and unexpected content under review.

Measure the card, the visit and what happens next

The Discover report in Search Console appears when a site has enough eligible data. It can show impressions, clicks, click-through rate and page-level performance. If the report is absent, that does not automatically indicate a technical fault; Google does not provide Discover data for every site at all times.

When the report is available, do not stop at total traffic. Ask separate questions:

• Which topic groups are receiving impressions?
• Do high-impression, low-click cards have a title or image problem?
• Do high-click pages satisfy the expectation as soon as they open?
• Is traffic concentrated in one post, or distributed across several pieces?
• On which days does Discover traffic rise, and how long after publication do those impressions appear?

Read your GA4 data alongside Search Console. In GA4 Setup Guide: Track Your Website Data Step by Step, I described the installation and basic validation process. Look beyond the number of Discover visitors: see which pages they visit next, how long they stay and whether they move towards a meaningful conversion.

Search Console clicks and GA4 sessions will not necessarily match. Ad blockers, consent choices, redirects and processing differences sit between the two systems. A small gap is normal. A large one is a reason to inspect UTM handling, redirects and the measurement code.

Build clusters instead of publishing noise

You do not need to publish every day just to stay visible in Discover. A better approach is to build groups of related subjects for the same reader. A foundational WordPress security guide can lead naturally to posts about plugin updates, restoring backups and cleaning malicious files.

This structure helps in two ways. Readers move from one page to another because the next page is genuinely useful, and you get a clearer view of the subjects where your site can demonstrate expertise. Make internal links complete the meaning of a sentence rather than using empty phrases such as “click here.”

Support tickets are an excellent source of ideas. If the same question arrives repeatedly, there is a real need behind it. During night shifts I saw “why is my site slow?” turn out to be one plugin, one expensive query or a full disk more often than an abstract hosting mystery. Removing personal details and turning those incidents into practical posts produces better material than generic advice.

Try these angles when planning Discover-friendly topics:

• How a new change affects site owners.
• The actual diagnostic process behind a common failure.
• What a tool cannot do, and where it should be used instead.
• A measured comparison that challenges a common assumption.
• A practical guide responding to a seasonal or industry-specific need.

Do not promise a fixed traffic timeline

There is no reliable waiting period for Discover visibility. Some sites receive impressions soon after publishing; others produce no useful data for a long time. Site history, subject area, content quality, technical accessibility and user interest all influence the result.

Do not declare the approach a failure after the first few posts perform quietly. Do not declare permanent success because one post had a viral week either. Watch several content cycles and compare the relationship between subject, headline, image and user behaviour.

Plan capacity for the possibility of a sudden increase. WordPress PHP workers, database connections, CDN cache state and image delivery can all become limits when the feed sends visitors your way. A site that cannot answer when the traffic arrives makes for an uncomfortable kind of success.

My short pre-publication check

I use this list before publishing a new post. It is not meant to trick an algorithm; it is there to make sure the reader receives a complete page.

1. Does the headline describe the article’s actual promise?
2. Does the opening paragraph get to the point without unnecessary throat-clearing?
3. Is the featured image relevant, large enough and compressed?
4. Is the canonical URL correct, is the HTML accessible, and is large image preview allowed?
5. Do an advert, popup or fixed bar cover text on mobile?
6. Are the author, date, sources or experience context provided where needed?
7. Do internal links lead to genuinely relevant pages?
8. Will I review Search Console and GA4 data after publication?

I do not treat this as a checklist to write once and forget. A theme change, a new cache layer or an image optimisation plugin update can alter the output. One setting may look correct in an admin screen while the source code tells a different story.

Frequently asked questions

Do I need to apply to get a site into Google Discover?

No. Pages that can be indexed by Google and comply with its policies may be considered for Discover. There is no application, but there is also no visibility guarantee. Quality, user interest and technical accessibility are evaluated together.

Why does Discover traffic suddenly drop?

Discover is a personalised, volatile feed. Topic interest, freshness, competition, user behaviour and system changes can all affect traffic. First separate impressions from clicks in Search Console. Then check page access, the headline, the image and whether the content still reflects the subject accurately.

Does a site have to be a news site to appear in Discover?

No. Guides, reviews, analysis and experience-based posts can appear in the feeds of interested users. Non-news content still needs a clear title, a relevant image, genuine usefulness and trustworthy sourcing.

Which WordPress plugin should I install for Discover?

No single plugin creates Discover visibility. Your SEO plugin can help produce correct canonical, robots and social image tags, but the main work is content quality, mobile experience, image preparation and regular measurement.

My own mistake was trusting the dashboard preview instead of checking the HTML that visitors and crawlers received. I still view the source before blaming Google. It takes a minute, and the page usually tells me more than the settings screen.