A sticky post is not a universal promise to appear first in every WordPress grid. The page's actual query, sticky-post handling, filters, and template context determine the result. Start by identifying which Query Loop or theme query renders the unexpected list.
Identify the List Before Changing Post Dates
Record the page URL, whether it is the assigned posts page or a regular page, and which template renders it. A category archive, a hand-built landing page, and the main blog can use different queries. Changing a publication date to force order can create a misleading date without fixing the query.
List the expected first five post IDs, then record the actual IDs and any repeats. Include each item's publication date and sticky status. This makes it possible to distinguish a true duplicate from two similarly titled posts.
Inspect Query Settings in Context
Review the WordPress Query Loop documentation for the settings available in your editor. Check the content type, ordering, taxonomy filters, offset, and sticky handling where those controls are exposed. Also determine whether the block inherits a template query or uses a custom one. Do not assume the controls in a screenshot from another version match yours.
The theme documentation for sticky posts describes sticky behavior and query options. If a developer has supplied a custom query, ask them to verify its treatment of sticky posts explicitly rather than assuming the default home-page behavior carries over.
Inventory: Record expected and actual post IDs. Two loops: Compare featured and regular results. Dates: Keep genuine publication dates. Logged out: Retest ordering after cache refresh. Explanatory checklist, not a customer test result.
Check the Two-Loop Duplicate Pattern
A common layout has a featured section above the ordinary article grid. If the first loop selects a sticky post and the second still includes the same post, it may appear twice even though each loop works as configured.
On staging, temporarily isolate the two loops. Record the IDs returned by each. Then define the intended rule: should featured items be excluded from the ordinary list, or is repeated placement intentional? Implement that rule in the actual query owner, not by hiding a duplicate card with CSS. Hidden cards can still disrupt layout, navigation, and accessibility.
| Symptom |
Test |
| Featured item repeats in the grid |
Compare IDs across both loops |
| Order changes on category pages |
Compare archive and home query context |
| Items skip on page two |
Inspect offsets and pagination together |
| Logged-out order stays old |
Compare fresh rendered output and page cache |
Verify Pagination, Not Just the First Screen
Test at least the first two pages of results and the final partial page where practical. Check for missing items, repeated IDs, and a pagination control that points to the correct list. A repair that fixes the first page but skips posts later is incomplete.
If the editor preview differs from the frontend, compare the saved template and any query-modifying plugin. Disable or change one candidate on staging at a time. Keep the original settings so you can restore them if the test does not explain the result.
After the fix, clear the affected page cache and repeat the logged-out test. Keep the publication dates accurate. For a post missing entirely, start with published posts not showing on the blog. For confusing shared layout edits, see synced patterns and page changes. Get a focused fix when a theme or plugin overrides the query.
References reviewed October 6, 2026. Examples are explanatory, not customer test results.