<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>

CC BY-SA 3.0
2015-09-08T13:51:33.310Z
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.
Pathfinder
CC BY-SA 3.0
2015-09-08T15:28:15.853Z
status(null) will give you all entries irregardless of status
Luke Holder
CC BY-SA 3.0
2015-09-08T16:18:16.770Z
Hey Pathfinder, have a look at my answer to the related question! ^^
carlcs
CC BY-SA 3.0
2015-09-08T17:18:09.630Z
[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.
Lindsey D
CC BY-SA 3.0
2015-09-09T09:43:42.347Z
Thanks for the comments, I'll have another look and see how I get on.
Pathfinder
CC BY-SA 3.0
2015-09-09T13:20:15.883Z
@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.
Pathfinder
CC BY-SA 3.0
2015-09-09T13:21:14.987Z
@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.
Pathfinder
CC BY-SA 3.0
2015-09-09T13:29:30.907Z
Okay, so I solved the issue of the redirect failing to fetch a record with the slug.
Pathfinder
CC BY-SA 3.0
2015-09-09T13:31:24.513Z
@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.
carlcs
CC BY-SA 3.0
2015-09-09T13:35:13.143Z
@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.
carlcs
CC BY-SA 3.0
2015-09-09T14:06:03.257Z
@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.
Pathfinder
CC BY-SA 3.0
2015-09-09T14:11:37.133Z
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 :)
Pathfinder
CC BY-SA 3.0
2015-09-09T14:13:10.873Z
@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!
Pathfinder
CC BY-SA 3.0
2015-09-09T14:14:20.430Z
@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)?
carlcs
CC BY-SA 3.0
2015-09-09T14:21:40.437Z
@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!
Pathfinder
CC BY-SA 3.0
2015-09-09T14:32:18.653Z
Ahh nice, didn't even notice you have the ID in your generated URI. :)
carlcs
<404><seo><expired>
How can I stop expired entries appearing as 404
# 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 Pathfinder, 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**: @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.  
> **username_0**: @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.  
> **username_0**: Okay, so I solved the issue of the redirect failing to fetch a record with the slug.  
> **username_2**: @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.  
> **username_2**: @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.  
> **username_0**: @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.  
> **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 Lindsey it says turn off the entries have unique URL's, which I've ignored - I want the auto-generated URL's :)  
> **username_0**: @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!  
> **username_2**: @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)?  
> **username_0**: @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!  
> **username_2**: Ahh nice, didn't even notice you have the ID in your generated URI. :)  

---

## 0 answers

