A WordPress sticky post is not a promise that every homepage card grid will put that article first. The saved sticky setting and the listing that displays the post are separate controls. Check both before changing the publication date or installing another plugin.
This matters when a business announcement should remain visible while newer articles appear. A post can be pinned correctly in the blog index yet stay in date order in a separate homepage section. That difference can be intentional, rather than a failed save or a cache fault.
Check which page is supposed to keep the post at the top
Open Settings > Reading and inspect Your homepage displays. WordPress can show the latest posts on the front page, or use a static homepage with a separate Posts page. The Reading settings reference explains that distinction.
Record the current selections; do not change the homepage just to make an announcement appear. If Home is a static page and Blog is the Posts page, inspect both public URLs. A grid embedded on Home may have its own selection and order.
The WordPress sticky-post reference describes pinning for the front page of posts. The native feature concerns ordinary blog posts, not a universal priority setting for pages, products or every custom content type. It is also unrelated to a sticky header that stays visible while you scroll.
Confirm the post’s sticky setting was actually saved
Use Posts > All Posts to open the exact article. Check its title, permalink and publication status. A draft or scheduled announcement is a different problem from a published post appearing in the wrong place.
In the classic publishing panel, open Visibility > Edit and inspect Stick this post to the front page. If an authorized publishing change is needed, select it, confirm with OK and update that post. Reopen the editor to verify the saved choice. The official classic-editor steps describe this control. Other editor versions place the sticky option in their post settings.
Do not repeatedly save or republish if the choice disappears, an error appears, or the account cannot make the change. Preserve the current state and check the failed save or account permissions. Our Editor versus Administrator guide explains why a role label alone is not proof of a particular site’s permissions.
Inspect the listing’s query, not just the card design
A listing query decides which posts are eligible and how they are arranged. The card template decides how each result looks. Editing the card’s title, image or spacing will not necessarily change which article appears first.
| Where the post appears | What to inspect | Do not assume |
|---|---|---|
| The site’s posts index | The saved sticky flag and the theme or archive template serving that URL | A separate homepage section uses the same query |
| A WordPress Query Loop block | The parent Query Loop’s source, sticky behavior, filters and order | Changing the nested Post Template changes selection |
| An Elementor Loop Grid | The widget’s Query controls, including Ignore Sticky Posts where available | The WordPress block’s controls apply to this widget |
| Manually chosen homepage cards | The selected content or links in the owning page or template | A post flag automatically replaces those choices |
For a WordPress Query Loop block
Open the owning page or template and use List View to select the parent Query Loop, rather than a title, image or Post Template inside it. Inspect the query settings before saving anything. The current block reference covers source, order, sticky handling and filters.
In a template, a Default query can inherit its context. Custom queries expose their own criteria; the available controls vary with the placement and installed version. Do not switch to Custom merely to reveal a control without first preserving the intended archive behavior.
Read the sticky option carefully. Include allows sticky posts in the results; Exclude removes them; Ignore allows eligible posts without treating the sticky flag as priority; Only or Show only restricts the listing to sticky posts. An allowed result is not the same thing as a guaranteed first card in every configuration. The WordPress.com Query Loop guide makes the Ignore distinction explicit.
Also check category or tag filters, manual exclusions, sorting and offsets. A listing can omit an announcement because of its selection rules. Record those rules before changing them; removing a filter can expose content that never belonged in that section.
For an Elementor Loop Grid
Select the Loop Grid widget that owns the results, then inspect its Query section. Check the source, Include or Exclude criteria, Order By and Order. Elementor’s Loop Grid reference also documents Ignore Sticky Posts: when enabled, the query does not use the sticky flag when arranging the loop.
That is a useful check, not a reason to toggle every query option. A manually selected collection or a category-specific grid has its own purpose. Preserve its current settings and agree which announcement belongs there before an authorized change. If a custom Query ID or developer filter controls the results, stop at that ownership boundary rather than pasting unrelated code into the theme.
A practical example: one announcement, two listings
Imagine a business publishes a service-hours announcement in May and three news articles in June. It wants the announcement first on Blog, while Home shows a manually selected group of customer stories. This is a hypothetical example, not a claim about a tested client site.
First inspect the announcement’s saved sticky choice and the actual Blog listing. Then inspect Home’s selected cards. If Blog places the announcement first but Home still shows the customer stories, those two results can both match the intended setup. Pinning the announcement does not mean the homepage selection must be replaced.
If the business wants the announcement on Home too, agree whether it belongs in that collection or in a separate announcement area. Make that change in the component that owns Home. Do not change the May publication date to June or duplicate the article to force it into a feed. Those actions alter content history while leaving the listing’s real rules unexplained.
Verify the public result without losing the original setup
Before an approved repair, retain the post ID, sticky choice, listing URL, query settings and an exact recovery copy of any page or template being changed. Change one owner at a time on staging when the listing is shared or commercially important.
- Check the first results on the intended URL, then follow pagination or Load More to inspect the rest of the listing.
- Confirm category and tag filters still show the intended content, with working card links and images.
- Compare desktop and mobile visitor views, not only the editor canvas.
- Verify that the article’s original URL, publication date and other homepage sections remain unchanged.
If the saved query is correct but visitors receive an older version of the listing, follow the separate WordPress changes not showing diagnosis. Refresh the relevant caches only after identifying that delivery problem. A full purge cannot correct an intentional Ignore setting or a manually selected card.
Stop and restore the approved previous settings if unrelated posts disappear, a shared archive changes unexpectedly, or pagination fails. Custom queries, shared templates and recurring editor-versus-public differences may need WordPress development help. Send the public listing URL and the expected result, not login details in a general enquiry.