After being parsed, the markup of the include file is plainly visible
in the source code, just like any vanilla page, so I see no reason why
search engines would not index that information. Unless I’m missing
the obvious.
Todd
On Aug 9, 2009, at 7:29 AM, hugh wrote:
Question: do search engines ‘drill down’ from an php-include or SSI
page to scan the content of the include source?
Well, unless I’m missing something obvious…the including page doesn’t display the iframe source.
Of course, it may be there in the iframe (click iframe and view source, I suppose?)
But if you’re just looking at the source of the INCLUDING page, then the source isn’t there.
ie. if I have an including page called atlas.php which is including a file called helmet.html…then you don’t see the source of helmet.html in the source of atlas.php.
To clarify, my post was referring to php or ssi includes, not iFrames.
I tried a version of your example below locally and I can see the
“helmet.html” markup just fine in the php page.
Todd
On Aug 9, 2009, at 9:44 AM, hugh wrote:
ie. if I have an including page called atlas.php which is including
a file called helmet.html…then you don’t see the source of
helmet.html in the source of atlas.php.
Agreed! If you use PHP or SSI, then the included page’s source code is also shown.
But the problem with both these methods is images etc. If there are any images referenced by the included page (htlmet.html), then they will probably not show correctly when you call atlas.php
so if my client is making up pages which have images in them even if they are only small icon graphics, php or ssi is awkward, while iFrame works.
Unless I’m misunderstanding, when I add an image reference to my
include file (or in your case, “helmet.html”) - e.g., - the image shows
up fine in the php file and I can style or position it as needed.
Todd
On Aug 9, 2009, at 10:33 AM, hugh wrote:
But the problem with both these methods is images etc. If there are
any images referenced by the included page (htlmet.html), then they
will probably not show correctly when you call atlas.php
errr…well it might work for you but it doesn’t for me!
Maybe it’s because FW makes these Resource folders? Or maybe it’s my directory structure.
But imagine…the helmet.html is looking for ‘Resources/image.jpg’
But helmet.html (and its corresponding Resources folder) is in the sub-directory includes.
But if you pull the file in by php or ssi, it doesn’t make a distinction. So your included file ends up as part of atlas.php (which is in the directory above), but it’s still looking for Resources/image.jpg.
Unfortunately, Resourcces/image.jpg is actually in the directory below.
Does that make sense? I’ll send you a map via skype
I wrote a KB article many years ago that dealt with SSI, and this was
one of the tricky bits I believe I covered. Have a search on the
Softpress KnowledgeBase and give it a read. You’ll even see where Todd
got some of his menu items (I must have been hungry that day).
Whenever you do SSI (whether it is with PHP or Apache, the principle
is the same) the path to the image will have to be correct from the
perspective of the outer page, not the inner page. So if you are
getting your “parts” from the same basic folder as the rest of your
site, and all of the references to Resources are to the same relative
level, then you won’t hit this problem. But if you have set up your
folder structure like this:
…then a reference to image3.gif in one of the fragments included
into outer_template.shtml will need to be written as though that
request was coming from outer_template.shtml, not from
fragment_1.html. So it would look like this:
Your other option would be to move these images (or symlink them) into
the “main” Resources folder up one level from the fragment files in /
stuff. Then the links could remain as written: Resource/foo.gif and
yet the images would be found when the combined page is loaded.
Walter
On Aug 9, 2009, at 1:08 PM, hugh wrote:
errr…well it might work for you but it doesn’t for me!
Maybe it’s because FW makes these Resource folders? Or maybe it’s my
directory structure.
But imagine…the helmet.html is looking for ‘Resources/image.jpg’
“your other option would be to move these images (or symlink them) into the main Resources folder…”
Yes, exactly! It’s either that manual move or creating a site with just one general Resources folder (does FW do that?..I’ve never noticed or opted for it)
that search engines will find, index and link to just the ‘snippets’… which will be all wrong if someone click the goodle link and finds some text without any context or site layout.
that the client is going to need to top-and-tail the files he outputs before uploading. ie. get rid of the html and head tags. not a huge deal but a nuisance step.
I’m favouring iFrames, at least as far as the second concern goes.
A symlink (properly named symbolic link) is the Unix equivalent of a
Macintosh Alias. It’s a pointer to a file that’s located elsewhere
that acts for all the world like the file itself. To make one, you
need shell access to your server, so not everyone can take advantage
of this. Further, your Apache configuration files must allow Apache to
traverse these links, which is not a completely foregone conclusion
depending on how paranoid your hosting provider is.
At a Terminal prompt, type man ln (that’s lower-case L followed by an
n) for all the gory details.
If you want to try this approach, then, ask your hosting provider to
make the link for you. Most hosts will do these sorts of things for
you if you file a support ticket and describe very clearly what you
want. If it doesn’t work, you can always delete the link using
Transmit or another FTP application. In Transmit, anyway, a link has
an “alias-like” icon, so you can clearly tell which is which.
Walter
On Aug 10, 2009, at 10:36 AM, hugh wrote:
Ooh lordy, I never go to the terminal…!!
At a Terminal prompt, type man ln (that’s lower-case L followed by an
n) for all the gory details.
How would a search engine even find the include files? The actual call
to the include file would be invisible to Google because all it
[Google] would see is the final rendered page with everything in
place. If I’m wrong about this someone tell me.
Todd
On Aug 10, 2009, at 9:14 AM, hugh wrote:
that search engines will find, index and link to just the
‘snippets’… which will be all wrong if someone click the goodle
link and finds some text without any context or site layout
Though I didn’t need to make a symlink myself - I did notice that this
facility is offered by GUI apps that enable non command line users such
things without typing anything anywhere.
That is fine on your local Mac, but you can’t upload a symlink to your
server, you have to create it on the server itself. It would be great
if there was such an application that could put a friendly face on
this, but in the end it really depends on the kind of connection you
can make to your server, and what sort of permissions you have on that
server when connected remotely.
Walter
On Aug 10, 2009, at 11:33 AM, Brian Steere wrote:
Though I didn’t need to make a symlink myself - I did notice that this
facility is offered by GUI apps that enable non command line users
such
things without typing anything anywhere.
I’ve no idea. Would the search engines find the file link? I thought they were capable of following links and levels in sites? But I admit I have no idea how google really works.
So maybe there’s no problem?
How would a search engine even find the include files? The actual call
to the include file would be invisible to Google because all it
[Google] would see is the final rendered page with everything in
place. If I’m wrong about this someone tell me.
Because the call to the include file is replaced with the actual
content of that file on the server before it makes its way to the
browser I don’t see how Google would find it unless there was a
specific hyperlink to that file somewhere. But there would be no
reason to do that.
Yes, Google can navigate a file structure but only if there’s a
hyperlink to a given page from somewhere else and assuming it has
access to it. If by chance a page has already been indexed then the
cat’s out of the bag anyway, but again, there’s no reason why an
include file would or should already be indexed.
The beauty is the fact that all this happens on the server before it’s
available for public consumption by Google or anyone else.
Todd
On Aug 10, 2009, at 10:49 AM, hugh wrote:
I thought they were capable of following links and levels in sites?
But I admit I have no idea how google really works.