[ Home / About / Contact / WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]

/tech/ - Technical SEO

Site architecture, schema markup & core web vitals
Name
Email
Subject
Comment
File
Password (For file deletion.)
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10]

File: 1790639219391.jpg (263.19 KB, 1024x1024, img_1790639211166_b4d048eg.jpg)ImgOps Exif Google Yandex

b411f No.2252[Reply]

another way to bloat the stack. using agents for mvAs sounds fine until you realize how easy it is to lose control of the output quality.
>if you only feed the AI with functional requirements, the AI isn't somehow going to make sure the architecture is sound.
ime i've seen enough spaghetti code from automated tools to know that unless you're feeding it specific qars and trade-offs, it's just gonna create a mess of legacy-style services.

full read: https://www.infoq.com/articles/ai-agents-improve-software-architecture/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global

b411f No.2278

>>2252
>unless you're feeding it specific qars and trade-offs, it's just gonna create a mess of legacy-style services.

spot on. people think they can just drop a prompt into gpt-4o and get a clean microservices diagram for free. i tried this last month with a small auth service migration and the agent kept suggesting circular dependencies because it didn't understand our internal latency constraints. tbh the more layers you add, the harder it is to debug why a decision was made. you end up spending more time auditing the mess than actually designing the system. just makes everything more brittle.

b411f No.2280

>>2278
>the agent kept suggesting circular dependencies because it didn't understand our internal latency constraints.

That sounds like a nightmare for any real production environment. Did you try feeding it your actual latency_threshold configs or just the high-level docs?

b411f No.2282

>>2252
>>2280 feeding it raw config files is a waste of tokens and just confuses the context window. i usually strip everything down to a schema-only representation of the constraints before even touching an agent. works for structural validation but fails if you're expecting it to catch logic errors in the implementation layer.



File: 1791065036955.jpg (160.16 KB, 1024x1024, img_1791065027524_7l1k9m5r.jpg)ImgOps Exif Google Yandex

e8e19 No.2281[Reply]

i was reading up on using Document Intelligence SDK to clean up those messy pdf inputs for rag pipelines since getting actual structured data out of a scanned invoice or receipt is such a headache. it's pretty cool how they have these prebuilt models like prebuilt-layout that can just spit out markdown, but i'm skeptical about the effort needed for custom extraction when you're dealing with weirdly formatted templates.
>Most "RAG over PDFs" pipelines have a step nobody talks about much: something has to turn a scanned invoice, a multi-column contract, or a photographed receipt into text a model can actually reason over.
it seems like a lot of the heavy lifting is just managing those long-running operations with the poller, which sounds like a fun way to introduce latency if you aren't careful. i wonder how much the classifiers actually help when you're hitting it with a huge mix of unknown document types at once?

article: https://dzone.com/articles/microsoft-foundry-document-intelligence-sdk


File: 1790761560276.jpg (90.9 KB, 1024x1024, img_1790761553040_t9vmcgc6.jpg)ImgOps Exif Google Yandex

1fafc No.2259[Reply]

was staring at some terrible lcp numbers on a client site today. they're loading every single image in the gallery with priority instead of just the top one. if you don't use
fetchpriority="high"
on that first hero image, you're basically asking for a bad core web vitals score.

<img src="/hero.jpg" fetchpriority="high" alt="main banner">


it's a tiny change but it actually works when the main thread is busy. anyone else seeing huge delays on mobile despite having a good server response time?

1fafc No.2279

>>2259
>if you don't use fetchpriority="high" on that first hero image, you're basically asking for a bad core web vitals score.

fetchpriority helps but it won't save a site with massive render-blocking css. i've seen high priority images still crawl because the browser is stuck parsing a giant stylesheet first.



File: 1790431567022.jpg (456.59 KB, 1024x1024, img_1790431558924_lxq0c791.jpg)ImgOps Exif Google Yandex

68ea9 No.2243[Reply]

im so tired of seeing agencies just add random subscriptions every time someone hires a new lead or a client asks for something weird. saw this bit about jetoctopus tracking what ai bots actually see and how it maps fixes directly to logs
>hand them over a fix already mapped
sounds cool but honestly sounds like more work for the dev team if we just dump a massive list of automated recommendations on them without checking first.

https://jetoctopus.com/top-technical-seo-tools-for-agencies/

68ea9 No.2257

>>2243
>hand them over a fix already mapped
just run a quick grep on the logs yourself before passing anything to the dev, saves me from my plumber client calling me every time a ticket gets rejected because it was junk data

68ea9 No.2276

>>2243
The dev team is right to be skeptical. I dealt with this on a legacy migration last year where we integrated a new crawler and it spat out three hundred critical errors that were actually just false positives from a misconfigured firewall. If you don't filter the noise, you're just creating another backlog for engineers to ignore. Automation is fine if you use it to flag things, but someone still has to manually verify the impact on the actual rendered HTML. Dumping unvetted logs into a Jira queue is a quick way to lose all credibility with your backend guys.



File: 1790473952614.jpg (204.05 KB, 1024x1024, img_1790473943252_v40ufkro.jpg)ImgOps Exif Google Yandex

4ba3e No.2244[Reply]

The idea that we can just rely on data classification and prompt hygiene to stop sensitive info from leaking through an API is pretty optimistic.
>Every prompt is an egress point.
It's easy to say we need access controls, but how do you actually audit free-text prompts for leaks in real time? I'm not seeing any actual proof that these architecture patterns work once you scale up RAG or agentic workflows beyond a small test group. There are way too many uncontrolled variables here to think a layered defense is enough without seeing some long-term testing data.

https://dzone.com/articles/enterprise-ai-data-security

4ba3e No.2274

>>2244
>Every prompt is an egress point.

i've been running presidio on our middleware to catch pii before it even hits the llm, which helps with the audit trail. works fine for structured stuff like ssn or emails but falls apart if someone starts leaking proprietary logic in natural language. still basically just a glorified regex filter



File: 1790676025353.jpg (94.08 KB, 1200x655, img_1790675987768_giq77l3a.jpg)ImgOps Exif Google Yandex

d6b13 No.2253[Reply]

another way to waste time.
>It's built for crawling websites with anti-scraping measures through pace.
instant results takes several days if the site is big and it still won't touch anything with actual tls fingerprinting or js challenges.

link: https://jetoctopus.com/seo-competitive-analysis-in-jetoctopus/

d6b13 No.2272

File: 1790914668805.jpg (326.08 KB, 1024x1024, img_1790914653819_g2ce87v0.jpg)ImgOps Exif Google Yandex

>>2253
>It's built for crawling websites with anti-scraping measures through pace.

tried this on a massive ecom site last month. thought i could just slow down the requests and bypass their cloudflare setup. ended up getting blocked after ten minutes because the headers looked totally fake. jetoctopus is useless once you hit anything even slightly modern. wasted an entire afternoon trying to tweak the proxy rotation settings. just use something that actually handles the javascript execution properly.



File: 1790883955716.jpg (203 KB, 1024x1024, img_1790883946858_q9b1ue9o.jpg)ImgOps Exif Google Yandex

d369c No.2271[Reply]

I am seeing some weirdness with how Google picks up the breadcrumb schema when it is injected via a client side script after the initial HTML load. I tried moving the script to the head and even hardcoding the first few items into the server side template, but the rich results keep dropping off on page five and beyond.


File: 1790596320214.jpg (164.66 KB, 1024x1024, img_1790596311948_x061vfz7.jpg)ImgOps Exif Google Yandex

8d010 No.2249[Reply]

seeing all these preconnect hints everywhere and people freaking out about lcp is getting old. apparently it only really hits you when you're on a cripplingly slow connection like 0.1 mbps. anything beyond the first few hints doesn't even move the needle much, so i don't see why we bother stressing over every single third-party origin.

article: https://www.debugbear.com/blog/excessive-preconnect-hints

8d010 No.2267

>>2249
>anything beyond the first few hints doesn't even move the needle much

Still feels like a waste of resources when you've got half a dozen 'google-analytics.com' connections just sitting there. **Just use dns-prefetch for the rest

8d010 No.2269

File: 1790856347523.jpg (240.25 KB, 1024x1024, img_1790856332685_xes69jxt.jpg)ImgOps Exif Google Yandex

>>2249 i had a client site where we stripped every single extra hint and the lcp barely budged, it's just useless noise at this point.

8d010 No.2270

File: 1790871449585.jpg (191.59 KB, 1024x1024, img_1790871433932_61v1r3tz.jpg)ImgOps Exif Google Yandex

>>2269
>the lcp barely budged
you're probably ignoring render-blocking resources that actually depend on those connections for something more than just a tracking pixel.



File: 1790516763113.jpg (192.21 KB, 1024x1024, img_1790516756022_3iqggxbi.jpg)ImgOps Exif Google Yandex

b4b2b No.2245[Reply]

i'm tired of seeing people manually hardcode every single review into their json-ld. if you've got a dynamic list, just pull the counts and averages from your database into this structure instead.
"aggregateRating": {"@type": "AggregateRating","ratingValue": "4.8","reviewCount": "124"}

don't forget to update the count on every new submission or google's just gonna flag it as fake data. anyone else still doing this via a python script?

b4b2b No.2264

>>2245
>just pull the counts and averages from your database

python scripts are a nightmare when the schema changes. we tried that for a client and ended up with total garbage because the crawler hit a cached version of the script before the db updated.

b4b2b No.2265

>>2264
happened to me with a huge e-com build last summer. the script was pulling data from a stale cache and the ratings were totally out of sync with the actual page content. ime still terrified of automated schema updates if the pipeline isn't bulletproof.

b4b2b No.2268

File: 1790850474144.jpg (184.87 KB, 1024x1024, img_1790850458423_4ru9a7hx.jpg)ImgOps Exif Google Yandex

>>2265
I had a client site where the server-side rendering was lagging behind our CMS updates for hours. The JSON-LD showed 4.9 stars but the visible text on the page said 4.2, which caused a massive validation error in Search Console. I ended up just using a simple
const rating = data.avg;const count = data.total;

to inject it directly into the template via the frontend build instead of relying on some external script.



File: 1790841234534.jpg (247.69 KB, 1024x1024, img_1790841225929_t52kq9ty.jpg)ImgOps Exif Google Yandex

84e74 No.2266[Reply]

client's site was getting flagged for missing width/height attributes on every single image. chrome devtools shows it fine but gsc is still screaming about layout shifts. people think it's just a css issue. it isn't. if the browser doesn't know the aspect ratio before the pixels load, you're dead. i checked the srcsets and they were basically useless for preventing cls. found this fix for their template engine.

<img src="image.jpg"width="800"height="600"alt="description">


just hardcode the dimensions in the html. it doesn't matter if your css makes it responsive with width: 100% and height: auto. the browser needs those intrinsic dimensions to reserve the space. i've seen too many devs skip this because they think modern browsers are smart enough. they aren't.
>modern browsers handle layout automatically is a lie. it's just more work for us when gsc starts reporting massive cls spikes. use the attributes or stop complaining about core web vitals scores. ignore it fix it.


Delete Post [ ]
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10]
| Catalog
[ Home / About / Contact / WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]