Questions created by dsbud
-
301 redirect hops from non-https and www
It's best practice to minimize the amount of 301 redirect hops. Ideally only one redirect hop. It's also best practice to 301 redirect (or at least canonical) your non-https and/or your non-www (or www) to the canonical protocol/subdomain. The simplest (and possibly the most common) way to implement canonical protocol/subdomain redirects is through a load balancer or before your app processes the request. Both of which will just blanket 301 to the canonical domain/protocol regardless if the path exists or not In which case, you could have: Two hops. i.e. hop #1 http://example.com/foo to https://example.com/foo, hop #2 https://example.com/foo to https://example.com/bar 301 to a 404. Let's say https://example.com/dog never existed, but somebody for whatever reason linked to it (maybe a typo). If I request https://www.example.com/dog, the load balancer would 301 to a 404 page. Either scenario above should be fairly rare. However, you can't control how people link to you. Should I care about either above scenario? I could have my app attempt to check if the page exists before forwarding, but that code could be complicated.
Intermediate & Advanced SEO | | dsbud0 -
Potential issue: Page design might look like keyword stuffing to a web crawler
We have an interesting design element we might try on our home page. Here's a mockup: https://codepen.io/dsbudiac/pen/Bwrgjd I'm worried web crawlers will interpret this as keyword stuffing and affect our rankings. It features: Mostly transparent/hidden text Repeating keyword list I could try a couple methods to skirt around crawling concerns: Load keywords through an iframe Make the keywords an image (would significantly increase page load) Inject keywords after page load into a container w/ javascript (prob not effective as crawlers are only getting better at indexing javascript) Load the keywords into an svg element Load the keywords into a canvas element via javascript I have a few questions: Should I be concerned about any potential keyword stuffing / SEO issues with this design? Can you comment on the effectiveness (with proof) of the above strategies? Am I better off just abandoning this type of design?
Intermediate & Advanced SEO | | dsbud0 -
Site structure: Any issues with 404'd parent folders?
Is there any issue with a 404'd parent folder in a URL? There's no links to the parent folder and a parent folder page never existed. For example say I have the following pages w/ content: /famous-dogs/lassie/
Intermediate & Advanced SEO | | dsbud
/famous-dogs/snoopy/
/famous-dogs/scooby-doo/ But I never (and maybe never plan to) created a general **/famous-dogs/ **page. Sitemaps.xml does not link to it, nor does any page on my site. Is there any concerns with doing this? Am I missing out on any sort of value that might pass to a parent folder?0 -
How important is the file extension in the URL for images?
I know that descriptive image file names are important for SEO. But how important is it to include .png, .jpg, .gif (or whatever file extension) in the url path? i.e. https://example.com/images/golden-retriever vs. https://example.com/images/golden-retriever.jpg Furthermore, since you can set the filename in the Content-Disposition response header, is there any need to include the descriptive filename in the URL path? Since I'm pulling most of our images from a database, it'd be much simpler to not care about simulating a filename, and just reference an image id in my templates. Example: 1. Browser requests GET /images/123456
Intermediate & Advanced SEO | | dsbud
2. Server responds with image setting both Content-Disposition, and Link (canonical) headers Content-Disposition: inline; filename="golden-retriever"
Link: <https: 123456="" example.com="" images="">; rel="canonical"</https:>1 -
Domain Transition: Leaving low quality content behind
We're in the initial stages of planning a domain transition / rebrand. We're considering 301'ing our low and high(er) quality content split to two different domains. One for the low quality, one for our high. Best practices normally tell you to not split your content between between multiple domains. However, what if the majority of pages on your site are thin/outdated, and attract low volume/long tail? Does it make sense to bring that low quality/volume content over the new domain, when you know you'll never have the resources (nor would it make sense to) mass improve the quality of these pages? I'm concerned the quality of these pages are affecting our overall domain authority. Some background on our site/business: Current site has 15,000+ pages. 98% of our site is a product directory of professional/enterprise business management software. While a small handful of our product pages have quality original long form content (maybe 50-100), most of the product pages are a combination of: thin, outdated, overly sales-y content provided directly from product developers, and/or catch only very low-volume/long tail organic traffic. 95% of our pages attract fewer than 20 visits/mo, 90% of our pages attract fewer than 10 visits/mo. We have a small business of about 10 employees. Most of which don't maintain our site. It's unrealistic for us to genuinely improve the quality of that many pages. Nor does it make sense to improve most of these pages, as they'll attract only very low volume keywords. Individually these low quality pages don't bring in many customers, but on aggregate they do. 70% of our organic conversions come from pages with less than 20 visits/mo. A few questions: Is this content negatively affecting our domain authority in any way? While I don't believe we've been hit with a penalty, Google knows that on average our pages aren't very helpful to many users, and I'm concerned that affects our ability to rank with pages that matter. None of the content was mass produced in any form of scraping efforts or anything nefarious like that. Would there be any negative/positive affect to offloading these low quality/volume pages to a different domain during the rebrand?
Branding | | dsbud0 -
Domain Transition: Moving over paid traffic campaigns first
We're planning a domain name (rebrand) transition, and considering our options. We rely heavily on paid traffic. To reduce risk, we’re considering moving AdWords and Bing Ads over campaign-by-campaign to the new domain first, while organic traffic continues to direct to the old domain. Each of our ad groups has a custom, noindex’d landing page. In order to serve paid traffic, we’d at minimum need a front page, and likely a privacy policy page in addition. Here’s a rough outline of what I think a transition like this might look like: Launch new domain with a simple front page, and privacy policy. Move over ppc landing pages on the new domain (noindex'd, robots.txt) Create new ads in existing ad groups directing to the new domain. Monitor ad groups for some time period to verify sustainability. Once we're satisfied with ppc performance, and planned the rest of the organic page migrations, 301 redirect everything to the new domain. Is there any problems or things we should be concerned about with this approach? I'd think it should be fine, but I've been bitten enough from large-scale redirects in the past, that I know I should be nervous.
Branding | | dsbud0 -
SEO implications of serving a different site on HTTPS vs. HTTP
I have two sites: Site A, and Site B. Both sites are hosted on the same IP address, and server using IIS 7.5. Site B has an SSL cert, and Site A does not. It has recently been brought to my attention that when requesting the HTTPS version of Site A (the site w/o an SSL cert), IIS will serve Site B... Our server has been configured this way for roughly a year. We don't do any promotion of Site A using HTTPS URLs, though I suppose somebody could accidentally link to or type in HTTPS and get the wrong website. Until we can upgrade to IIS8 / Windows Server 2012 to support SNI, it seems I have two reasonable options: Move Site B over to its own dedicated IP, and let HTTPS requests for Site A 404. Get another certificate for Site A, and have it's HTTPS version 301 redirect to HTTP/non-ssl. #1 seems preferable, as we don't really need an SSL cert for Site A, and HTTPS doesn't really have any SEO benefits over HTTP/non-ssl. However, I'm concerned if we've done any SEO damage to Site A by letting our configuration sit this way for so long. I could see Googlebot trying https versions of websites to test if they exist, even if there aren't any ssl/https links for the given domain in the wild... In which case, option #2 would seem to mostly reverse any damage done (if any). Though Site A seems to be indexed fine. No concerns other than my gut. Does anybody have any recommendations? Thanks!
Intermediate & Advanced SEO | | dsbud0 -
Should I allow a publisher to word-for-word re-publish our article?
A small blog owner has asked if they can word-for-word republish one of our blog articles on their own blog. I'm not sure how to respond. We're don't do any outreach to submit or duplicate our articles throughout the web... so this isn't something being done in mass. And this could be a great signal to Google that somebody else is vouching for the quality of our article, right? However, I'm a bit concerned about word-for-word duplicating. Normally, if somebody is interested in re-publishing, both the re-publisher and our website would get more value out of it if they re-publisher added some form of commentary or extra value to our post when citing it, right? This small blog just started releasing a segment in which they've titled "guest blog Thursday". And given the recent concerns with guest blogging (even though I'm not sure this is the classical sense of guest blogging), I'm even more concerned. Any ideas on how I should respond?
Intermediate & Advanced SEO | | dsbud0