I’ll admit I may have spoken too quickly and/or using a browser cashed SERP page? I have been making sure I continuously use a no history browser …
I am currently going through Google Search Console to remove links leading to 404.
Am I going about this properly? Of, course it all depends what I am shooting for, eh?
Clean up a bit would be my answer top that.
@darylpittman
Without All in One SEO Pack redirecting images to the post parent, does https://laserimagenc.com/kelly_clark_v2/ still 404?
Thanks for looking into this, Michael. In the end I think I am talking myself into circles … 🙂
Truth be told, I have no problem with https://laserimagenc.com/kelly_clark_v2/, which is an unattached image, resulting in a 404. What I wish, at least what I think I wish, is for URLs such as this example to not be in Google SERP results for our website. If every (unattached) image ends up in the SERP results then there is a whole bunch of, I dare say, useless URLs getting in the way of content-based URLs. Of course, image attachment pages can be useful if used for content such as a photographer. But, if images are merely a royalty-free decoration for a blog post then I feel there is no need for it to be indexed separately.
What I prefer is what I think comes about when using the Direct to Parent Post URL such as: https://laserimagenc.com/our-team/kelly_clark_v2/. If that URL is used the visitor, as you know, is redirected to the “our-team” page/post.
I have gone through Google Remove URL, recently, and cleaned over 300 URLs “short-version” (unattached image) URLs that have accumulated over the years …
Unattached vs. attached image is where this particular adventure began for me. Choosing an image from the Media Library as opposed to bringing in a image through the Post/Page build UI lends two different results. One way will give the “preferred” redirect URL, if using a plugin, the other will result in a unattached URL which for the most part is an lack-luster no-information image attachment page.
It’s these self discoveries which WordPress is built upon! :))))))
As Doug Foster and I have said in the past, … there are a lot of nerd knobs!
I have also discovered if a post/page is in Draft an attachment id query string is generated to the sitemap even if the image is attached. ie. https://laserimagenc.com/?attachment_id=0000. So, now I am attempting to come up with a system which allows me to draw up Drafts without having image attachment URLs for legitimately attached images submitted to the sitemap. Suggestions?
Or, something … :/
Thank you,
Daryl Pittman
I’ve opened Github issues for both of these at https://github.com/semperfiwebdesign/all-in-one-seo-pack/issues/1834 and https://github.com/semperfiwebdesign/all-in-one-seo-pack/issues/1835
Let me know if I’ve missed anything, as this is a pretty long post. Feel free to make a Github account to participate if you like.
Well, that escalated quickly!
When reading the Github submissions, the question is what are the desired results? I am not a developer and not certain of how solutions come about in Github … The “problem” is described but a desired solution is not included. The solution can be implied from context within the stated problem but, as in #1834, the answer could be as easy as “Don’t have unattached images.” In this case this solution wouldn’t need any extra coding.
Participate!? If by that you mean concoct rambling posts … I’m all in! 🙂
Thanks for the responsiveness, Michael!
After further investigation, the attachment id query string mentioned above relates directly to the Draft post as opposed to the image as I claimed.
I am looking into the create post dashboard UI in WordPress to find a of “hiding” Drafts, updating sitemap in AISEO then checking to see if the Draft has been removed from the sitemap.
In the end, eventually, the Draft will become a bonafide post. But, by then Google has picked up the query string …
@darylpittman
The best thing you can do is to update the issues with a clear and concise description of the problem, along with simple steps to reproduce, so that developers don’t have to parse through both an issue and long forum thread.
