• Skip to main content
  • Skip to forum navigation

StudioPress

  • Shop for Themes
  • My StudioPress

Forum navigation

  • Home
  • General Genesis Discussions
  • StudioPress Themes
  • Genesis Blocks
    • Genesis Blocks
    • Genesis Custom Blocks
  • Retired Themes
  • FAQs
  • Forum Rules
  • Internationalization and Translations
  • Forum Bugs and Suggestions
  • Forum Log In

Are You Using The WordPress Block Editor?

Genesis now offers plugins that help you build better sites faster with the WordPress block editor (Gutenberg). Try the feature-rich free versions of each plugin for yourself!

Genesis Blocks Genesis Custom Blocks

Web site shows old date (caching ?)

Welcome!

These forums are for general discussion on WordPress and Genesis. Official support for StudioPress themes is offered exclusively at My StudioPress. Responses in this forum are not guaranteed. Please note that this forum will require a new username, separate from the one used for My.StudioPress.

Log In
Register Lost Password

Community Forums › Forums › Archived Forums › General Discussion › Web site shows old date (caching ?)

This topic is: not resolved
  • This topic has 8 replies, 3 voices, and was last updated 10 years, 3 months ago by Russel.
Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • December 25, 2012 at 8:49 pm #7431
    PsychSearch
    Member

    I am still new to WP.  This situation is sort of bizzare, and I never saw anything like it.
    On my home page  (PsychSearch. net,  using Genesis Corporate Child Theme) I have a date field. And today (Dec. 25) it started to show it as December 23 and on some pages Dec. 19.
    It looks like I am looking at cached content rather then the real one.  It corrected itself on my computer when I logged in and edited something in WP.  However, on the other computer is still shows old date.  What could cause this? How do I fix it?
    Thank you.
    AR

    December 26, 2012 at 12:11 am #7439
    Bill Murray
    Member

    It looks like you are using Super Cache, and Super Cache might not be caching for logged in users.  That might be why logging in appeared to correct the problem.  When I visited your home page, I was served cached content, but if the cache for an older post was created on 12/19 and your cache life is that long (5 or 6 days), that could cause a user to see a cached page with a bad date.  Even with a short cache life, visitors right around a date change might see a wrong date.

    To fix it, you have to investigate your cache life and the control you have in SC over what gets cached.  Caches are very powerful, but if you have a site with light traffic and long cache life on infrequently visited pages, you'll see issues like this.  You can shorten your cache life or remove things like the date that you might not be able to tell SC not to cache.  Most of your visitors probably know the date, so dropping the date is the easiest solution and doesn't take information away from your visitors.


    Web: https://wpperform.com or Twitter: @wpperform

    We do managed WordPress hosting.

    December 26, 2012 at 8:00 am #7456
    PsychSearch
    Member

    Thank you for your reply.  I will need to read more about it now.
    Did not know it can be kept for so long...  Thanks Bill.

    December 26, 2012 at 9:01 am #7459
    Bill Murray
    Member

    Just to clarify - 6 days is too long for cache life, and that is effectively what you are seeing, but to find the source of your problem you have to dig deeper.

    Cache life in Super Cache is effectively called garbage collection, so you can check your setting for that, but I suspect that it is probably not unreasonably high unless you set it that way inadvertently.  You can also double check to see if WP Cron is running successfully, because if it can't, Super Cache can't do garbage collection.  Also check your setting for Coarse File Locking and do tests with it on and off as a non-logged user (you can use another browser if you are logged in using your favorite browser).  It may be that Super Cache's cache life is reasonably short but it can't delete the old cache file, so users are being served up an old cache file.

    If you have a short cache life and you are still seeing cached pages served up from 6 days ago, it's probably a problem with deleting those cache files, so you can focus your efforts there.

    You can see the problem on this page: http://www.psychsearch.net/fraud/ which shows a date of 12/19 on 12/26.


    Web: https://wpperform.com or Twitter: @wpperform

    We do managed WordPress hosting.

    December 26, 2012 at 11:35 pm #7650
    Russel
    Member

    I have a similar issue.

    On the 6th of December, I contacted the webmaster to remove my name from the webpage and url. He did so and has modified the webpage to exclude my name and has changed the url.

    However the old url still appears on Google when my name is typed. When accessed, it still contains some old information that was removed. Upon signing in to the website however, the webpage automatically "corrects" itself.

    Furthermore, Google has also re-cached the old webpage on the 17th of December which got me confused as shouldn't the old link/page be dead now? How long till the old url/page stop being accessible?

    Will this be resolved if I managed to convince the webmaster to delete the webpage altogether?

    Cheers and Best Regards.

    December 27, 2012 at 12:48 am #7661
    Bill Murray
    Member

    Your issue isn't really related to Super Cache.

    Will your problem be resolved by deleting the webpage?  In a word, no.  Deleting the page will most likely be unhelpful.  You need to tell the webmaster to do these things:

    1) mark the old URL as noindex, noarchive (those are SEO terms, so he'll need to know how to do this)

    2) only after completing step #1, sign in to Google Webmaster Tools and make a URL removal request

    3) after the URL has been removed from every search index you care about, only then can the webpage be deleted or 301 redirected elsewhere

    The steps can't be completed by you, only by the owner of the website hosting the content you want to remove.  The URL removal request can take at least 24 hours to be approved, and additional time to be implemented across all of Google's severs.  That covers Google.  Step 2 needs to be repeated for Bing (which also serves Yahoo's search index).  Those are the primary US search engines, but there are other global search engines (Ahrefs, Yandex, Baidu, etc).  Then there's the Wayback Machine.  If you want the content completely removed, Step 2 would need to be completed for every search engine that has already indexed the offending content.  Google and Bing are friendly in that they have webmaster tools and respect robots directives; not all search engines may make it that easy.  As you are probably beginning to figure out, once content is indexed by a search engine, it is difficult to completely erase from the internet.

    Once the webmaster completes step 1, you can visit the old URL in your browser and see if those tags are in the content of the HTML content of the page.  Good luck.


    Web: https://wpperform.com or Twitter: @wpperform

    We do managed WordPress hosting.

    December 27, 2012 at 12:58 am #7662
    Russel
    Member

    Thanks for the swift reply, Bill. I appreciate it.

    I'm only interested in getting the content off Google in the meantime. There is however one thing I don't understand - Won't deleting the webpage stops the old url from functioning anymore though? Won't it then display the error 404 page and I can just submit the page to Google url removal from there?

    Cheers and Best Regards.

    Thanks for the reply.

    December 27, 2012 at 9:06 am #7673
    Bill Murray
    Member

    First, you have to use Google Webmaster Tools to accomplish the removal, and to do that, you have to establish yourself as the owner of the site.  Based on your description, it didn't sound like you were the owner, just someone who was discussed in content on a site owned by someone else.  Therefore, the site owner has to to request the removal, not you.

    Second, you're correct that you could ask the site owner to delete the URL, which would return a 404.  However, based on your description, that's not the best approach.  According to Google's URL removal requirements, a 404 is one of the requirements to remove a URL, but removing the URL won't have an impact on the cached pages in Google's index.  That seems odd, I know, but the requirements specify steps for removing cached pages, and a 404 isn't one of the accepted steps.  To do that, you need to use the noarchive tag, and to use that, the page has to exist at least long enough for Google to crawl the page and grab the updated noarchive tag.  Depending on how frequently Google crawls that site and whether the site has an XML sitemap, that process could be quick or take a long time.

    And lastly, while removing the URL might seem like what you want, it's often better to 301 redirect the offending URL somewhere else.  That way, for other search robots that respect robots meta tags, the offending URL get's cleaned in search indexes where you don't want to devote as much effort to URL removal.  Most search engines don't remove URL's that 404, because a 404 response can be a temporary error due to a configuration change.

    Hope that helps.

     


    Web: https://wpperform.com or Twitter: @wpperform

    We do managed WordPress hosting.

    December 27, 2012 at 4:58 pm #7774
    Russel
    Member

    Thanks for clarifying, Bob. I appreciate it. =)

    Cheers and Best Regards.

  • Author
    Posts
Viewing 9 posts - 1 through 9 (of 9 total)
  • The forum ‘General Discussion’ is closed to new topics and replies.

CTA

Ready to get started? Create a site or shop for themes.

Create a site with WP EngineShop for Themes

Footer

StudioPress

© 2023 WPEngine, Inc.

Products
  • Create a Site with WP Engine
  • Shop for Themes
  • Theme Features
  • Get Started
  • Showcase
Company
  • Brand Assets
  • Terms of Service
  • Accptable Usse Policy
  • Privacy Policy
  • Refund Policy
  • Contact Us
Community
  • Find Developers
  • Forums
  • Facebook Group
  • #GenesisWP
  • Showcase
Resources
  • StudioPress Blog
  • Help & Documentation
  • FAQs
  • Code Snippets
  • Affiliates
Connect
  • StudioPress Live
  • StudioPress FM
  • Facebook
  • Twitter
  • Dribbble