Body: <p>I'm trying to find the best way to let expired entries display.</p>
  
  <p>My client has jobs that are filled / expire.</p>
  
  <p>A typical job url looks like this:</p>
  
  <p><a href="https://flourish-uk.com/jobs/sous-chef-maidstone-20881" rel="nofollow noreferrer">https://flourish-uk.com/jobs/sous-chef-maidstone-20881</a></p>
  
  <p>In the section settings I've got:</p>
  
  <p>Entry URL format set to:</p>
  
  <p>jobs/{jobTitle|kebab}-{jobCity|kebab}-{jobId|kebab}</p>
  
  <p>And the entry template set to:</p>
  
  <p>jobs/_entry</p>
  
  <p>Everything works great. When a job expires/entry expires it no longer appears, but of course the google index remains and so I'd like the page to still 'exist' rather than redirect to a 404.</p>
  
  <p>I've done a bit of work with the 404 so that the /jobs/ part is recognised in the URL and I change the content, as well as fetch expired job data, such as the jobTitle and integrate it into the content. The problem is, Google still sees a 404 page, and the content of the page is different which will invariably create some negative page rank issues given the number of expired jobs that are accruing.</p>
  
  <p>So rather than a 404, I'd like the expired:</p>
  
  <p>/jobs/sous-chef-maidstone-20881</p>
  
  <p>Entry to go to the _entry template and show the original unexpired layout (albeit with some tweaks to explain the job has expired).</p>
  
  <p>But despite following the details found here:</p>
  
  <p><a href="https://craftcms.stackexchange.com/questions/8226/is-it-possible-to-view-expired-entrys-on-the-front-end/8228#8228">Is it possible to view &#39;Expired&#39; entrys on the front end?</a></p>
  
  <p>The _entry still redirects to the 404 page when an entry is expired.</p>
  
  <p>Is there any way to stop this so I can perform some .status('expired') voodoo on it?</p>
  
  <p>Many thanks.</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-09-08T13:51:33.310Z
Comments.Text: Thanks Jeroen, creative thinking, thank you, it is definitely one way to go about it. However, in the dashboard this would remove the ability to filter expired jobs/entries and over time create pages and pages of entries we don't need to see.
Comments.UserDisplayName: Pathfinder
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-09-08T15:28:15.853Z
Comments.Text: status(null) will give you all entries irregardless of status
Comments.UserDisplayName: Luke Holder
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-09-08T16:18:16.770Z
Comments.Text: Hey Pathfinder, have a look at my answer to the related question! ^^
Comments.UserDisplayName: carlcs
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-09-08T17:18:09.630Z
Comments.Text: [This question/answer](http://craftcms.stackexchange.com/a/8481/45) does a great job of walking through a similar issue. She's tackling _future_ entries, while you're tackling _past_ entries, but other than that the solution is the same.
Comments.UserDisplayName: Lindsey D
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-09-09T09:43:42.347Z
Comments.Text: Thanks for the comments, I'll have another look and see how I get on.
Comments.UserDisplayName: Pathfinder
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-09-09T13:20:15.883Z
Comments.Text: @lindsey-d having fun getting this working, trying a new section as the jobs affects the live site etc. Fetching the segment okay for the slug, but the craft.entries is drawing a blank.
Comments.UserDisplayName: Pathfinder
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-09-09T13:21:14.987Z
Comments.Text: @carlcs as above, I can see now what I was missing in your post. Lindsey's forwarded answer lays out the steps and helped flesh out the issue. Still having fun as described above.
Comments.UserDisplayName: Pathfinder
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-09-09T13:29:30.907Z
Comments.Text: Okay, so I solved the issue of the redirect failing to fetch a record with the slug.
Comments.UserDisplayName: Pathfinder
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-09-09T13:31:24.513Z
Comments.Text: @Pathfinder I would highly recommend to get rid of this `jobs/{jobTitle|kebab}-{jobCity|kebab}-{jobId|kebab}` and use `jobs/{slug}` instead. I didn't notice this when posting yesterday, but you should really use the slug for your urls.
Comments.UserDisplayName: carlcs
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-09-09T13:35:13.143Z
Comments.Text: @Pathfinder This should also make your record fetching more straight forward. To automatically get your slugs look like that kebab party you have right now, I'd make use of the [automatic entry titles](http://buildwithcraft.com/docs/sections-and-entries#dynamic-entry-titles) feature.
Comments.UserDisplayName: carlcs
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-09-09T14:06:03.257Z
Comments.Text: @carlcs funny you should mention that :)
  
  After much head scratching (The slug wasn't fetching any records), I realised that the slug was different from the URI.
  
  The problem I have with slugs for the jobs is two fold - first and foremost - the users can edit it - and they do mess it up (Which is why my randomly picked job entry was failing - they'd messed with the slug!
  
  The auto generated titles are far more reliable and consistent, taking fields they've filled in elsewhere to form the generated title, and thus, the URI.
Comments.UserDisplayName: Pathfinder
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-09-09T14:11:37.133Z
Comments.Text: So I have got this all working now using:
  
    {% set uri = craft.request.getSegment(2) %}
    {% set jobs = craft.entries.section("jobs").uri('jobs/' ~ uri).status('live', 'expired').find() %}
  
  This has the advantage of not having to change the listing <a> record manually in the listing template, instead just using the auto-generated uri which is reliably created. In the answer mentioned by Lindsey it says turn off the entries have unique URL's, which I've ignored - I want the auto-generated URL's :)
Comments.UserDisplayName: Pathfinder
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-09-09T14:13:10.873Z
Comments.Text: @carlcs I think the main thing I didn't understand from your answer was that I had to use routing. That is my bad, but the fields you mentioned are the same as in the section fields, which is why I thought it wasn't working.
  
  My routing is using /jobs/* and all is good.
  
  I'd like to thank you both for the feedback - solved a big issue for me and your time and talent is truly appreciated!
Comments.UserDisplayName: Pathfinder
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-09-09T14:14:20.430Z
Comments.Text: @Pathfinder But as soon as they edit one of these fields, you get a new URI and with that you start fresh in allt hings google, confuse site visitors who bookmarked that job's site. The slugs field is there for a reason! Can't you just train your useres to not mess with the field (or use CPJS to hide it from them)?
Comments.UserDisplayName: carlcs
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-09-09T14:21:40.437Z
Comments.Text: @carlcs That is true, but generally they don't edit these fields once setup - where as they are terrible at getting the slug right.
  
  I have got a catch in the 404 that looks for /jobs/ in the first segment. What I then do is do a 301 redirect to a page that strips out just the jobId number and pulls the job entry in.
  
    {% redirect '/jobs/position-filled?jobId=' ~ craft.request.url|split('-')|last 301 %}
  
  Ideally I'd also use the jobId instead of the uri to pull the job entries, but they aren't always reliable with the jobId either - sometimes using the same number twice!
Comments.UserDisplayName: Pathfinder
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-09-09T14:32:18.653Z
Comments.Text: Ahh nice, didn't even notice you have the ID in your generated URI. :)
Comments.UserDisplayName: carlcs
Tags: <404><seo><expired>
Title: How can I stop expired entries appearing as 404
ThreadText: # How can I stop expired entries appearing as 404
  
  (Asked by: username_0 on 2015-09-08)
  
  I'm trying to find the best way to let expired entries display.
  
  My client has jobs that are filled / expire.
  
  A typical job url looks like this:
  
  <https://flourish-uk.com/jobs/sous-chef-maidstone-20881>
  
  In the section settings I've got:
  
  Entry URL format set to:
  
  jobs/{jobTitle|kebab}-{jobCity|kebab}-{jobId|kebab}
  
  And the entry template set to:
  
  jobs/\_entry
  
  Everything works great. When a job expires/entry expires it no longer appears, but of course the google index remains and so I'd like the page to still 'exist' rather than redirect to a 404.
  
  I've done a bit of work with the 404 so that the /jobs/ part is recognised in the URL and I change the content, as well as fetch expired job data, such as the jobTitle and integrate it into the content. The problem is, Google still sees a 404 page, and the content of the page is different which will invariably create some negative page rank issues given the number of expired jobs that are accruing.
  
  So rather than a 404, I'd like the expired:
  
  /jobs/sous-chef-maidstone-20881
  
  Entry to go to the \_entry template and show the original unexpired layout (albeit with some tweaks to explain the job has expired).
  
  But despite following the details found here:
  
  [Is it possible to view 'Expired' entrys on the front end?](https://craftcms.stackexchange.com/questions/8226/is-it-possible-to-view-expired-entrys-on-the-front-end/8228#8228)
  
  The \_entry still redirects to the 404 page when an entry is expired.
  
  Is there any way to stop this so I can perform some .status('expired') voodoo on it?
  
  Many thanks.
  
  **Tags:** 404, seo, expired
  
  > **Comments:**
  > **username_0**: Thanks Jeroen, creative thinking, thank you, it is definitely one way to go about it. However, in the dashboard this would remove the ability to filter expired jobs/entries and over time create pages and pages of entries we don't need to see.  
  > **username_1**: status(null) will give you all entries irregardless of status  
  > **username_2**: Hey username_0, have a look at my answer to the related question! ^^  
  > **username_3**: [This question/answer](http://craftcms.stackexchange.com/a/8481/45) does a great job of walking through a similar issue. She's tackling _future_ entries, while you're tackling _past_ entries, but other than that the solution is the same.  
  > **username_0**: Thanks for the comments, I'll have another look and see how I get on.  
  > **username_0**: @username_3-d having fun getting this working, trying a new section as the jobs affects the live site etc. Fetching the segment okay for the slug, but the craft.entries is drawing a blank.  
  > **username_0**: @username_2 as above, I can see now what I was missing in your post. username_3's forwarded answer lays out the steps and helped flesh out the issue. Still having fun as described above.  
  > **username_0**: Okay, so I solved the issue of the redirect failing to fetch a record with the slug.  
  > **username_2**: @username_0 I would highly recommend to get rid of this `jobs/{jobTitle|kebab}-{jobCity|kebab}-{jobId|kebab}` and use `jobs/{slug}` instead. I didn't notice this when posting yesterday, but you should really use the slug for your urls.  
  > **username_2**: @username_0 This should also make your record fetching more straight forward. To automatically get your slugs look like that kebab party you have right now, I'd make use of the [automatic entry titles](http://buildwithcraft.com/docs/sections-and-entries#dynamic-entry-titles) feature.  
  > **username_0**: @username_2 funny you should mention that :)  After much head scratching (The slug wasn't fetching any records), I realised that the slug was different from the URI.  The problem I have with slugs for the jobs is two fold - first and foremost - the users can edit it - and they do mess it up (Which is why my randomly picked job entry was failing - they'd messed with the slug!  The auto generated titles are far more reliable and consistent, taking fields they've filled in elsewhere to form the generated title, and thus, the URI.  
  > **username_0**: So I have got this all working now using:    {% set uri = craft.request.getSegment(2) %}   {% set jobs = craft.entries.section("jobs").uri('jobs/' ~ uri).status('live', 'expired').find() %}  This has the advantage of not having to change the listing <a> record manually in the listing template, instead just using the auto-generated uri which is reliably created. In the answer mentioned by username_3 it says turn off the entries have unique URL's, which I've ignored - I want the auto-generated URL's :)  
  > **username_0**: @username_2 I think the main thing I didn't understand from your answer was that I had to use routing. That is my bad, but the fields you mentioned are the same as in the section fields, which is why I thought it wasn't working.  My routing is using /jobs/* and all is good.  I'd like to thank you both for the feedback - solved a big issue for me and your time and talent is truly appreciated!  
  > **username_2**: @username_0 But as soon as they edit one of these fields, you get a new URI and with that you start fresh in allt hings google, confuse site visitors who bookmarked that job's site. The slugs field is there for a reason! Can't you just train your useres to not mess with the field (or use CPJS to hide it from them)?  
  > **username_0**: @username_2 That is true, but generally they don't edit these fields once setup - where as they are terrible at getting the slug right.  I have got a catch in the 404 that looks for /jobs/ in the first segment. What I then do is do a 301 redirect to a page that strips out just the jobId number and pulls the job entry in.    {% redirect '/jobs/position-filled?jobId=' ~ craft.request.url|split('-')|last 301 %}  Ideally I'd also use the jobId instead of the uri to pull the job entries, but they aren't always reliable with the jobId either - sometimes using the same number twice!  
  > **username_2**: Ahh nice, didn't even notice you have the ID in your generated URI. :)  
  
  ---
  
  ## 0 answers
  
  